Guides / agent fan out cost
Agent fan out cost, and why one request becomes thirty calls
Agent fan out is the gap between one user request and the many model calls an agent makes to satisfy it. Cost scales with steps, not requests, so a modest request count can carry a large bill. Culpa, a local-first LLM cost, margin, and forecast ledger, traces every step in a run back to the conversation that started it.
Why this happens
An agent loop plans, calls a tool, reads the result, and decides again. Each decision is a model call, and each one carries the whole accumulated transcript as input. So the cost of step ten isn't the cost of step one, it's much larger, because the input has been growing the entire time. Teams size agent budgets from request volume, which is the one number that doesn't track the spend.
What this usually looks like
- Your agent feature has modest request volume and dominates the bill anyway.
- Cost per request varies wildly between runs, because step count varies and nobody bounds it.
- A single run occasionally costs many multiples of the median, and nobody can say which one or why.
- Adding one tool to the agent raised spend across every run, not only the runs that used it.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Mistakes that cost the most
| Mistake | Why it hurts | Do instead |
|---|---|---|
| Budgeting an agent from request count. | Requests aren't the billing unit. Steps are, and step count is the variable nobody bounded. | Budget from steps per run times cost per step, and track the 90th percentile step count, not the mean. |
| Running the whole loop on a frontier model. | Most steps in an agent run are routing and tool selection, which rarely need frontier reasoning. | Route the planning step to the strong model and the mechanical steps to a small one, then measure both. |
| Leaving the loop unbounded so it can finish hard tasks. | The rare runaway run costs more than all the successful runs it was meant to rescue. | Set a hard step ceiling and a per-run spend ceiling, then treat hitting either as a signal to investigate. |
| Adding tool definitions to every call in the loop. | Tool schemas are input tokens, and in a thirty-step run you pay for them thirty times. | Trim schemas to what the step can actually use, and keep the stable block cacheable. |
Run this check tonight
- Count model calls per agent run for your last hundred runs and read the maximum, not the average.
- Price your longest run on its own. On most agents it's a startling number.
- Check whether a hard step ceiling exists in code. If not, your worst case is unbounded by construction.
- Measure how much of each step's input is the accumulated transcript rather than new information.
- Split spend by step type. If routing steps cost as much as reasoning steps, your model routing is the fix.
A twelve-step agent run, priced step by step
Illustrative example
An agent on Claude Opus 4.8 at real rates, $0.005 per 1k input and $0.025 per 1k output. The run starts with a 2,000-token context and each step adds about 600 tokens of transcript. Each step returns 250 tokens.
About thirty-nine cents for one request, and the back half of the run costs almost twice the front half purely because the transcript kept growing. Step count is the lever, not request count.
Every number, with its confidence and source
| Figure | What it means | Confidence | Source |
|---|---|---|---|
| $0.39 | modelled cost of one twelve-step agent run on a frontier model | calculated | Sum of twelve steps with input growing 2,000 to 8,600 tokens, priced at Claude Opus 4.8 rates per 1k tokens from the price book, effective 2026-07-02. Step profile is modelled. |
| $0.14 to $0.39 | cost range for the same run capped at six steps versus twelve | estimated | Both endpoints from the teardown arithmetic above, at real Claude Opus 4.8 rates. A range because real step counts vary per run. |
What a generic answer can’t know
A provider sees twelve unrelated calls. It has no idea they were one agent run serving one user, because the run only exists as a concept inside your application. Grouping them needs a run identifier attached at request time. Culpa captures that on your infrastructure, keeps your prompts and responses there, and counts the calls to run your plan.
Questions founders ask next
Why does agent cost grow faster than agent step count?
Because each step carries the accumulated transcript as input. Step ten pays for everything that happened in steps one through nine, so cost grows roughly with the square of the step count rather than linearly.
How do I cap agent cost without breaking hard tasks?
Set a per-run spend ceiling rather than only a step ceiling. A spend ceiling lets a cheap thirty-step run finish while stopping an expensive eight-step one, which is usually the behaviour you actually wanted.
Should every agent step use the same model?
Rarely. Planning and final synthesis benefit from a strong model. Tool selection, routing and formatting usually don't. Splitting them is often the single largest saving available on an agent, and it's measurable within a day.
On your infrastructure
Culpa runs on your infrastructure. Your prompts and responses never leave it. Culpa counts calls to run your plan, and it fails open, so if it ever breaks your app keeps running.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Keep reading
Sources: Anthropic pricing. Last reviewed 2026-08-01. Plain text version.