Lesson 03. The Cost Model Picks Your Topology Before You Do

Anchorwell moved from one agent to three running in parallel for a two-week product push, because three agents finishing three tickets sounded like three times the output. The month's invoice climbed well past what a single agent had ever cost, model spend and sandbox time together. The number of pull requests that actually merged that month barely moved: a couple more than the month before, not three times more. Half of what the three agents attempted was abandoned mid-run, superseded by a second attempt at the same ticket, or rewritten after review found it had guessed at an interface Lesson 02 would have caught. Nobody at Anchorwell could say what a merged change had cost, only what the fleet had cost, and those turned out to be very different numbers. Decide now: when you divide this month's spend, what do you divide it by, attempted diffs or the ones that actually landed?

This lesson's deliverable is fleet/cost-model.md, cost per landed change for your fleet, with the crossover that picks your venue. It is the third document of Scope: the number that tells you whether adding an agent is worth what it costs, before you add one.

What is actually going on

A fleet's spend runs on two separate meters, and treating them as one is the first mistake. Inference tokens are billed per call, and parallel agents multiply that meter directly: three agents drafting three tickets pay for three drafts, three sets of tool calls, three retries. A cold restart multiplies it again, less obviously. Prompt caching prices a write at a premium over plain input, 1.25 times for a five-minute cache and 2 times for a one-hour cache, and only pays that premium back on a later read, priced at a tenth of plain input on most current models (Anthropic prompt caching docs, observed 2026-09-13). An agent spun up fresh for every short task writes that premium every time and never collects the discount, because nothing ever reads what it wrote. Compute time is the second meter, and it belongs only to whatever runs off your own machine: a sandbox, a remote VM, a managed cloud agent. It bills on wall-clock existence, not on activity, so a sandbox idling between an agent's turns costs the same as one doing useful work.

Neither meter tells you what you actually want to know, which is what a merged change costs. The picture below plots cost per landed change against agent count for a fleet whose review capacity does not grow with it. Look at where the line bends, not at how high it starts.

Illustrative composite. The curve is modeled from Anchorwell's own per-task price (below), extended to agent counts they have not actually run, holding review capacity fixed. It is a teaching device, not measured data.

diagramsource

drawing

The line barely moves from one agent to two, because at that scale most of what gets attempted still gets reviewed and merged. Past that point, attempted work keeps growing while landed work does not, because review capacity is the thing that never scaled in this picture. The bend is not a token-pricing effect. It is Module 4's ceiling arriving early, priced in dollars instead of in days.

The rule and its condition

Budget per landed change, never per agent-hour and never per token. Divide total spend, both meters together, by the count of changes that actually merged in the period, not the count attempted. Abandoned runs are the dominant cost of an immature fleet, and a denominator of attempted work hides exactly that cost. The two meters also behave differently enough that they need separate handling before you ever sum them.

	Token-metered	Compute-metered
Who bills this way	Model API calls; some subscriptions bill an opaque rolling budget instead	Sandboxes and VMs: a fleet running off your own machine
What multiplies it	Agents in parallel; a cold restart paying the cache-write premium again with no read to redeem it	Wall-clock existence; idle time between an agent's turns bills the same as active work
Where it hides	A prompt reordered so a volatile line sits before the cache breakpoint, turning every call into a write	A sandbox left running after a task finishes, because nobody tore it down
The lever	Reuse one warm session instead of respawning; verify hits with the cache-read field	Tear down on completion, or pick a venue billed by the call rather than by the hour

Worked case

Anchorwell's engineer who ran the push wrote the numbers down properly, and it settled the argument that had started this lesson.

Illustrative composite. Anchorwell ran three agents in parallel on Claude Sonnet 4.6, priced at $3 per million input tokens and $15 per million output (Anthropic API pricing, observed 2026-09-13; the newer Sonnet 5 lists lower, at $2 and $10), across twenty working days. Each agent attempted about two tasks a day, 120 attempted tasks for the month, averaging 100,000 tokens each at a 70/30 input-to-output split, with a 4% retry rate and no caching yet. Sandboxes ran on E2B's default 2 vCPU / 4 GiB configuration, billed at $0.1656 an hour wall-clock, for an average five hours per task including idle time waiting on review (E2B pricing, observed 2026-09-13).

The arithmetic, one task at a time: 70,000 input tokens at $3 per million is $0.21; 30,000 output tokens at $15 per million is $0.45; sum $0.66, times the 4% retry factor is about $0.69 in tokens. Sandbox time adds five hours at $0.1656, about $0.83. Call it $1.52 per attempted task. Over 120 attempted tasks, that is roughly $182 for the month, tokens and compute together.

Of those 120 attempts, 28 landed as merged changes; the rest were abandoned mid-run, superseded by a second attempt at the same ticket, or rewritten after review. Cost per attempted task: $182 divided by 120, about $1.52. Cost per landed change: $182 divided by 28, about $6.50. The month before, one agent working alone had attempted 30 tasks at the same per-task rate with no sandbox meter running (it worked directly on a laptop), and 24 of those 30 landed: about $21 in tokens, or roughly $0.86 per landed change. Landed output rose by four changes. Cost per landed change rose more than seven times.

That gap is the entire argument for dividing by landed changes instead of attempted ones. It is also, separately, an argument for the caching discipline from the first section. Say Anchorwell's three agents share an 8,000-token system prompt and repository context on every task. Ten fresh, short-lived sessions each pay the 1.25 write multiplier on that prefix and never read it back, since each session ends before another one starts: ten times 8,000 tokens at 1.25, about 100,000 effective input tokens, with nothing to redeem the premium. One longer-lived session that writes the same prefix once at the 2 one-hour multiplier and lets ten task turns read it at 0.1 instead: 16,000 effective tokens for the write plus 8,000 for the ten reads, 24,000 total. Roughly four times cheaper on the shared-prefix portion alone, before counting each task's own unique work, purely from not respawning (Anthropic prompt caching docs, observed 2026-09-13).

A spend cap that auto-suspends is the safety rail underneath all of this arithmetic, not a replacement for it. At least one coding-agent vendor enforces a hard cumulative cap per session: a session is suspended the first time it reaches $100 of spend, and stays suspended until someone confirms in that session's web UI that it should continue, rather than trusting a runaway loop to notice its own bill (Blacksmith pricing and FAQ, observed 2026-09-13). A cost model tells you what a landed change should cost; a cap is what stops an unattended run from finding out the hard way what it costs when something goes wrong.

Illustrative composite. The crossover Anchorwell actually faced was between this metered setup and buying more subscription seats. Individually, the four engineers had been on Claude Pro at $20 a month each, $80 total, for single-agent use. Provisioning three concurrently-running Max 20x seats at $200 each to cover the push would have run $600 a month (Claude pricing, Max 20x observed 2026-09-11, Pro observed 2026-09-13), and a subscription's budget is a single-seat pool, so a colleague's idle seat cannot cover another engineer's third agent mid-sprint. Metered API plus sandbox compute came to about $182 for the same two weeks. As a rule of thumb, not a vendor number: once running N agents in parallel for enough active hours pushes metered-equivalent spend past a subscription tier's monthly price for three or more consecutive days, metered API and owned or rented compute is the cheaper venue, because subscription tiers jump in fixed multiples while metered spend tracks actual use continuously. Anchorwell's own crossover sat well inside that: a two-week burst never justified three permanent Max 20x seats, and the month after the push, with one agent running most days, a single Pro seat was cheaper than staying on metered API.

Faded case

Skip to the open case if this is familiar.

A different kind of task altogether: a scheduled agent that re-checks fifty factual claims in a documentation set against their live sources once a night, unattended, with nobody waiting on the result. Each check is independent: a different claim, a different source URL, nothing shared between them. It runs in a small sandbox for about twenty minutes and reads roughly 200,000 tokens total across all fifty checks on a small, cheap model.

Decide which of this lesson's two levers apply here and which do not: caching, and batch pricing. One of them is free money for this task; the other would add cost with nothing to show for it.

Open case

A five-person team runs two agents in parallel per engineer during a two-week product push, all of them on individual subscription seats at the top tier. The combined monthly bill for those seats is a flat, known number, but partway through the second week, two engineers hit their seat's usage ceiling and their agents sit idle for the rest of the day while a third engineer's seat has room to spare. Write the cost model: name the two meters actually in play here, say what you would divide total spend by, and say whether this is a spend problem or a venue problem.

Where this breaks

Prices move under the model, and a cost model with no date on its price sheet is fiction within a quarter; at least one major coding-agent vendor has changed its entire billing unit inside a single year, from a per-request charge to a per-token one, with no advance notice to customers already modeling costs the old way. Re-date every figure at each sweep, not just once.

The crossover rule of thumb is exactly that, a rule of thumb: it tells you which side of the line you are probably on, not the exact day to switch. Treat a crossover this lesson's arithmetic produces as a trigger to re-measure, not as a number to defend in a budget meeting.

Rate limits cap the concurrency this whole model assumes is available, and they bind before the invoice does: Anthropic's published tiers for Sonnet 5 move from 1,000 requests and 400,000 output tokens per minute on the entry Start tier to 10,000 requests and 2,000,000 output tokens per minute on the highest published Scale tier, ten times the requests but only five times the output, with cached input exempt from the input-token ceiling on most current models (Anthropic API rate limits, observed 2026-09-13). The same tiers carry a monthly spend cap, $500 on Start, and hitting it pauses API access until the first of the next month with a 429 that has no retry-after header, so a retrying agent loop retries into a wall. A fleet sized on cost alone can hit a 429 well before it hits its budget, and that ceiling is per model and per organization, not per agent, so the fifth agent you add can throttle the four that were already running cleanly.

Not every vendor bills the way this lesson's two meters assume. At least one coding-agent vendor prices by a compute-time unit rather than by raw tokens or by a plain hourly sandbox rate, which is a third meter shape worth recognizing on a vendor's price sheet even though this lesson does not model it, since no clearly published conversion rate exists to check it against.

Key Takeaways

• Divide spend by landed changes, never by attempted work or agent-hours.
• Price tokens and compute time as two separate meters; they multiply differently and hide in different places.
• A cold restart pays the cache-write premium with no read to redeem it; a warm, shared session earns the discount back.
• Treat a spend cap that auto-suspends as the safety rail, not the cost model itself.
• Cross to metered API and owned compute once parallel usage beats a subscription tier's price for several consecutive days; treat that line as a rule of thumb, not a vendor number.

What You Have Now

fleet/cost-model.md, cost per landed change for your fleet, with the crossover that picks your venue, sits in your Fleet Kit beside fleet/task-template.md from Lesson 02. It closes Scope's third question: not just whether a task is safe to hand to more than one agent, but whether doing so is worth what it costs. Project 01 prices a full week of your own fleet against this model; Module 3 reads its crossover line when it decides whether a venue off your laptop is worth the move.

Further Reading

• Anthropic prompt caching docs — the write and read multipliers this lesson's arithmetic runs on.
• Anthropic API rate limits — the per-tier ceilings that bind a fleet's concurrency before its budget does.
• E2B pricing — a worked example of compute billed on wall-clock existence rather than activity.
• Blacksmith pricing and FAQ — a real auto-suspending spend cap, as the safety rail this lesson's cost model needs underneath it.

Exercises

1. Price one week of your own fleet's usage: token spend by call, compute spend by wall-clock hour, divided by attempted tasks and then by landed changes. State both numbers and the ratio between them.
2. Find one place in your own setup where a fresh session respawns instead of reusing a warm, cached one. Estimate what moving to one longer-lived session would save on that prefix alone, using the write and read multipliers above.
3. Write your own crossover line: at what parallel agent count, for how many consecutive active hours, does your current venue stop being the cheaper one. State the subscription or venue price you are comparing against and its date.

Check your understanding