trace close discards the tool-call count, which is the actual cost multiplier #199

New issue

Closed

opened 2026-08-16 17:16:06 +00:00 by john · 0 comments

john commented

2026-08-16 17:16:06 +00:00

Owner

The defect

The subagent return carries a tool-call count and Cadence throws it away.

Today's returns, verbatim: the phase-2 executor came back with
<subagent_tokens>160988</subagent_tokens><tool_uses>86</tool_uses>, the deep
verifier with 55251 / 24. trace close takes --tokens and has nowhere to
put the other number, so the record keeps the term that under-reports by ~20x
and discards the term that is the actual cost multiplier.

Why turns are the multiplier

Decomposed over the last 7 days on this repo, the bill is
cost ~= turns x window x 0.10:

Component	Billed-equiv	Share
cache-read x0.10	181,626,530	62.5%
cache-write 5m x1.25	60,880,839	21.0%
cache-write 1h x2	47,800,186	16.5%
fresh input x1	89,778	0.0%

15,579 messages at an average 121,250-token window. Every assistant turn re-reads
the whole window at the cache-read rate, so a dispatch's cost is close to linear
in its turn count. At 121,250 the phase-2 executor's 86 turns are roughly
1.04M billed-equivalent in re-reads alone, before anything it wrote.

Cache HIT RATE is not the lever - it is already 96.1% and cache-read is the cheap
rate. Turn count is, and it is the one quantity the record never captures.

The fix

Add a tool-call (or turn) field to the close seam:

planning.mjs trace close --phase <N> --plan <k> --role <r> --tokens <t> --tool-calls <n>

Same shape as --tokens: omitted when the return carries no figure, never
defaulted to 0. Every dispatch site in workflows/ already reads the return to
get --tokens, so the count is in hand at exactly the same moment and no site
gains a read.

Then trace render and trace suggest can report turns per dispatch and
turns per role beside the token totals, which is the first time the multiplier
becomes visible at all.

Why this one first

It is a one-field change and it is the prerequisite for judging every other cost
proposal: whether batching improved, whether bigger plans amortize better,
whether a window budget is being approached. None of those can be argued today
because the number does not exist.

## The defect The subagent return carries a tool-call count and Cadence throws it away. Today's returns, verbatim: the phase-2 executor came back with `<subagent_tokens>160988</subagent_tokens><tool_uses>86</tool_uses>`, the deep verifier with `55251` / `24`. `trace close` takes `--tokens` and has nowhere to put the other number, so the record keeps the term that under-reports by ~20x and discards the term that is the actual cost multiplier. ## Why turns are the multiplier Decomposed over the last 7 days on this repo, the bill is `cost ~= turns x window x 0.10`: | Component | Billed-equiv | Share | |---|---|---| | cache-read x0.10 | 181,626,530 | 62.5% | | cache-write 5m x1.25 | 60,880,839 | 21.0% | | cache-write 1h x2 | 47,800,186 | 16.5% | | fresh input x1 | 89,778 | 0.0% | 15,579 messages at an average 121,250-token window. Every assistant turn re-reads the whole window at the cache-read rate, so a dispatch's cost is close to linear in its turn count. At 121,250 the phase-2 executor's 86 turns are roughly 1.04M billed-equivalent in re-reads alone, before anything it wrote. Cache HIT RATE is not the lever - it is already 96.1% and cache-read is the cheap rate. Turn count is, and it is the one quantity the record never captures. ## The fix Add a tool-call (or turn) field to the close seam: ``` planning.mjs trace close --phase <N> --plan <k> --role <r> --tokens <t> --tool-calls <n> ``` Same shape as `--tokens`: omitted when the return carries no figure, never defaulted to 0. Every dispatch site in `workflows/` already reads the return to get `--tokens`, so the count is in hand at exactly the same moment and no site gains a read. Then `trace render` and `trace suggest` can report turns per dispatch and turns per role beside the token totals, which is the first time the multiplier becomes visible at all. ## Why this one first It is a one-field change and it is the prerequisite for judging every other cost proposal: whether batching improved, whether bigger plans amortize better, whether a window budget is being approached. None of those can be argued today because the number does not exist.