Everyone discusses whether an AI agent is worth it. Almost no one publishes the bill.

I have one. The foundation of this blog — requirements, architecture, ten ADRs, the mockups, and the content contract — was built by a multi-agent cycle with a committee of seven automatic reviewers and a cutoff score of 9.5. It was three rounds and about 6.67 million tokens, with consumption noted by stage in the repository itself while it was happening.

This post opens that spreadsheet. It is not a model benchmark, and it is not a promise that your number will be this one: it is a measurement of one case, with the method stated and the numbers reproduced in this text. The project repository is private; because of that, the scorecards cited do not open for the reader.

The number, and where it comes from

The values were noted at the end of each round in the scorecards versioned under docs/testes/ — the same files that record the committee’s scores. They are values reported by the subagents, not an invoice extracted from the billing dashboard. That distinction matters, and it comes back at the end of the post.

What the 6.67 million bought: 21 foundation artifacts (a requirements document, an architecture document, ten ADRs, the pipeline specification, five mockups, the design tokens file, and the ad component), reviewed by seven independent lenses — software architecture, data architecture, development, design, QA, security, and innovation — plus a process auditor, until all of the lenses passed 9.5.

Where the tokens went, round by round

Where the tokens went, round by round
RoundConsumptionResult
R1≈ 1.97Mfailed
R2≈ 2.04Mfailed (average +1.55)
R3≈ 2.66Mpassed — all seven lenses ≥ 9.5

The stage-by-stage detail is more interesting than the total. In R2:

  • corrections of the previous round’s findings: ≈ 785k
  • smoke gate + cheap correction: ≈ 236k
  • the seven lenses in delta mode: ≈ 922k
  • process auditor: ≈ 101k

In R3:

  • corrections: ≈ 919k
  • smoke gate + pre-review corrections: ≈ 393k
  • the seven lenses in strict verification: ≈ 652k
  • re-verifications: ≈ 359k
  • post-review corrections (four, on a small model): ≈ 186k
  • auditor: ≈ 147k

Notice what the table shows: the review is not the most expensive item. Adding corrections and re-verifications, the work of fixing what was pointed out cost more than pointing it out. Anyone who only looks at the reviewer’s price is looking at the cheap half of the bill.

The cheap gate paid off; “delta” mode did not

Two process changes were tested with the explicit intention of making the cycle cheaper. One worked, the other did not — and the one that did not work is the more instructive.

What worked: the smoke gate before the lenses. A quick, mechanical check (do the declared files exist? does the text match the code? is there a dead link?) running before the expensive reviewers. In R1, without that gate, trivial defects were rediscovered by three different lenses, each spending context to reach the same conclusion. In R2, with the gate, one correction closed for 34 thousand tokens on a small model. The same defect, by the previous path, was paid for three times on a large model.

What did not work: reviewing only the diff. The idea was obvious — if the previous round had already read everything, the next one only needs to look at what changed. In practice, the seven lenses in delta mode cost 922k, practically the same as a full evaluation. They did not use the savings to finish sooner; they used the slack to attack the diff in more depth. The result was good — it just was not cheap. A saving the model can spend on quality is not a saving, it is a reallocation.

What actually cut the cost of the review was changing the instruction, not the scope: in R3, the lenses ran in strict verification mode (check these specific pending items, do not reassess the world) and cost 652k — about 30% less than delta mode.

And the highest-return item in the whole cycle: the pair cheap correction + re-verification with the context preserved. Four pending items closed for ≈ 545k combined, which avoided a full fourth round. One round cost more than 2 million tokens. Spending 545 thousand in order not to spend 2 million is the kind of decision that shows up only if you are measuring.

The waste has a name: 378 thousand tokens

The item I like most in the record is the one that went wrong.

Inside the 919k of R3 corrections there are ≈ 378 thousand tokens in two duplicate retries, triggered by a hasty diagnosis: I concluded that the internet had gone down and ordered a redo. It had not gone down. The work was already underway and was redone on top of itself, twice.

That is 5.7% of the whole cycle burned on a wrong guess about infrastructure. It was not the model that got it wrong, and it was not the prompt: it was the operator reacting to silence. An agent that takes a long time is not a stuck agent, and the difference between the two costs real money.

The fix is tedious, and it works: before ordering a redo, confirm that the thing actually stopped.

And in dollars, how much was it?

Here the honest answer is a range, not a number — and the reason is the most useful lesson in this post.

At the list prices Anthropic publishes today, Claude Opus 5 costs US$ 5 per million input tokens and US$ 25 per million output tokens. Applying that to the 6.67 million:

  • if everything were input: ≈ US$ 33
  • if everything were output: ≈ US$ 167

The real number sits somewhere in that fivefold range, and I cannot point to where. Because I noted the total, not the split between input and output — and not how much ran on a small model. Part of the cycle ran on Haiku, which costs one fifth of Opus on input, so the true floor is even lower; and none of this considers prompt cache, which offsets a good part of the repeated reading.

In short: I instrumented enough to know where the effort went, and not enough to know what it cost. Process can be decided with what I have. A budget cannot be closed.

If you are going to measure an agent, measure in money from day one: input and output separate, by model, by stage. A token is a unit of effort; money is a unit of decision. Converting from one to the other afterward works only if you kept the split — and I did not keep it.

What I would change before the next cycle

  1. Record input, output, and model by stage. Three more columns in the same note I was already keeping, and the fivefold range becomes a number.
  2. A mechanical gate before an expensive reviewer. What a script can reject should not reach the large model.
  3. A narrow instruction instead of a narrow scope. Saying “check these pending items” cuts cost; saying “look only at the diff” does not.
  4. Cheap correction with contextual re-verification. It is cheaper to fix and recheck than to open another full round.
  5. Do not react to silence. Confirm that it is stuck before ordering a redo — the duplicate retry was the most expensive and most avoidable spend in the cycle.

None of these items is about choosing the right model in isolation, though recent architectures built for agent swarms and aggressive context caching are beginning to relieve this economic bottleneck at the infrastructure layer. All of them are about the process around it, which is where the bill actually takes shape.

Sources

  • R2 consumption by stage (785k corrections · 236k gate + cheap correction · 922k lenses in delta · 101k auditor; total ≈ 2.04M) and the recorded lesson that delta mode did not make the lenses cheaper — committee scorecard, round 2 (internal project record), verified on 2026-08-10.
  • R3 consumption by stage (including the ≈ 378k of duplicate retries), the cycle total at ≈ 6.67M, and the measurements of −30% for strict verification and of the ≈ 545k that avoided a fourth round — committee scorecard, round 3 (internal project record), verified on 2026-08-10.
  • Price per million input and output tokens of the current models — model overview, Anthropic (official documentation), verified on 2026-08-10.
  • Declared methodology: the token numbers are values reported by the subagents and noted at the end of each round, not an extraction from the billing dashboard. The conversion to dollars is a range I calculated from the list prices above, not an invoice.