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 blended rate that moved 36% without saying why
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.
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.
Keep reading
Sources: Anthropic pricing. Last reviewed 2026-08-01. Plain text version.