v1.28.0 ·
The cheapest token is the one you never carry
Answer first
You are not paying for the model to think. You are paying for it to remember.
Across every token this project has ever spent building itself — 56 lifecycle instances, about 10.9 billion tokens — the split is not close:
| token class | tokens | share of tokens |
|---|---|---|
| cache read (re-reading the conversation) | 10,469M | 95.9% |
| cache write (adding to it) | 409M | 3.7% |
| output (what the model actually produced) | 39.3M | 0.4% |
| fresh input (what you typed) | 0.14M | 0.001% |
Ninety-six percent of the volume is the model being handed, again, what it was handed last turn. Your prose is a rounding error. Its prose is a rounding error. The bill is the carrying.
That single fact is the whole cost argument for working in a lifecycle instead of one long chat, and it is also the reason the savings are much larger than they look.
Why one long session gets expensive, mechanically
Every API call in an agentic session re-sends the entire conversation so far. Caching makes that cheap per token — a cache read costs a tenth of a fresh input token — but it does not make it free, and the thing being multiplied grows all day.
Two consequences follow, and neither is intuitive.
A token you add mid-session is not charged once. It is charged once to write, then again on every subsequent turn. On this project's measured mix, a thousand tokens appended in the middle of a working session cost about 25 times their write price over the rest of that session, because they got re-read an average of 304 more times. A 6KB file you pasted "just to have it in context" is not a 6KB decision. It is a 6KB decision multiplied by however many turns you have left.
The same work costs more later in the day than earlier. Here is average resident context per unit of work, by lifecycle phase, measured across this project's first 49 instances before any of this was fixed:
ideation 84k
requirements 174k
design 182k
implementation 274k
testing 354k
deployment 413k
maintenance 812k
complete 81k <- fresh session
Look at the last row against the second-to-last. The complete phase does real work —
writing up an instance, filing its roadmap item, recording lessons — at 81k tokens. The
maintenance phase does comparable work at 812k, ten times the cost per turn, for one
reason: it inherits everything that came before it in the same conversation.
That is not a phase being complicated. That is a phase being late.
What caching is already doing for you
Before crediting any framework with anything, the honest baseline: prompt caching alone is doing the heavy lifting.
this project, as metered: $9,737.82
the same tokens with no caching: $60,507.74
caching saves: 83.9% (6.2x)
If you are agentic coding at all, most of your theoretical bill is already gone. What remains — the ~$9.7k — is the part that is still yours to control, and it is 96% carrying cost. So the lever is not "think less" or "use a cheaper model first". It is carry less.
What AIDLC actually does about it
Five mechanisms, each with the measured effect rather than the intention.
1. State lives in files, so a session can end
This is the load-bearing one, and it is a design decision rather than a feature. An AIDLC
instance keeps its progress in .aidlc/state/: which phase it is in, which acceptance
criteria exist, which tasks are ticked, what the design decided. None of that lives in the
conversation.
Which means the conversation is disposable. The framework says so explicitly:
A phase boundary is where you start a fresh session. Not a suggestion about tidiness: 91% of what a lifecycle run costs is re-reading the conversation it is already carrying, and that carry only grows.
In a single long chat you cannot do this, because ending the chat loses the plan. That is the actual cost difference between vibe coding and a lifecycle — not ceremony, not rigour. It is whether you are allowed to throw the transcript away.
2. Each phase names exactly what to re-read
A fresh session is only cheaper if it does not immediately re-read everything to catch up. So every phase skill carries a bounded list, and the list is closed:
Re-read only what the phase you are entering names. Each phase skill lists exactly that under Entering in a fresh session. The list is the whole list — an artifact not on it is not needed to start, and reading it "for context" is the charge this rule exists to avoid.
Concretely, the testing phase reads the requirements and not the design. The deployment phase reads neither the requirements, nor the design, nor the implementation write-up. It reads the test results and the state files. That is a few kilobytes to enter the most expensive phase in the lifecycle, against the hundreds of kilobytes a continuing session would have been carrying.
3. A knowledge graph, so the codebase is not re-explored
The single most expensive habit in agentic coding is re-discovering the shape of a codebase: grep, read, read, read. AIDLC records what it learns once and queries it after:
aidlc knowledge query cost # what do we already know about this?
aidlc knowledge context --scope phase --phase design
The graph's answers are token-budgeted — 2,000 tokens by default — where the equivalent exploration is tens of thousands of tokens of file bodies that then sit in the prefix for the rest of the session. The phase skills mandate asking before exploring for exactly that reason.
4. The stable part goes first, so caching can work
Caching only pays when the front of the context does not move. AIDLC's compiled skills, guidance layers and context documents are stable across a whole session, and the framework refuses to inline anything over 2KB into a skill body — large guidance is delivered as a pointer, read once, and cached. The 83.9% above is not luck; it is what a stable prefix buys.
5. It measures itself, in the one unit that matters
You cannot optimize what you cannot see, and the default cost view of most agentic work is "my credit card said a number". AIDLC reports the driver:
$ aidlc cost cost-driver-integrity
total: $12.73 elapsed: 2.0h active: 14m idle: 1.7h fidelity: 100% reconciled
context re-read: 60.2% of spend avg context: 144k per response: $0.22 responses: 59
That is this very feature's own cost. Four numbers a person can act on: how much went on
re-reading rather than producing, how big the context was, what a single round trip cost,
and how many round trips there were. $12.73 on its own tells you nothing. "60% of it was
re-reading a 144k prefix, at 22 cents a turn" tells you what to change.
And there is a budget you can check at any moment:
$ aidlc cost context
resident context: 124k budget: 150k 83% — within budget
It is a report, never a gate. A long implementation phase may legitimately blow through it; the point is that you know.
Did it work? Partly, and here is where it did not
This is the part most framework write-ups skip. The rule above shipped on 2026-09-10. Here is average resident context per record, per phase, before and after — measured, same meter both sides:
| phase | before | after | change |
|---|---|---|---|
| requirements | 174k | 100k | -42% |
| design | 182k | 137k | -25% |
| implementation | 274k | 214k | -22% |
| testing | 354k | 292k | -18% |
| deployment | 413k | 406k | -2% |
Real, and lopsided. The early phases dropped hard. Deployment — the most expensive phase in the lifecycle, 17.8% of all spend — barely moved.
The reason is behavioural, not technical. Deployment is where you are deepest into a working session, most reluctant to restart, and most likely to think "I am nearly done". It is precisely where the discipline is hardest to keep and where it would pay most.
The success criterion written down in advance was that deployment and testing should fall below 150k. They are at 406k and 292k. That target has not been met, and it is recorded as not met rather than quietly restated. The mechanism works where sessions naturally break; it does not yet work where a human does not want to break one.
For the record, the instance whose own numbers appear above — cost-driver-integrity,
which built the measurement this post relies on — ran at 144k average context, inside
the budget, across four phases and 59 model round trips, for $12.73. That is the rule
being followed rather than merely published.
Two things we got wrong about our own bill
Being able to measure is not the same as measuring correctly, and this project has now been wrong twice in the same direction — flatteringly.
The meter double-counted by 1.85x for a month. Claude Code writes one transcript line per content block, and repeats the response's usage object on every one of them. AIDLC counted lines. One API call that used three tools was billed three times. 46% of its usage records were duplicates of a response it had already counted. Worse, the error scaled with parallel tool use — genuinely the cheapest thing an agent can do, since two tools in one turn saves an entire full-context read. The meter reported the cheap behaviour as three times the cost. The correction across the full history is $9,673 down to $7,134.
Then the fix's own instrument lied. The corrected meter reported average context per
response by dividing token totals taken over every ledger entry by response counts
carried on only a handful of them. It printed an average context of 21.5 million tokens
and rendered it like a measurement. That is the defect this release fixes: the numerator
and the denominator now range over the same entries, and when only part of the ledger is
counted, the derived figures are marked with a ~ instead of pretending to be exact.
And 43.3% of spend was in a file nothing priced. Records that fall outside any instance's claim window land in an unattributed pool. That pool was about $4,220 — nearly half of everything — and the only surface for it printed an entry count with no dollars. The default report now ends with the line it should always have had, read here on 2026-09-14:
unattributed: $4218.43 across 10062 entries — `aidlc cost sync` attributes what claim windows cover
It is a growing number, because unclaimed work accumulates. That is the point of putting it where somebody sees it.
The general rule, learned expensively: any figure that becomes money needs a duplicate-cursor audit across every path that writes it — and an instrument reporting "fine" is not evidence, until you have checked it can report anything else.
What AIDLC does not do for you yet
Named plainly, because a cost story with no gaps is marketing.
- Per-phase model routing. The single largest unrealised saving. Deployment and testing are 24.5% of spend and the most mechanical work in the lifecycle — run the suite, write the release plan, update a docs page. Simulated against the real token mix, routing those phases to a cheaper model saves 39%, and combined with the context cap 57%. It needs platform support that does not exist today, so nothing here pretends to offer it.
- Subagent work is cost-invisible. A subagent's usage lands in the parent session's
transcript. If the parent holds no claim, nothing is attributable, and the instance reads
no datarather than a low number. - The always-on guidance layer grows. This project's own lessons file is 83.7KB, about 21k tokens, and eight phase skills read it in full. Carrying it has cost about $246 so far. There is no digest mechanism yet; it is the next thing to fix, and it is on the record as such.
- Fresh sessions at deployment. Per the table above: published, not yet habitual.
What to do on Monday
Ranked by measured saving, for anyone doing agentic work with or without this framework:
- End the session at a natural boundary and start again. Worth 31% on this project's token mix. It is only possible if your state is in files — which is the argument for a lifecycle, not for discipline.
- Re-read from a list, not from instinct. "Let me just load the design doc for context" is a charge on every remaining turn, not a one-off read.
- Prefer an edit to a rewrite. Writing a whole file puts the whole body in the prefix permanently — averaging 6KB across 700 calls here, against 1.2KB for an edit across 1,294. Rewriting a file you could have edited is a permanent context charge.
- Batch independent tool calls. Only 10% of tool-calling responses here made more than one call. Two tools in one turn saves a whole full-context read; the saving is roughly 8% of spend and it is free.
- Check the actual driver, not the total.
aidlc costandaidlc cost context. If cache-read share is above 60% and your average context is six figures, your problem is carrying, and no model change fixes carrying. - Read true cost, not own cost. A feature's own spend understates it: this project's cost-tracking work reported $153.65 for itself against a true cost of $219.78 once the two bugfixes it caused were counted. A third of the bill was one level away.
The one-sentence version
Agentic coding bills you for the conversation you are carrying, so the cheapest possible token is the one you never carry — and the only reliable way to stop carrying it is to keep your state somewhere a session can safely end.