Same price, bigger bill: Claude's new tokenizer

Your Claude spend went up by roughly a third and nothing in your code changed. Same prompts, same files, same number of requests. You moved to a newer model, the price table says it costs the same per million tokens — or less — and the usage dashboard agrees with the invoice. The arithmetic still does not.

This is not a price rise. It is a unit change. Anthropic replaced the tokenizer, and a token is now a smaller piece of text than it used to be.

What Anthropic actually says

The pricing page states it plainly. As of 19 October 2026:

Claude 4.7 and later models and Claude Mythos Preview use a newer tokenizer that contributes to their improved performance on a wide range of tasks. This tokenizer produces approximately 30% more tokens for the same text. The exact increase depends on the content and workload shape. Claude Sonnet 4.6 and earlier models use the previous tokenizer.

The Opus 5.5 migration guide puts a range on it and names the model that introduced it:

Claude Opus 4.7 introduced a new tokenizer, which later Opus models, including Claude Opus 5.5, also use. It contributes to improved performance on a wide range of tasks, and it may use roughly 1x to 1.35x as many tokens when processing text compared to models before Claude Opus 4.7 (up to ~35% more, varying by content).

Read the bottom of that range. Some content does not change at all. The headline 30% is a midpoint across workloads, not a floor under yours — which is exactly why the number you care about is the one you measure, not the one in the quote.

The boundary is a generation line, not a date, and it runs straight through the catalog most people are choosing from.

Why the price table hides the whole thing

Per-million prices are quoted per token, and the token changed size. A $/MTok figure from either side of that line is denominated in a different unit, so putting the two in one column compares nothing.

The cleanest case is Opus 4.6 against Opus 4.7. Both are listed at $5 per million input tokens and $25 per million output. Not one cell in the price table moved. The tokenizer did.

Take a request that counted 100,000 input and 10,000 output tokens on Opus 4.6. That is $0.50 plus $0.25, so $0.75. Send the identical text to Opus 4.7 at 1.30x and it is 130,000 and 13,000 tokens: $0.65 plus $0.33, so $0.98. Same price list, 30% more money.

Now run it the other way. Sonnet 4.6 is $3 and $15; Sonnet 5.5 is $2 and $10. The same task is $0.45 on Sonnet 4.6 and $0.39 on Sonnet 5.5 — about 13% cheaper, despite counting 30% more tokens. The per-token cut was deep enough to absorb the unit change.

That gives you the one piece of arithmetic worth memorising:

At 1.30x tokens, a model has to be at least 23% cheaper per token to cost the same per task. At 1.35x, 26%.

Anything less than that cut and your cost per task goes up even though the price went down.

A 20% price cut loses to a 30% unit change. A 33% cut wins. The price column alone will not tell you which you are looking at.

The sharpest edge: Haiku 5.5's tier boundary

Haiku 5.5 is billed in two tiers: $0.10 per million input for prompts up to 100,000 tokens, and $0.50 per million over that. Output goes from $0.50 to $2.50. The threshold is counted in tokens, and on Haiku 5.5 those are new-tokenizer tokens.

So a prompt you sized at 90,000 tokens against an older model is roughly 117,000 tokens here, lands in the upper tier, and bills at five times the rate on both input and output. Nothing about the prompt changed. The ruler did.

What does not work

Dividing characters by four. The old rule of thumb was calibrated on the old tokenizer. Anthropic's own migration guidance tells you to "re-test any code path that estimates tokens client-side or assumes a fixed token-to-character ratio" — an unusually direct instruction to go delete a constant.

Reusing a count you already have. The token-counting docs are explicit: "Recount prompts against the model you plan to use rather than reusing counts measured against earlier models." A spreadsheet of per-prompt token counts from six months ago is now wrong by an unknown amount in one direction.

Reading the price table as the direction of travel. As the table above shows, the sign of the change depends on the pair.

Pinning to an old model and forgetting about it. This works, and it is legitimate — Sonnet 4.6 and Opus 4.6 are still active and still bill on the previous tokenizer. But it has an expiry. Anthropic's deprecation page lists tentative retirement for Opus 4.6 as not sooner than 5 February 2027 and Sonnet 4.6 as not sooner than 17 February 2027, with at least 60 days' notice promised before any retirement. Treat a pin as a budgeting decision with a review date, not a permanent answer.

The fix: measure your own multiplier

Anthropic gives you the instrument and does not charge for it. The token-counting endpoint counts under the tokenizer of whichever model id you pass, so counting the same payload twice gives you your multiplier directly:

curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-sonnet-4-6",
    "messages": [{"role": "user", "content": "...your real prompt..."}]
  }'

Then send the identical body with "model": "claude-sonnet-5-5" and divide the two input_tokens values. The docs describe exactly this: "count the same request twice, once with your current model and once with the model you plan to move to, and compare the two input_tokens values."

Three things make this worth doing rather than trusting the 30%:

• It is free, and rate-limited separately from message creation — 5,000 requests per minute on the Start tier, more above it.
• It accepts the same body as a real request, including system prompts, tool definitions, base64 images and PDFs. Your tool schemas and your file dumps are counted, not a toy string.
• Anthropic says the increase depends on content and workload shape. Prose, code, JSON and non-English text are not one workload. Measure the mix you actually send.

Run it on three or four real payloads from your own traffic. The number you get is the only one that belongs in your budget.

Where this bites a router, including this one

A router is where token counting, context headroom and cost comparison all live, so a tokenizer that differs between two generations of the same vendor hits it directly. kRouter 0.5.166 does not run a real tokenizer anywhere. It uses a flat four-characters-per-token estimate in three places, and being specific about them matters more than being reassuring:

1. Sizing the history it keeps when it trims an oversized request down to fit a smaller model's window. This runs only on the capacity-adapter path, where a request needing vision, PDF, audio or video input falls back to a pool model.
2. The usage figures it reports when a provider returns none. These are flagged as estimated in the response.
3. The before-and-after numbers for the pxpipe saver, labelled estimated in the dashboard.

None of these change what you are charged. Billing follows the provider's own usage numbers whenever the provider sends them. What the constant does affect is how much history gets kept — and that one has a failure mode.

The trim targets 80% of the model's context window, leaving a fifth of it for the response. For a 1M-token Claude model that is 3,200,000 characters of kept history. Under the previous tokenizer that lands near 800,000 tokens, which is the intended 80%. Under the newer one the same characters are around 1,040,000 tokens — past the window, where the API answers 400 with "prompt is too long" rather than silently truncating.

What kRouter does not do, as of 0.5.166: it has no per-model tokenizer factor, it does not convert costs across the boundary when you compare models, and it will not warn you that a combo spans it. If you have a fallback combo holding both Sonnet 4.6 and Sonnet 5.5, your cost per task changes depending on which member answered, and no setting you touched caused it.

The one place this is genuinely good news

Every kRouter token saver works on text before it reaches a tokenizer. RTK rewrites bulky tool output, Headroom compresses context, Caveman and Ponytail shorten what the model writes. They remove characters, and the tokenizer then runs on what is left.

That means the same character reduction is worth more absolute tokens on a new-tokenizer model, because each removed character was going to become more token than before. The percentage saved does not change; the quantity does. If you are moving onto Claude 4.7 or later and you have never switched a saver on, this is the moment it pays best — see where each token saver acts on a request for which one fits your traffic.

Be clear about what this is not: compression does not undo a tokenizer change, and no router can make a token hold more text. It reduces the text you send. That is all, and it is enough to be worth doing.

Common questions

Did Anthropic raise prices?

No. Per-million list prices are unchanged across the Opus 4.6 to 4.7 boundary and lower on several newer models. The cost per task moved because the unit moved. Whether your bill goes up or down depends on which pair you moved between.

Which models are affected?

Claude 4.7 and later, plus Claude Mythos Preview. Sonnet 4.6 and earlier use the previous tokenizer. Opus 4.7 is the model that introduced the change, and the Fable and Mythos 5-series share the same tokenizer.

Is it really 30% for my workload?

Unknown until you measure. Anthropic publishes approximately 30% with a range of roughly 1x to 1.35x and says the increase depends on content and workload shape. Count a few of your real payloads against both model ids and use your own figure.

Does this affect my context window too?

Yes, and it is the part people miss. A 1M-token window holds about 30% less text than the same number on an older model. Prompts that used to fit can now return a 400. Re-check any max_tokens value, compaction trigger or client-side budget you tuned before the switch.

Should I stay on a 4.6-era model to avoid it?

It is a reasonable short-term choice and it is a real one — those models are still active. But Opus 4.6 and Sonnet 4.6 both carry tentative retirement dates in February 2027, so treat the pin as a decision with a review date. If the newer model is cheap enough per token to clear the 23% bar, moving is the cheaper answer anyway.

Related

• Where each kRouter token saver acts on a request
• Caveman vs Ponytail: two ways to cut output tokens
• Headroom: the token saver that reclaims your context window
• Claude Code context window with non-Claude models: the fix
• The cheapest LLMs for coding in 2026: real list prices