v1.27.0 ·
The bill was never the thinking
I counted before I wrote anything. Across this repository's 53 transcripts, AIDLC counted 17,292 usage-bearing lines. There were 9,357 distinct API responses. That is an over-count of 1.848x.
Claude Code writes one transcript line per content block, and repeats the response's usage on every one. A reply that thought aloud and then called two tools was charged three times. All 7,935 repeat lines carried a usage object identical to the first, and every group of repeats was contiguous.
The direction mattered more than the size. Duplication scales with content blocks, so it scales with parallel tool use. Calling two tools in one reply is cheaper than two sequential replies, because it skips a re-read of the whole conversation. The meter was reporting the best optimization available as a cost increase.
What changed
Usage is now grouped by response id, and repeats are collapsed rather than summed. Collapsing is only right if the repeats are identical, and I measured that before choosing. Summing would have reproduced the defect.
The reports changed too. The token total summed fresh input and output only, hiding 95 percent of the volume and 91 percent of the cost, so any cost-per-million figure was off by two orders of magnitude. Cache tokens now count, and the reported total rises about 26-fold. The cost report also names the driver: the share spent re-reading the prefix, the average context size per response, and the cost per response.
Those numbers showed the real bill. Ninety-one percent of what this lifecycle costs is cache traffic, paying turn after turn to carry a conversation that only grows. Average context runs from 80,000 tokens in ideation to 395,000 in deployment to 791,000 in maintenance. Deployment is the most expensive phase, ahead of implementation, not because it does more but because it runs last and inherits everything. The one phase that reliably starts in its own session does comparable work at 76,000.
So a phase boundary is a free context reset, and nothing said to take it. The framework overview now states that rule once. Each phase skill names what to re-read when it starts fresh. And aidlc cost context reports what the session is carrying against a budget that defaults to 150,000 tokens, set by cost.context_budget_tokens in config. It reads the transcript, not the ledger, since the question comes at a phase boundary, when the ledger has nothing recent.
Choices
I built the two items together. The second item's success criteria were measurements, all read through a meter that was 1.85x wrong. Landing the cap first would have shipped a saving nobody could verify.
Routing testing, deployment and maintenance to a cheaper model simulates at 39% against the cap's 31%, and 57% combined. I did not skip it. It needs per-phase model support that does not exist.
I would not scale the history. For 14,212 ledger entries no transcript is left to re-read. Multiplying them by the known factor would have looked tidier and made an estimate indistinguishable from a measurement, the defect I was removing. Those entries stay byte-identical and are reported as unknown, so the correction comes out at 1.362x, not the 1.937x the analysis predicted. aidlc cost dedupe plans by default and writes only with --apply. I have not applied it, because it moves every cost figure already published.
One smaller fix came along: aidlc discover stopped destroying hand-written context documents.
What it does not do
The budget is a report, never a gate. This project's guidance is that features watching the lifecycle become a tax on every later piece of work.
And the loose end: I ran the command on the session that built it. It read 198,000 tokens, rising to 306,000, over budget throughout. Either 150,000 is too tight for a change this size, or the rule needs the fresh session it recommends and I never took one. The next three pieces of work decide. If starting fresh spends back more than a third of the saving on re-reading, the threshold moves, not the claim.