Claude: full context fails turns as "blocking_limit" instead of compacting #160

Summary

A long Claude thread reached 96% of its context window (961,230 of 1,000,000 tokens). Claude reported auto-compact as enabled, yet the next turn failed 4 s after it started, and the chat panel showed only Claude turn failed (blocking_limit). That message doesn't say the context is full or what to do. BiBCode didn't compact or retry. The user had to recognise the cause, type /compact by hand, and resend. Messages sent after the failure queue behind the manual compaction. The profiler recorded nothing for the failed turn.

Environment

Evidence

• Thread token usage at 13:25:27 UTC: usedTokens 961,230, maxTokens 1,000,000, compactsAutomatically: true (from Claude's isAutoCompactEnabled).
• The turn started at 13:30:18 and failed at 13:30:23 UTC. The session is now in error with last_error Claude turn failed (blocking_limit). and last_error_class provider_error.
• Claude's own transcript for that turn: one synthetic assistant message with isApiErrorMessage: true, error: "invalid_request", text Prompt is too long. The transcript has no compaction boundary, so automatic compaction never ran. It wasn't a failed compaction: Claude then says automatic compaction failed: ….
• In Claude Code 2.1.308, blocking_limit sits with prompt_too_long and rapid_refill_breaker as the { kind: "stop", cause: "context_limit" } terminal reasons.
• Profiler events from 13:29 to 13:35 UTC: only server.refreshProviderUsage timings and client batches. Nothing marks the failed turn.

Suspected source

• apps/server/src/provider/claude/runtime.rs:2654: with no errors and no api_retry error, the message falls back to Claude turn failed (<terminal_reason>)., which turns a context-limit stop into an opaque code.
• apps/server/src/provider/claude/protocol.rs:86: AssistantMessage doesn't model Claude's error / isApiErrorMessage, so the Prompt is too long text never reaches the failure message.
• apps/server/src/provider/claude/usage.rs:63: BiBCode already knows usedTokens, maxTokens and compactsAutomatically, but nothing acts on a near-full window.

Reproduction

1. Run a Claude thread until the context indicator approaches the window (here 96% of 1M).
2. Send another message.
3. The turn fails within seconds with Claude turn failed (blocking_limit). Further messages also fail or queue until the user sends /compact.

Root-cause hypothesis

Claude Code stopped at its blocking context threshold without running auto-compact, even though auto-compact was enabled. That part is upstream behavior in headless stream-json mode, and its trigger is unclear. BiBCode treats the stop as a generic provider error, hides the actionable text, and has no recovery path. Confidence: high for the BiBCode handling (code paths above); low for why Claude skipped its own auto-compact.

Suggested fix direction

• Classify blocking_limit, prompt_too_long and rapid_refill_breaker as a context-limit failure (its own errorClass). Show an actionable message such as "This conversation filled Claude's context window. Compact it to continue.", with a Compact action, and carry Claude's own text (Prompt is too long, or automatic compaction failed: …).
• Recover automatically: on a context-limit failure, send /compact to the same session once, then redeliver the failed message. If compaction fails too, stop and show the actionable error; never loop. Consider a setting, on by default.
• Guard proactively: when usedTokens / maxTokens crosses a high threshold (for example 95%) and the turn ends idle, compact before the next turn instead of waiting for Claude's blocking threshold.
• Profiler coverage: record provider turn failures (redacted: provider, terminal reason, error class) so repeated context-limit stops raise a finding.