fix(report): weight 1h cache writes at 2x, not 1.25x

john commented

2026-08-01 12:04:12 +00:00

Owner

burnrate already split cache_creation into its 5m and 1h halves and charted them separately, then multiplied both by 1.25. Only the 5m write bills at 1.25x base input; a 1h write bills at 2x, so every 1h token was counted at 62.5% of its weight and the composition legend named the wrong multiplier next to the wrong bar.

be_of now weights 1.25 on (cache_creation - ephemeral_1h) and 2 on ephemeral_1h. Across my own 40 active days that moves the total from 851M to 947M billed-equiv, +11.4%. Transcripts predating the cache_creation breakdown report no 1h tokens and keep the 5m weight throughout, which the docstring says outright.

Fixture weights match, so per-message billed-equiv is an exact 775 instead of 700, and the suite fails in 19 places if the two weights are collapsed back into one. 141 tests pass.

burnrate already split cache_creation into its 5m and 1h halves and charted them separately, then multiplied both by 1.25. Only the 5m write bills at 1.25x base input; a 1h write bills at 2x, so every 1h token was counted at 62.5% of its weight and the composition legend named the wrong multiplier next to the wrong bar. be_of now weights 1.25 on (cache_creation - ephemeral_1h) and 2 on ephemeral_1h. Across my own 40 active days that moves the total from 851M to 947M billed-equiv, +11.4%. Transcripts predating the cache_creation breakdown report no 1h tokens and keep the 5m weight throughout, which the docstring says outright. Fixture weights match, so per-message billed-equiv is an exact 775 instead of 700, and the suite fails in 19 places if the two weights are collapsed back into one. 141 tests pass.

john added 1 commit

2026-08-01 12:04:13 +00:00

fix(report): weight 1h cache writes at 2x, not 1.25x 0d0d500b82

burnrate already split cache_creation into its 5m and 1h halves and
charted them separately, then multiplied both by 1.25. Only the 5m write
bills at 1.25x base input; a 1h write bills at 2x. Every 1h token was
therefore counted at 62.5% of its weight, and the composition chart's own
legend asserted the wrong multiplier next to the wrong bar.

Claude Code writes a mix of both TTLs, so no single blended weight is
right. be_of now reads the split it was already carrying: 1.25 on
(cache_creation - ephemeral_1h), 2 on ephemeral_1h. Across my own 40
active days that moves the total from 851M to 947M billed-equiv, +11.4%,
and it shifts weight toward the sessions that hold a long cache rather
than spreading it evenly.

Transcripts old enough to predate the cache_creation breakdown report no
1h tokens and keep the 5m weight throughout. That undercounts them, but
it is the only reading their data supports, and the docstring on be_of
says so rather than leaving the next reader to infer it.

The fixture carries a 300/100 split per message, so its billed-equiv
stays an exact integer at 775 per message instead of 700, and the suite
fails in 19 places if the two weights are collapsed back into one.

john merged commit 8ba4634b5d into main

2026-08-01 12:04:20 +00:00

john referenced this pull request from a commit

2026-08-01 12:04:22 +00:00

Merge pull request 'fix(report): weight 1h cache writes at 2x, not 1.25x' (#5) from fix/1h-cache-write-weight into main

Rows
Columns

fix(report): weight 1h cache writes at 2x, not 1.25x #5