Guides / model mix cost teardown
Model mix cost teardown, from a real month
This is a real month of Anthropic API usage, measured rather than modelled. The cheaper model processed 20% more input tokens and 12 times more output than the frontier model beside it, for 55% of the cost. Culpa, a local-first LLM cost, margin, and forecast ledger, attributes spend per model, which is what turns a model mix into a decision rather than a habit.
Why this happens
A model mix is rarely chosen. It accumulates, one feature at a time, and the shape it settles into gets defended long after anyone examined it. The useful question isn't which model is best, it's what each one is actually doing for the money. That needs two quantities per model rather than one, because a model can be expensive for two completely different reasons: it processes a lot, or it charges a lot for what little it processes. Only the token counts beside the cost share tell you which.
What this usually looks like
- Your most expensive model is assumed to be your busiest and nobody has checked.
- Model choice per feature was made once and has never been revisited.
- Cost is reported per model and token volume isn't, so the two can't be compared.
- One model's output is a rounding error against its input and nobody finds that odd.
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 |
|---|---|---|
| Reading a model's cost share as a measure of how much work it did. | Rate and volume both move it, so a costly model can be doing very little. | Put input and output token counts next to the cost share. The gap between them is the finding. |
| Ignoring the output-to-input shape per model. | It tells you what the model is being used for, and a tenfold difference in shape means two different jobs. | Compute output as a share of input per model, and check it matches what you think that model does. |
| Assuming the frontier model earns its rate because it's the frontier model. | The premium is paid per token whether or not the task needed the capability. | Sample the work each model is doing and test whether the cheaper one handles the easy majority. |
Run this check tonight
- Export a full month and total input and output tokens per model.
- Put each model's cost share beside its token counts and read the two together.
- Compute output as a share of input per model. A large spread means different jobs, not different quality.
- Find the model with the highest cost share and the lowest token volume. Ask what it's for.
- Sample that model's actual requests and test whether a cheaper one handles them.
Two models in one real month, side by side
The same single month of Anthropic API usage, taken from the provider's usage export and aggregated with account identifiers stripped. Token counts are the provider's figures and cost is shown as a share of the month rather than in dollars.
The expensive model wasn't busier, it was doing a different job: reading a great deal and saying almost nothing. That shape is what a code or agent workload looks like, and it's the one where a frontier rate applies to every token read.
Every number, with its confidence and source
| Figure | What it means | Confidence | Source |
|---|---|---|---|
| 54.7% | share of one real month's model cost taken by the frontier model on this account | provider-reported | Anthropic usage export for the month, per-model cost aggregated by scripts/analyse-usage-export.py and expressed as a share of the month. Account identifiers stripped on load. |
| 30.3% | share of the same month taken by the small model, which processed more tokens | provider-reported | The same export and aggregation, per-model cost as a share of the month. |
| 12.2x | measured ratio of the small model's output tokens to the frontier model's | calculated | 2,480,090 output tokens divided by 202,854, both from the provider's usage export. |
| 3.4% and 34.6% | output as a share of input for the frontier model and the small model | calculated | 202,854 / 5,971,879 and 2,480,090 / 7,172,016, from the export's token counts. |
What a generic answer can’t know
A provider can tell you what each model cost and has no idea which of your features sent the work or whether a cheaper model would have done it. Putting cost share, token shape and the feature behind them in one view is your side of the problem. Culpa does it on your infrastructure, keeps your prompts and responses there, and counts the calls to run your plan.
Questions founders ask next
Does a higher cost share mean a model is doing more work?
No, and this month is a measured counter-example. The frontier model took the larger share of cost while processing fewer input tokens and a small fraction of the output, because its rate is several times higher per token rather than because it did more.
What does a low output-to-input ratio tell you?
That the model is reading far more than it writes, which is the signature of code work, agent steps and retrieval-heavy tasks. It matters for cost because input volume then sets the bill, so a frontier rate applies to a very large number of tokens the user never sees.
How do I decide whether to move work to a cheaper model?
Sample the actual requests going to the expensive one and run them through the cheaper one, then score the outputs you care about. The token counts tell you how much is at stake and only your own evaluation tells you whether the quality holds.
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.
How Culpa works
Find the culprit. Not just the total.
Your dashboard shows what you spent. It stops short of who spent it. Culpa shows the conversation, the user and the feature behind it.
Your prompts stay local.
Culpa runs on your own infrastructure. What you send to a model reaches us at no point.
Every dollar has a name.
Follow any charge to the conversation, the user, the feature and the customer behind it.
See the bill before it lands.
Cost your next feature before you ship it. You get the likely bill and the worst case, at best, median, p90 and p99.
Three steps to your first answer.
Change one base URL.
Or drop in the Python or TypeScript library.
Find your most expensive conversation.
In the first session, not the first week.
Cost your next feature before you ship it.
Why the bill went up
Example dashboardCalls traced
418,209
across 3 projects
Spend this week
$378.41
+ $182 vs last week
Failed calls
312
74% retried, and you paid for all of them
+ $182 this week traced to one culprit
Spend over 14 days
Most expensive users
Next week forecast
Graded against reality. Accuracy shown as results land.
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-02. Plain text version.