[ranxianglei]

Problem

Claude Code (CC) through the bili proxy suffers context explosion + task drift (upstream issue #68). Root cause (full analysis in dog/billion-context-pi#12):

• CC sizes its autocompact window off a separate /v1/messages/count_tokens API call.
• The proxy forwarded count_tokens unchanged (unrecognized path) → relay returned the token count of CC's full uncompressed message list.
• CC saw a large count → tripped its own autocompact mid-task → summarized away in-progress context → task drift (was doing task A, ended up on task B).
• Meanwhile the proxy already compresses every /v1/messages turn and reports the compressed usage.input_tokens back to CC. So count_tokens was the one remaining leak — the only signal CC had that still reflected the uncompressed size.

Fix

Route /v1/messages/count_tokens through the same compression pipeline as /v1/messages, so the relay returns the post-compression token count. CC then sizes its window off the small compressed count and never trips autocompact.

• New prepareCountTokens() runs the read-only processTurn (identical prune/inject/tag path as prepareAnthropic) but discards the returned state — count_tokens is a query and must not mutate session state, create blocks, or nudge. Verified processTurn does not mutate the input state object.
• compressInjected: false + empty processedMessages → forward() does plain pipeThrough of the relay's non-streaming {input_tokens} JSON response.
• Escape hatch: ACP_COUNT_TOKENS_PASSTHROUGH=1 restores the old unchanged-forward behavior.

Why this is correct

CC's autocompact is redundant in the proxy architecture: the proxy already compresses for the upstream model. CC's own compaction is pure double-compression — information loss (task drift) with zero model benefit. Making count_tokens report the compressed count aligns it with the /v1/messages usage CC already sees, so CC never believes it is near the limit.

Trade-off (explicit): CC's local context now grows unbounded (it never autocompacts; the upstream never returns prompt-too-long since it sees the compressed body). Memory grows at MB scale for long sessions — acceptable and is the intended behavior.

Tests

tests/count-tokens.test.ts (4 new):

1. With coverage: pruned output < input, summary injected, log delta present.
2. Read-only: session state JSON byte-identical before/after; block count + coverage unchanged.
3. No blocks: output == input.
4. Prune failure (bogus state): logs fallback warning, forwards original body.

Full suite: 173 pass, 0 fail. npm run typecheck clean. npm run build OK.

Note on Codex

Codex does not need an equivalent fix — it triggers compaction off response.completed.usage.input_tokens (no separate count_tokens call), which the proxy already returns compressed (verified stream-responses.ts:227 passes the completed event through verbatim).