Description
On a fresh local run, a single transient failure (Timeout waiting for PoW headers) during header/session capture permanently tanks the server's internal "estimated context limit" telemetry, and it never recovers even after many subsequent successful requests. This causes the [Compression] step to aggressively (and lossily) truncate/compress every prompt afterwards, even though the underlying model's real context window is much larger (per the model list, deepseek-v4-pro reports context_length: 64000).
Steps to reproduce
- Start the server normally.
- Send a small chat completion request (e.g. via curl) — succeeds fine, logs
Estimated context limit: 224000 chars (~64000 tokens).
- Send a larger request (e.g. an agentic tool-calling request from an OpenAI-compatible client like opencode, with a big
tools schema — ~33k chars). If this request happens to hit a transient Timeout waiting for PoW headers on first attempt (DeepSeek's own anti-bot proof-of-work challenge, unrelated to prompt size), the retry succeeds, but:
[Chat] Attempt 1 (stream) failed: Timeout waiting for PoW headers
[Telemetry] Recorded failure for model 'deepseek-v4-pro'. Prompt size: 2286 chars. Estimated context limit reduced to: 33369 chars (~9534 tokens).
[Chat] Attempt 2/3 (stream) with prompt length 2286 chars.
[Telemetry] Recorded success for model 'deepseek-v4-pro'. Prompt size: 2286 chars. Estimated context limit: 2171 chars (~621 tokens).
The estimated limit drops to 2171 chars (~621 tokens) — this is clearly wrong; it's not related to the actual model's context window, just to the size of the one request that happened to succeed right after the failure.
- Every request after this gets compressed down to fit inside ~2171 chars, regardless of how large the model's real context window is:
[Compression] Prompt length 25729 exceeds target limit of 2171. Starting compression...
[Compression] Compression finished. Final length: 2139
There's no logic that re-probes or grows the limit back up after subsequent successful larger requests — it appears to be stuck at the post-failure floor indefinitely.
Observed impact
With a large tools schema (agentic coding client, e.g. opencode/qwen-code-style clients) getting compressed this aggressively, the model's responses become incoherent — in my case, the final assistant message contained clearly leaked/garbled prompt fragments (<available_skills>, <system-reminder>, [System think] ... boilerplate) that don't belong in a normal chat response, presumably from message boundaries getting mangled during compression.
The underlying tool call itself still worked in my test (file got written and read back correctly), but the conversational text response around it was corrupted/nonsensical, and this would clearly break more complex agentic workflows relying on coherent multi-turn reasoning.
Suggested fix
- Don't let a single PoW/network timeout collapse the estimated context limit that aggressively — the failure is unrelated to prompt size and shouldn't be used to infer a much smaller working context.
- Add logic to grow the estimated limit back up after N consecutive successes at a given size (currently it seems to only shrink, never recover).
- Consider not compressing the
tools/system-prompt-injection section at all (or compressing it last), since dropping/mangling it breaks the tool-calling contract with the client.
Environment
- macOS, Node v22.23.1
- Client: opencode (
@ai-sdk/openai-compatible provider) with tool calling (write/read file tools)
Description
On a fresh local run, a single transient failure (
Timeout waiting for PoW headers) during header/session capture permanently tanks the server's internal "estimated context limit" telemetry, and it never recovers even after many subsequent successful requests. This causes the[Compression]step to aggressively (and lossily) truncate/compress every prompt afterwards, even though the underlying model's real context window is much larger (per the model list,deepseek-v4-proreportscontext_length: 64000).Steps to reproduce
Estimated context limit: 224000 chars (~64000 tokens).toolsschema — ~33k chars). If this request happens to hit a transientTimeout waiting for PoW headerson first attempt (DeepSeek's own anti-bot proof-of-work challenge, unrelated to prompt size), the retry succeeds, but:The estimated limit drops to 2171 chars (~621 tokens) — this is clearly wrong; it's not related to the actual model's context window, just to the size of the one request that happened to succeed right after the failure.
There's no logic that re-probes or grows the limit back up after subsequent successful larger requests — it appears to be stuck at the post-failure floor indefinitely.
Observed impact
With a large
toolsschema (agentic coding client, e.g. opencode/qwen-code-style clients) getting compressed this aggressively, the model's responses become incoherent — in my case, the final assistant message contained clearly leaked/garbled prompt fragments (<available_skills>,<system-reminder>,[System think] ...boilerplate) that don't belong in a normal chat response, presumably from message boundaries getting mangled during compression.The underlying tool call itself still worked in my test (file got written and read back correctly), but the conversational text response around it was corrupted/nonsensical, and this would clearly break more complex agentic workflows relying on coherent multi-turn reasoning.
Suggested fix
tools/system-prompt-injection section at all (or compressing it last), since dropping/mangling it breaks the tool-calling contract with the client.Environment
@ai-sdk/openai-compatibleprovider) with tool calling (write/read file tools)