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.