Follow-ups deferred from the 2.1.257 identity work (#180), both MEDIUM wire-fidelity, neither cache/billing-blocking.
1. cc_prompt_id + cc_prev_req billing-header fields
Real Claude Code 2.1.257 emits two fields after the canonical cch, ordered …cch; cc_prev_req; cc_prompt_id;:
cc_prompt_id — a client-minted UUID, stable per user prompt, absent on background/prewarm requests.cc_prev_req — present on non-first turns, equal to the previous Anthropic response's request-id.
We emit neither. Deferred because they need real plumbing: a stable per-user-prompt UUID (with retry stability) and per-session capture/threading of the prior response's request-id. The existing cache-diagnostics tracker stores provider message IDs, not response request IDs, so it can't be reused directly for cc_prev_req.
Impact: MEDIUM wire-fidelity gap. Both fields sit in the uncached billing tail after cch, outside the hashed body and the cache breakpoint, so their absence does not affect prompt-cache keys or billing acceptance. Wire order when implemented: cc_prev_req before cc_prompt_id.
2. The [1m] model-id variant misses both model matchers
The live capture's bootstrap offered claude-fable-5-1[1m] (the 1M-context variant). Our model matchers key on exact id or a --suffix only, so claude-fable-5-1[1m] matches neither the 5.0 family nor the 5.1 matcher. Unreachable today — nothing in the repo selects a [1m] id — but if that variant ever becomes configurable, 5.1 handling (pricing, tool_choice strip, server-side fallback, thinking-binding-controls) would silently miss it. Fix when it becomes reachable: tolerate a [...] suffix or normalize the id before gating.
Follow-ups deferred from the 2.1.257 identity work (#180), both MEDIUM wire-fidelity, neither cache/billing-blocking.
1.
cc_prompt_id+cc_prev_reqbilling-header fieldsReal Claude Code 2.1.257 emits two fields after the canonical cch, ordered
…cch; cc_prev_req; cc_prompt_id;:cc_prompt_id— a client-minted UUID, stable per user prompt, absent on background/prewarm requests.cc_prev_req— present on non-first turns, equal to the previous Anthropic response'srequest-id.We emit neither. Deferred because they need real plumbing: a stable per-user-prompt UUID (with retry stability) and per-session capture/threading of the prior response's
request-id. The existing cache-diagnostics tracker stores provider message IDs, not response request IDs, so it can't be reused directly forcc_prev_req.Impact: MEDIUM wire-fidelity gap. Both fields sit in the uncached billing tail after
cch, outside the hashed body and the cache breakpoint, so their absence does not affect prompt-cache keys or billing acceptance. Wire order when implemented:cc_prev_reqbeforecc_prompt_id.2. The
[1m]model-id variant misses both model matchersThe live capture's bootstrap offered
claude-fable-5-1[1m](the 1M-context variant). Our model matchers key on exact id or a--suffix only, soclaude-fable-5-1[1m]matches neither the 5.0 family nor the 5.1 matcher. Unreachable today — nothing in the repo selects a[1m]id — but if that variant ever becomes configurable, 5.1 handling (pricing, tool_choice strip, server-side fallback, thinking-binding-controls) would silently miss it. Fix when it becomes reachable: tolerate a[...]suffix or normalize the id before gating.