copilot journal era: claude-opus-4-6 reports zero cache read/write — recovered history overprices cached tokens #1094

Activity

1. iamtoruk commented on Aug 22, 2026

   

   iamtoruk

   on Aug 22, 2026

   MemberAuthor

   More actions

   Investigated. src/providers/copilot.ts's journal parser already maps cacheReadTokens/cacheWriteTokens from the session.shutdown rollup generically for every model — proven correct with real data for claude-sonnet-4-5 (issue #676's sample, pinned in tests/providers/copilot.test.ts:592). assistant.message events carry no input/cache fields at all (only outputTokens), so the rollup is the sole journal-era source. A synthetic fixture reproducing kelchm's claude-opus-4-6 shape confirms the parser passes through exactly what the CLI wrote — zero — and that zero cache split is what drives the full-input-rate pricing.

   Cross-referencing kelchm's #946 validation: zero cache read/write for claude-opus-4-6 was observed on both 0.9.20 and the #946 branch (same parser code), while other models in the same corpus/era carry real cache data on the same rollup schema. That points at the Copilot CLI itself not recording cache accounting for claude-opus-4-6 during the Feb–May window, not a codeburn mapping gap.

   There's no other journal field to derive a real split from, and inventing a blended cache-hit assumption would fabricate per-session numbers this codebase's costIsEstimated/measured-cost conventions exist to prevent. Closing as data-limited: the recovered pre-store history for this model/era is priced at full input rate because that's genuinely all the CLI recorded, not because codeburn drops it. If a journal sample ever surfaces with real opus-4-6 cache fields, reopen with the excerpt and this becomes a mapping fix.
2. iamtoruk

   closed this as completedon Aug 22, 2026