What It Costs

A coding agent has three meters, and only one of them sends an invoice. Tokens are what the provider counts. Plan limits decide when work stops. Review time is what the team actually spends, and on most teams it is the largest of the three by a wide margin.

This page treats all three as mechanisms, because mechanisms outlast price lists. The prices of the month, plan by plan, are in Chapter 15. What a session costs, why, and which habits lower it are the same whichever tool you use.

Tokens Are the Unit

The model has no memory between turns, as Chapter 4 explained, so every turn sends the whole context again: the project instructions file, every file read so far, the conversation and every test run's output. A session's cost therefore grows with the size of its context multiplied by the number of turns. The 30th turn of a long session is not one more turn like the 3rd; it carries everything the first 29 accumulated.

The chart shows the shape for an illustrative session the size of the refund change from Chapters 5 to 9: 38 turns, starting from about 10,000 tokens of instructions and files and adding about 2,200 per turn as the agent reads code and runs tests. Turn 3 sends about 17,000 tokens. Turn 30 sends about 76,000, four and a half times as many, for a reply of the same length. Over the session the agent sends about 2 million input tokens, most of them in the last third.

Providers soften this. As of 2026 the main providers bill context that was sent before and cached at a fraction of the normal input rate, one tenth on some models, so a stable prefix of instructions and files costs much less on the second turn than on the first. That softens the curve. It does not flatten it: new material is billed in full, the cache expires when a session sits idle, and the context still has to fit in the window.

Plans and Limits

Three billing shapes cover the market as of 2026. A subscription with usage limits that reset on a window, typically some hours plus a weekly ceiling. Credits or metered usage, drawn down per request or per token from a monthly allowance, with more available at a price. And per-token billing on a provider's interface for developers, with no ceiling except the one you set.

A limit is a mechanism, not just a price. A session that hits its limit mid-task stops, with whatever half-finished edits it had made sitting in the working tree. If you committed before the request, as Chapter 9 insists, that is an annoyance: you discard the half-done change, wait for the window, and start again from a known state. If you did not, you are untangling a partial change by hand. Larger models draw down the same allowance faster, so the choice of model is also a choice of how many tasks fit in the window.

In the month Cragmoor counted, Kai hit the window twice, both times late in long feature sessions. Both times he had committed before the request, so he lost only the step in progress, and both times the fresh session he started afterwards finished that step in fewer turns than the long one had spent failing to.

What Makes a Task Expensive

Five habits drive the token meter, and the book has already named all of them for other reasons. Large contexts: a pasted 3,000-line log, or a whole file read where one function would do. Circling, from Chapter 10: the same fix attempted three times costs three times and buys nothing. Vague tasks that need many rounds of correction, the opposite of Chapter 5's task an agent can finish. Test runs that print thousands of passing lines into the context on every run. And parallel agents, from Chapter 9, which multiply every meter at once.

The cheap habits are the quality habits. Point at files instead of pasting them, as Chapter 4 described. Ask for small steps. Make the test command report only failures, so a run of 900 tests that all pass costs one line instead of 900. None of these were invented to save money, and all of them do.

The Meter Nobody Reads: Review

Kai's waitlist was about 1,400 lines written in one afternoon. The tokens for that afternoon cost less than an hour of an engineer's time. Reading 1,400 lines carefully takes a careful engineer more than a day. That day was never spent, and the third week of Chapter 2 followed from it: nobody had read the code that later offered one place to two people.

This is the meter that decides whether an agent makes a team faster. Generation that outruns the team's capacity to review does not speed anything up. It builds a queue of unread code, and the queue gets merged eventually, read or not. A team that budgets agent work in tokens and not in review hours is budgeting the cheap meter and ignoring the expensive one.

Rework

The double offer that surfaced in the waitlist's third week cost more than every token the team spent that quarter. Engineers had to trace it first, which is the story of Chapter 10. They fixed it, tested it and shipped the fix. And someone had to write to the members who had been offered the same place twice and explain why one of them could not have it.

So the cost of a change is generation, plus review, plus whatever review missed. The third term is invisible when the change merges and arrives weeks later with someone else's name on the incident. That delay is why teams consistently underestimate it.

Counting It

Cragmoor counts a month of agent-assisted tasks with five numbers per task: the usage the tool reports, the wall-clock time from task to pull request, the review time, the number of review rounds, and any rework traced back to the change within a month. The tally below is the team's own, and the numbers feed the next topic's question of whether the tool helps at all.

Kind of task	Tasks	Tokens reported	Writing the task and generating	Review	Rework within a month
Small fixes	18	9 million	6 h	9 h	1 h
Features	7	31 million	11 h	27 h	6 h
Tests and fixtures	12	14 million	5 h	10 h	0 h
Refactors	4	8 million	3 h	8 h	2 h
Month	41	62 million	25 h	54 h	9 h

Review is more than twice the time spent writing tasks and generating, and features dominate it. The rework column is small this month and is not small every month; one bad merge can double it. The token column, whatever its price in Chapter 15, is the only one that arrives as an invoice.