Guides / blended rate
What is a blended rate?
A blended rate is your average cost per thousand tokens across every model you run, weighted by how much traffic each one takes. It's one number for a mixed fleet. Culpa, a local-first LLM cost, margin, and forecast ledger, prices each call at its own model rate first and blends afterwards, so the average never hides which model moved.
Why this happens
A blended rate is genuinely useful for one job, forecasting a bill when your model mix is stable. It's actively misleading for the other job teams use it for, deciding what to optimise. The number moves for two completely different reasons, a rate change or a mix change, and it looks identical either way. A team whose blended rate rose 30% can't tell from that figure alone whether prices went up or whether traffic shifted to a pricier model.
What this usually looks like
- Your blended rate moved and nobody can say whether the cause was a mix shift or a price change.
- A cheap model handles most of your calls, so the blend looks reassuring while a frontier model carries the actual spend.
- Forecasts built on last quarter's blend miss badly after a routing change nobody flagged as a cost event.
- Two teams quote different blended rates for the same month because they weighted by calls rather than by tokens.
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 |
|---|---|---|
| Weighting the blend by call count instead of token volume. | A million tiny classification calls and a thousand long generations weight equally, which makes the blend meaningless. | Weight by tokens, and blend input and output separately because their rates differ by several times. |
| Using one blended rate to forecast after a routing change. | The blend describes the mix that produced it. Change the mix and the blend describes history, not the future. | Forecast per model with its own rate and volume, then blend the result for reporting only. |
| Reporting a single blended rate across input and output. | Output bills several times input on most models, so a combined blend hides the lever that would actually cut the bill. | Publish two blended rates. The gap between them tells you which side of the call to work on. |
Run this check tonight
- Compute your blended input rate weighted by input tokens, then your blended output rate weighted by output tokens.
- Compare each against the list rate of the model carrying most of your tokens. Large gaps mean your mix is doing the work.
- Recompute last month's blend using this month's mix. The difference is the part of any change caused by routing, not pricing.
- Check the share of tokens on your single most expensive model. That percentage moves the blend more than anything else.
- Ask whether a blend is the right tool for the decision in front of you, or whether you need the per-model numbers.
A stable blended rate hiding a 60% cost increase
Illustrative example
Two months, same blended input rate, very different bills. Real rates: Claude Haiku 4.5 at $0.001 per 1k input, Claude Sonnet 5 at its introductory $0.002 per 1k input. Token volumes are modelled.
Same traffic, same list prices, a 36% larger bill. The blended rate did move, from $0.0011 to $0.0015, but only the per-model split explains why.
Every number, with its confidence and source
| Figure | What it means | Confidence | Source |
|---|---|---|---|
| $0.0011 to $0.0015 per 1k | modelled blended input rate before and after a mix shift at identical token volume | calculated | Weighted averages of real Claude Haiku 4.5 and Claude Sonnet 5 input rates from the price book, effective 2026-07-02. Token splits are modelled, arithmetic shown in the teardown. |
| 36% | bill increase caused by mix shift alone, with volume and list prices unchanged | calculated | ($15 - $11) / $11, from the two monthly totals in the teardown. |
What a generic answer can’t know
A blended rate computed from an invoice tells you what happened to the average. It can't attribute the move to a specific routing decision, because the invoice doesn't know your routing rules existed. Separating a mix shift from a price change needs per-call model attribution over time. Culpa records that on your infrastructure, keeps your prompts and responses there, and counts the calls to run your plan.
Questions founders ask next
Is a blended rate useful at all?
Yes, for forecasting a bill when your mix is stable, and for communicating one headline number to people who don't need model detail. It stops being useful the moment you try to make an optimisation decision from it.
Should I blend input and output into one rate?
No. Output bills several times input on nearly every model, so a combined blend averages away the single biggest lever you have. Publish both, and the gap tells you where to look.
How often should I recompute the blend?
Whenever your routing changes, not on a calendar. A blend recomputed monthly will lag a mid-month routing change by weeks, and that lag lands exactly when you most want an accurate forecast.
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.