[argszero]

Summary

Anthropic reports input_tokens, cache_read_input_tokens and cache_creation_input_tokens as three disjoint segments, so input_tokens already excludes cache reads. On the streaming path this repository subtracted the cache-read amount from it anyway: the uncached segment clamped to zero, and those tokens were billed as cache hits only.

gateway.rs's own module header has said so since the cache-write work landed: listing where each protocol keeps its cache-read count, its anthropic line reads, in the original Chinese, "input_tokens already excludes the hit, do not subtract". The prose was right and the code below it was wrong.

This is the streaming Anthropic undercount that #434 named in its own body as tracked separately and deliberately untouched. It is that follow-up.

Related Issue

Closes #435

The defect is four sites, not one

I checked before writing code, because patching only the obvious one would have left the client-facing path broken. All four have the same root cause; the same expression (input - cached).max(0.0) was applied to every protocol.

Site	Path it serves	Protocol	Verdict
gateway.rs — UsageCapture::finish	same-protocol streaming	anthropic	wrong — subtracted a segment that was never in input_tokens
gateway.rs — UsageCapture::finish	same-protocol streaming	openai_chat, responses	correct — prompt_tokens does include the hit
sse.rs — anthropic_sse_to_openai, message_delta branch	anthropic upstream → openai client	anthropic	wrong
sse.rs — anthropic_sse_to_openai, message_stop branch	anthropic upstream → openai client	anthropic	wrong
sse.rs — anthropic_sse_to_openai, end-of-stream fallback	anthropic upstream → openai client	anthropic	wrong

sse::anthropic_sse_to_responses is a wrapper around anthropic_sse_to_openai, so responses clients carried the same defect without appearing anywhere in the diff.

The three record_usage sites in the openai / responses upstream converters are correct and are unchanged: there input_tokens genuinely includes cache reads, and subtracting is what stops the same tokens from being charged once at input_per_m and again at cache_hit_input_per_m.

Changes

• One criterion, one place: gateway::uncached_input(protocol, input, cached). anthropic returns input unchanged; the OpenAI shape subtracts with .max(0.0), and that clamp guards the OpenAI underflow (upstream reports cached > prompt), not the protocol difference.
• UsageCapture::finish calls it with self.protocol instead of recomputing the expression.
• The three cross-protocol record_usage sites call a one-line local wrapper, sse::anthropic_uncached_input, which delegates to the same function — so the rule stays single-sourced while each call site stays readable.
• Four assertions that had pinned the defect as the expected value are corrected: two in gateway.rs, two in sse.rs. The load-bearing one asserted (input, cached) = (80, 70) yields input == 10.0 for anthropic; the correct value is 80.0. The openai half of that same test (prompt_tokens 100, cached 90 → 10.0) was right and still is.
• One new test, streaming_uncached_input_follows_the_protocol_not_the_operation: the same numbers (input 100, cached 90, output 50) through both protocols, asserting (10, 90, 50) for openai_chat and (100, 90, 50) for anthropic. Pinning only the Anthropic half would let a future "unification" back onto the subtraction pass; this pairing is what makes that fail.

Billing impact, stated precisely: existing ledger rows are not rewritten; the change alters settlement from this point on — the same traffic becomes more expensive. The worked example in #435, at claude-sonnet-5.5 catalogue prices ($2.00 input / $0.10 cache-read / $10.00 output per million): input=2,000, cache_read=60,000, output=1,000 settles at $0.020000; streamed today it settles at $0.016000, because the uncached segment was clamped to zero — ~20% of that call, and the larger the cached share, the wider the gap.

Tests

• cargo test — 584 passed, 0 failed (baseline 583, plus the one new test).
• cargo fmt --check — clean.
• cargo clippy --all-targets -- -D warnings — clean (the CI invocation, .github/workflows/ci.yml:30).

Both directions of the fix were checked by mutation, not just asserted:

• Forcing the pre-fix behaviour (always subtract) turns 4 tests red: both_usage_parsers_read_anthropic_cache_creation_tokens, streaming_uncached_input_follows_the_protocol_not_the_operation, usage_capture_parses_openai_and_anthropic, and sse::tests::anthropic_cache_read_spelling_disjoint.
• Forcing "never subtract" turns 3 tests red — the openai / responses side, which must keep subtracting.
• Restored: 584 / 0.

Deliberate boundaries

• The three openai / responses record_usage sites are untouched on purpose. A blanket removal of the subtraction would have introduced the mirror-image defect: double-charging cached tokens.
• The non-streaming path already behaved correctly — parse_usage expresses the same rule through a per-protocol match — and its behaviour is unchanged. What changed is that streaming now agrees with it on the same usage; a test that previously pinned the two paths to different values ((0.0, 100.0)) now pins them to the same one ((100.0, 100.0)).
• No schema change, no config change, no new dependency, no new field. Two files, 119 insertions, 16 deletions.

Checklist

• Branch name follows the convention (fix/)
• Commit message uses Conventional Commits
• Single responsibility, minimal diff