# Model mix cost teardown, from a real month > A real month, measured. The small model processed more input and twelve times more output than the frontier model beside it, for 55% of the cost. URL: https://getculpa.com/model-mix-cost-teardown Last reviewed: 2026-08-02 ## Answer 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. ## Common mistakes - Reading a model's cost share as a measure of how much work it did. Why it hurts: Rate and volume both move it, so a costly model can be doing very little. Do instead: 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. Why it hurts: It tells you what the model is being used for, and a tenfold difference in shape means two different jobs. Do instead: 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. Why it hurts: The premium is paid per token whether or not the task needed the capability. Do instead: Sample the work each model is doing and test whether the cheaper one handles the easy majority. ## Self-check - 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. Haiku 4.5: 7,172,016 input tokens and 2,480,090 output tokens Opus 4.8: 5,971,879 input tokens and 202,854 output tokens Haiku processed 20% more input and 12.2 times more output Cost share: Opus 4.8 took 54.7% of the month, Haiku 4.5 took 30.3% So the cheaper model did more work for 55% of what the frontier model cost Output as a share of input: Opus 3.4%, Haiku 34.6%, a tenfold difference in shape 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. ## Cost figures Every figure carries its confidence and its source. No figure on this site is provider-reported. - 54.7% — share of one real month's model cost taken by the frontier model on this account [provider-reported] Source: 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] Source: 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] Source: 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] Source: 202,854 / 5,971,879 and 2,480,090 / 7,172,016, from the export's token counts. ## FAQ Q: Does a higher cost share mean a model is doing more work? A: 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. Q: What does a low output-to-input ratio tell you? A: 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. Q: How do I decide whether to move work to a cheaper model? A: 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. ## Sources - Anthropic pricing: https://platform.claude.com/docs/en/docs/about-claude/pricing Run the free Cost Leak Scan: https://app.getculpa.com/scan?source=pseo&slug=model-mix-cost-teardown&cluster=teardown Machine-readable index of every guide: https://getculpa.com/api/pages Human-readable index of every guide: https://getculpa.com/guides Site overview: https://app.getculpa.com/llms.txt Privacy: 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.