Opus 4.7's Quiet 35% Tokenizer Tax

When Anthropic shipped Claude Opus 4.7 in early 2026, the pricing page kept the headline numbers from 4.6: $5 per million input tokens, $25 per million output tokens, batch and cache discounts unchanged. Most teams read the changelog, noted "no price change," and kept going.

That reading was wrong. Opus 4.7 ships a new tokenizer that produces up to 35% more tokens for the same input. Anthropic's own pricing documentation acknowledges this — the text reads, almost in passing, that 4.7's tokenizer is "more efficient at certain language modeling tasks" and may produce "more tokens for certain inputs." Translated: identical prompts cost more on the new model than on the old one. The per-token price is the same. The per-prompt price went up.

Finout was the only outlet to call this out at the time. The migration guides, the tutorials, and the Vercel AI SDK docs all stayed silent. This post does the math, names the workloads that get hit hardest, and gives you the one-line check you should run before migrating.

The actual mechanism

A tokenizer is the bridge between a string and the model's internal vocabulary. The tokenizer that shipped with Claude 3 / 3.5 / 4.x through 4.6 was a fairly standard byte-pair encoding variant. The Opus 4.7 tokenizer was rebuilt — Anthropic has not published the full spec, but the empirical behavior is consistent across our test corpus:

• Code-heavy prompts fragment more aggressively. Long identifier names, especially in languages with snake_case or kebab-case conventions, split into more tokens.
• Non-Latin scripts (Chinese, Japanese, Korean, Arabic, Cyrillic) produce roughly the same token count as 4.6, sometimes slightly fewer. This is the "more efficient at certain language modeling tasks" claim from the docs.
• English prose sits in the middle — 5-12% inflation, not catastrophic.
• JSON and structured output are the worst case. Keys with dotted notation, long enum values, and deeply nested structures inflate by 25-40%.

The 35% figure is the upper end. The corpus-average across our 47-prompt benchmark suite was 18.4%. If you live in the JSON-heavy end of the corpus, your bill rose more than that.

The math on a real workload

Take a typical RAG-with-Claude pipeline running 4.6 today:

• 8,000-token system prompt (cached)
• 3,500 tokens of retrieved context per request
• 600-token user query
• 1,200-token JSON response

At 4.6 prices with prompt caching active: Migrate the same workload to 4.7 unchanged. Apply our corpus-average inflation:

• System prompt: 8,000 → 9,440 tokens (+18%, English prose mid-range)
• Retrieved context: 3,500 → 4,130 (+18%)
• User query: 600 → 708 (+18%)
• JSON response: 1,200 → 1,608 (+34%, JSON-heavy upper range)

New cost: That's a 26.8% cost increase on identical work. At 100k requests/month, you went from $5,450 to $6,910. Per quarter, that's an extra $4,380 you didn't budget for and your CFO will not understand why.

Workloads heavier on output (chat with long-form answers, code generation, structured extraction) trend toward the upper end. The 35% figure becomes realistic when output is dominated by JSON with verbose schemas.

What the model gives you in exchange

To be fair to Anthropic: Opus 4.7 is meaningfully better at long-running agentic work. Boris Cherny's launch tweet calls it "more agentic, more precise, and a lot better at long-running work. It carries context across sessions and handles ambiguity much better." The 1M-token context window is a real lift over 4.6's 200K. SWE-bench Verified scores moved up. The model is better at the things it is better at.

The trade-off is: the model is also more expensive per equivalent unit of work, even though the per-token price did not change. That trade-off may be worth it for your workload — agent runs that previously took 40 turns and now take 25 might net out cheaper despite the tokenizer tax. Static request/response workloads with no agentic depth (a translation service, a single-shot classification, a Q&A bot over docs) net out more expensive.

The question is not "is 4.7 better" — it is. The question is "is 4.7 better enough at your specific workload to offset the per-prompt cost increase."

The one-line check before you migrate

Anthropic does not publish a standalone tokenizer endpoint for 4.7 yet. The cleanest empirical check is to run a representative sample of your real production prompts through both the 4.6 and 4.7 APIs in dry-run mode (stream: false, max_tokens: 1) and read the usage.input_tokens field from each response.

Pseudocode:

const corpus = await loadRecentProductionPrompts({ n: 100, days: 7 });
const counts46 = await Promise.all(corpus.map(p => measureTokens(p, "claude-opus-4-6")));
const counts47 = await Promise.all(corpus.map(p => measureTokens(p, "claude-opus-4-7")));
const inflation = counts47.reduce((a, b, i) => a + b / counts46[i], 0) / counts47.length;
console.log(Average inflation: ${((inflation - 1)  100).toFixed(1)}%);

If inflation is under 15%, the migration is cost-neutral for most teams (model quality gains offset). If it's between 15% and 25%, you need to model the agent-loop-shortening benefit on your specific workload. Above 25%, you have a budget conversation to have before flipping the switch.

Mitigations that actually work

If you're committed to 4.7 but the tokenizer tax is biting:

1. Aggressive prompt caching. Cache hits cost 10% of the input rate. The tokenizer inflation applies to the cached content too, but a hit at 10% of the new rate is still cheaper than a miss at the old rate. If your cache hit ratio is below 80%, the next dollar is best spent there. 2. Batch the offline work. The Anthropic Batch API gives 50% off and stacks with cache reads. System prompt → batch + cached read = $0.05/M tokens vs $5.00/M list. We do the math in detail in /blog/batch-plus-cache-95-percent-off. 3. Mixed routing. Not every request needs Opus. Sonnet 4.6 (now Sonnet 4.7) is one-fifth the cost on input and still adequate for retrieval-grade Q&A, summarization, and structured extraction. Route by complexity. The LLM gateway decision tree covers this. 4. Shorten the JSON. If your structured output schema uses dotted keys (user.profile.address.city) or verbose enum values (STATUS_PENDING_APPROVAL), short equivalents tokenize substantially better in the 4.7 tokenizer. Move expensive verbosity to the schema docs, not the runtime. 5. Trim retrieved context. Reranking before generation cuts retrieval token volume by 30-50% at equivalent recall. The tokenizer tax hits the cut tokens too — if you didn't need them, removing them is double savings.

Where this fails

We tested 47 prompts on a corpus skewed toward our team's workload. A different workload distribution (more multilingual, more long-form prose, less structured output) will produce different averages. The 18.4% corpus average is not "the inflation rate" — it is "our team's inflation rate." Run your own corpus. Anthropic may revise the tokenizer. They did it once between 4.6 and 4.7 without changing the per-token price. They could do it again. Tokenizer behavior is not a stable contract. Some workloads got cheaper. If your traffic is dominated by Chinese, Japanese, or Korean inputs, our benchmark suggested you might see 2-8% cost reduction* on the same workload. Don't migrate to 4.7 assuming you'll save money; do migrate assuming you'll need to measure. The 1M context window changes the math. A workload that needed two requests on 4.6 (because context didn't fit) and now needs one on 4.7 may net out cheaper despite per-token inflation. Token count is not the only variable; turn count matters.

Why this matters beyond the immediate bill

The deeper story is that model versioning is not a stable price contract. "We use Claude" is a vague commitment; "we use Claude Opus 4.7" is a specific commitment with specific economics, and the economics can change underneath you between minor versions. Teams that built financial models assuming token count is a function of input length are going to be wrong each time Anthropic re-trains a tokenizer.

The mitigation is to measure on your real corpus, not the marketing page; to set up cost-tracking that alerts on per-request cost drift, not just total spend; and to keep migration paths to Sonnet or to OpenAI/Gemini warm for the workloads that don't justify Opus pricing. The LLM cost tracking guide walks through this.

What to read next

• /topic/anthropic-prompt-caching — the caching playbook that gets the tokenizer tax back
• /blog/batch-plus-cache-95-percent-off — stacking discounts
• /topic/llm-cost-tracking — multi-provider spend visibility
• /topic/llm-gateway-decision — routing across providers when one gets expensive
• /topic/anthropic-prompt-caching — implementation reference
• /for/finops-ai-cost-tracker — the team that owns this conversation

Sources

• Anthropic. "Pricing". Headline rates; tokenizer note.
• Anthropic. "What's new in Claude 4.7". Model improvements.
• Boris Cherny. Launch tweet, Opus 4.7. "Carries context across sessions, handles ambiguity much better."
• Finout. "The Real Cost Story Behind the Unchanged Price Tag". The only public outlet to identify the tokenizer cost shift.
• Anthropic. "Prompt caching". Cache hit cost = 10% of input rate; 20-block lookback; 5-minute TTL.
• Anthropic. "Message Batches API". 50% discount, stacks with cache.

FAQ

Q: Does the tokenizer change apply to Sonnet 4.7 too? A: Yes, but the effect is smaller in our testing — Sonnet's tokenizer changed less between 4.6 and 4.7. Measure on your corpus before assuming. Q: How do I see the inflation factor without running both models? A: You don't, currently. Anthropic does not publish the 4.7 tokenizer as a standalone library yet. The dry-run check (max_tokens: 1) against both APIs is the cheapest way. Q: Will my Anthropic bill go up automatically when 4.6 sunsets? A: Yes, if you have an alias that pins to "latest Opus" or you re-deploy without changing model IDs. Pin to claude-opus-4-6 explicitly until you've done the migration math. Q: Why did Anthropic not announce this more loudly? A: They did acknowledge it in the pricing docs — quietly. The marketing emphasis on quality improvements ("more agentic, more precise") buried the cost shift. Standard vendor behavior; not unique to Anthropic. Q: Does prompt caching mitigate this? A: Partially. The cached content is also inflated by the new tokenizer, but cache reads at 10% of the input rate still beat un-cached reads at 100%. If you're not caching, that's the first thing to fix. Q: Should I move to OpenAI / Gemini / Vertex? A: Only if the model quality difference is one your workload tolerates. The cost-shifting is real but Anthropic still has a quality lead on agentic tasks per public benchmarks. The right move is multi-provider routing with explicit cost-per-task tracking, not a wholesale switch. See /topic/llm-gateway-decision.