Guides / provider switching cost
What it costs to move models, beyond the rate card
Comparing rate cards is the easy part of a migration and the smallest part of the cost. The same text produces different token counts on different tokenizers, so your volumes change along with your rates. Culpa, a local-first LLM cost, margin, and forecast ledger, prices your real traffic against a versioned price book so both sides move together.
Why this happens
Every migration starts with a rate comparison, and a rate comparison assumes the only thing changing is the price per token. It isn't. Token counts are a property of the tokenizer, not of your text, and Anthropic publishes the clearest illustration of this within its own range: Claude 4.7 and later use a newer tokenizer that produces approximately 30% more tokens for the same text than earlier models. That's a model-family change inside one provider, with the numbers stated. Moving between providers changes the tokenizer too, and none of them publish a comparison, so the honest position is that your volumes will move by an unknown amount and you have to measure it rather than model it. Everything else in a migration compounds that. Prompts tuned for one model rarely transfer unchanged, evaluation has to be re-run to know whether quality held, and any period of dual-running means paying both providers at once for whatever share of traffic you shadow.
What this usually looks like
- Your migration business case compares rates and nothing else.
- Nobody has measured what your own prompts tokenize to on the target model.
- Prompts were ported unchanged and quality moved in ways nobody priced.
- Dual-running was planned and its cost was never added up.
- Post-migration spend came in above the rate comparison and nobody can say why.
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 |
|---|---|---|
| Comparing rate cards and calling it a business case. | Rates are per token and your token count changes with the tokenizer. | Tokenize a real sample of your own traffic on both models before deciding. |
| Assuming the same text costs the same tokens. | Anthropic publishes roughly 30% more tokens for identical text across its own model generations. | Measure your volumes on the target, and re-price at its rates using those volumes. |
| Leaving dual-running out of the migration cost. | Shadow traffic is paid twice, and migrations run longer than planned. | Budget the overlap explicitly, at the traffic share and duration you actually expect. |
| Porting prompts unchanged to save effort. | Prompts tuned for one model produce different output lengths on another, which moves cost as well as quality. | Re-tune and re-evaluate, and price the output length that comes out of it. |
Run this check tonight
- Take a real sample of your traffic and tokenize it on both the current and target model.
- Re-price your monthly volume using the target's token counts, not your current ones.
- Add the dual-running period at the traffic share you'll actually shadow.
- Check whether your prompts assume behaviour specific to the model you're leaving.
Same text, more tokens
Illustrative example
Anthropic states that Claude 4.7 and later models use a newer tokenizer producing approximately 30% more tokens for the same text, and that Claude Sonnet 4.6 and earlier use the previous one. Take a modelled 100 million input tokens a month as measured on the older tokenizer, and price the identical text after the shift at Claude Sonnet 5's real introductory rate of $2.00 per million. The volume is modelled, the tokenizer statement and the rate are published.
Nobody changed a price and nothing about the workload moved. A rate comparison would have shown these two as identical. This is within one provider's own range, with the figure published. Across providers the same effect exists and nobody publishes the number, which is the argument for measuring your own traffic rather than modelling it.
Every number, with its confidence and source
| Figure | What it means | Confidence | Source |
|---|---|---|---|
| $260.00 against $200.00 | modelled monthly cost of identical text before and after a published tokenizer change | calculated | Anthropic's pricing page states that Claude 4.7 and later use a newer tokenizer producing approximately 30% more tokens for the same text, with Claude Sonnet 4.6 and earlier on the previous one. A modelled 100 million input tokens becomes approximately 130 million for identical text, and at Claude Sonnet 5's real introductory rate of $2.00 per million from the price book effective 2026-07-02 gives $200.00 against $260.00. The tokenizer statement and the rate are published, the volume is modelled. |
What a generic answer can’t know
What your traffic tokenizes to on a model you don't run yet appears on no pricing page, and it's the number the decision turns on. It depends on your own text: the language, the formatting, how much of it arrives as code or structured data. Culpa prices your actual calls from a versioned price book in exact decimal and keeps the token shapes alongside the costs, so a migration case can be built from the traffic you served rather than from an assumed average. Because the book is versioned by effective date, the same ledger prices the period after the move at the rates that apply to it, and the forecast that supported the decision can be scored against what actually happened.
Questions founders ask next
Is comparing rate cards enough to plan a migration?
No, because rates are per token and token counts change with the tokenizer. Anthropic publishes roughly 30% more tokens for the same text between its own model generations, which is a 30% cost move from a rate card that didn't change. Measure your own traffic on the target.
How much do token counts differ between models?
Within Anthropic's range the published figure is approximately 30% more tokens on Claude 4.7 and later than on earlier models, and the exact increase depends on the content. Across providers the same effect exists, no one publishes a comparison, so the only honest answer is to tokenize your own sample.
What else does a migration cost?
Re-tuning prompts, re-running evaluation to confirm quality held, and dual-running. The overlap is the one people forget: shadow traffic is paid to both providers at once, and migrations tend to run longer than the plan allowed for.
How do I build a defensible migration case?
Tokenize a real sample of your traffic on both models, re-price your monthly volume using the target's counts rather than your current ones, and add the dual-run period at the traffic share you'll genuinely shadow. That gives a number you can be held to rather than a rate ratio.
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-05, rates effective 2026-07-02. Plain text version.