Anthropic's Opus 4.7 uses more tokens: hidden inflation at the same prices

Anthropic has released Claude Opus 4.7, and early API tests turned up a surprise: the same text in the new model can take up significantly more tokens than in Opus 4.6. With prices formally unchanged, that means a quiet but real increase in costs.

What the problem is

The tokenizer is the component that splits text into fragments before it is fed to the model. The number of those fragments determines the cost of a request and how much of the context window it occupies. When Anthropic changes the tokenizer between versions, the same prompt starts to "weigh" differently. With Opus 4.7, the weight went up.

If your typical request used to take 1,000 tokens, it may now take 1,300–1,500. The price per million tokens has not changed, but you are effectively consuming more tokens for the same work.

"The result is hidden inflation: prices and limits are listed as before, but in practice costs may rise" — from research by the

Kodik team.

Kodik, which develops a code editor supporting multiple AI models, checked the tokenizer's behavior itself through the API. Anthropic has not published official comparison data, so the developers ran the tests themselves and shared their findings.

Which content is affected most

The token increase is not uniform across text types. Based on the available data, the picture looks like this:

• Code: a noticeable increase, especially in languages with many special characters: operators, brackets, indentation
• Technical strings (JSON, XML, YAML, SQL): changes vary with structure; nested constructs may grow more
• System prompts: affected the same way as user requests; this is especially sensitive for products with long system instructions
• Plain text: moderate growth, less noticeable on short requests
• Mixed content (text + code + JSON): behavior is unpredictable, so test for your specific scenario

Scale matters: if a prompt grows by 20% and you handle a million requests a day, the real bill changes very significantly.

Why this is a systemic problem

Opus 4.7 is not an exception. A tokenizer can change in any model from any provider, and far from always is it stated explicitly in the release notes. For teams building products on top of an API, this creates several risks.

Budget surprises. Limits calculated from historical data can be unexpectedly exceeded after a model switch, even if the requests themselves have not changed.

Overrunning the context window. A system that used to fit within 128k tokens may start truncating context or returning an error after the update.

Unfair A/B tests. When comparing the quality of two model versions on the same data, a different tokenizer means the models receive technically different input, which affects how the results should be interpreted.

Hidden regressions in RAG pipelines. If you pack chunks to a token limit, a tokenizer change can break the splitting logic without a single error in the logs.

What this means

Developers who already use Opus in production or plan to move to 4.7 should run their real prompts through the tokenizer API of both versions before switching. It will take a few hours, but it gives an honest estimate of the cost increase and lets you adjust the budget or architecture.

The Opus 4.7 case is a good reminder: when upgrading a model, check not only the quality of answers but also tokenization efficiency.