Sonnet 5 Pricing: Why a Cheaper Token Can Cost You More

The bottleneck: your bill is not denominated in what the price list measures#

On 10 August 2026 Anthropic made Claude Sonnet 5's introductory pricing permanent. The release note is one sentence: the $2 / $10 per million tokens introductory rate "is now the standard price: the previously scheduled increase to $3 / $15 per MTok on September 1, 2026 will not occur."

Against Sonnet 4.6 at $3 / $15, that reads as a 33% price cut on both input and output. A founder looking at a $12,000 monthly inference line reasonably expects to see $8,000.

The same vendor's pricing page carries a second note that nobody reads next to the first one:

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.

Sonnet 5 uses that newer tokenizer. So the price per unit fell by a third, and the number of units your unchanged text produces rose by roughly a third. Your invoice is denominated in tokens; your business is denominated in customer requests. Those two things just drifted apart, and the vendor never states the interaction, because the interaction is different for every workload.

This is not only a cost problem. It arrives bundled with two other things founders feel before finance does.

Reliability. A lift-and-shift to Sonnet 5 fails at runtime in two specific ways. Manual extended thinking (thinking: {type: "enabled", budget_tokens: N}) is removed and returns a 400. Setting temperature, top_p, or top_k to non-default values returns a 400. Both are documented in the launch note, and both live in code written years ago by someone who has left.

Latency. On Sonnet 5, adaptive thinking is on by default. Anthropic's own docs are blunt about the cost: "the tokens Claude spends reasoning are billed as output tokens, even when the thinking text isn't returned to you, and they count toward max_tokens alongside the response text." The default display on Sonnet 5 is "omitted", so those tokens are billed, they add to time-to-first-visible-text, and by default you cannot see them. To a user watching a spinner, a model that reasons well and streams nothing for four seconds is a broken product. Sonnet 5 is also excluded from Priority Tier, which is the capacity guarantee some teams were relying on for peak-hour latency.

Three separate business problems, one migration ticket.

Why the naive in-prompt fix fails#

The instinct when a bill jumps is to attack the prompt. Shorten the system message. Trim the few-shot examples. Tell the model to be concise. Turn thinking down to save output tokens.

Each of those does something, and the last one actively backfires.

Prompt caching on Claude is a prefix match, evaluated in a fixed order: tools, then system, then messages. A change at any level "invalidate[s] that level and all subsequent levels." Cache hits cost 0.1x the base input price. On Sonnet 5 that is $0.20 per million tokens against $2.00 — the single largest lever available to you, and an order of magnitude bigger than anything you will win by rewording a paragraph.

Now read the thinking documentation next to it:

The thinking configuration and the resolved effort level are rendered into the prompt itself, so changing any of them starts a new cache prefix. Switching between adaptive, enabled, and disabled, changing budget_tokens, and changing the effort value all invalidate cache breakpoints.

So the two most popular in-prompt cost fixes are in direct conflict. A per-request effort toggle — cheap effort for easy questions, high effort for hard ones — saves output tokens on one axis and destroys your input cache on the other. Input is usually the larger side of an agent or RAG bill. Teams ship that toggle, watch the bill rise, and conclude the model got more expensive.

The deeper problem is that prompt editing is a client-side fix for a server-side accounting problem. Whoever assembles the request controls the cache prefix, the model choice, and the thinking configuration. If that assembly happens in your frontend, in three microservices, and in a notebook someone runs on Tuesdays, no prompt rewrite will hold. You cannot optimise what you do not centrally construct.

Production architecture: measure, prune, cache, route#

Four steps, in this order. The order matters — routing before measurement is how teams move traffic onto a model that is worse and not cheaper for their shape of text.

1. Measure your own inflation factor#

"Approximately 30%" is a vendor average across content types. Prose, minified JSON, source code, and non-English text tokenize differently, and your real number is the only one that matters. The token counting endpoint is stateless, non-generative, and takes the model ID as an argument, so you can price a migration before you run a single completion.

# pip install anthropic
from anthropic import Anthropic
from pathlib import Path

client = Anthropic()

def count(model: str, text: str) -> int:
    return client.messages.count_tokens(
        model=model,
        messages=[{"role": "user", "content": text}],
    ).input_tokens

# A fixed corpus of YOUR traffic, one file per content shape.
corpus = {p.stem: p.read_text() for p in Path("corpus").glob("*.txt")}

print(f"{'shape':<20} {'sonnet-4-6':>10} {'sonnet-5':>10} {'ratio':>7}")
for name, text in sorted(corpus.items()):
    old = count("claude-sonnet-4-6", text)
    new = count("claude-sonnet-5", text)
    print(f"{name:<20} {old:>10,} {new:>10,} {new / old:>7.3f}")

Do not substitute tiktoken or any offline tokenizer library here. Those are built for a different vendor's models and will hand you a confidently wrong number.

2. Prune server-side, not in the prompt#

Move request assembly behind one internal service. That service, and only that service, is allowed to talk to the model provider. It does three jobs:

• Freezes the prefix. Stable system text and a deterministic tool list are serialised with sorted keys and a fixed tool order, so byte-identical requests actually hit the cache. An unsorted json.dumps of a Python dict, or a tool list built from a set, silently produces a new prefix on every deploy.
• Evicts volatile content from the prefix. Timestamps, request IDs, session UUIDs, and "today's date" belong after the last cache breakpoint, never inside the frozen system block.
• Prunes the payload before it is priced. Retrieved documents get truncated to a token budget, tool results get summarised after N turns, and dead conversation history is dropped. This is where "context engineering" stops being a blog word and becomes a line item you control.

3. Cache with the model's real floors in mind#

The minimum cacheable prefix is model-specific, and the differences are large enough to break a routing design:

Prices and minimums from Anthropic's pricing and prompt caching documentation, read 31 August 2026.

Read the Haiku row twice. A 2,000-token system prompt caches on Sonnet 5 and does not cache on Haiku 4.5 — and the API returns no error when it declines to cache. "Any requests to cache fewer than this number of tokens will be processed without caching, and no error is returned." A team that routes its cheapest traffic to Haiku for the lower headline price can land on a higher effective input price than Sonnet 5 cache hits, and the only symptom is a cache_read_input_tokens field nobody is graphing.

resp = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=4096,
    system=[{
        "type": "text",
        "text": FROZEN_SYSTEM,              # byte-stable across deploys
        "cache_control": {"type": "ephemeral"},
    }],
    messages=[*history, {"role": "user", "content": question}],
)

# The only honest cache metric. Alert on it, per route.
u = resp.usage
hit_rate = u.cache_read_input_tokens / max(
    1, u.input_tokens + u.cache_read_input_tokens + u.cache_creation_input_tokens
)

You get up to 4 cache breakpoints per request. Default cache lifetime is 5 minutes, refreshed for free on each use; a 1-hour TTL is available at a 2x write multiplier, which pays for itself once you get two reads out of it.

4. Route on task difficulty, and hold the tokenizer constant#

Hybrid routing — cheap model for the easy 60%, expensive model for the rest — is the correct architecture, and it is the one most likely to be measured wrong here, because two models on different tokenizers cannot be compared on price per million tokens at all. Compare them on cost per completed request, computed with each model's own token counts. We covered the routing-quality side of this in our RouteLLM cost-optimisation write-up; the tokenizer split adds a pricing trap that did not exist a year ago.

What the money actually does#

Take a support-reply feature currently on Sonnet 4.6, billing 300M input and 20M output tokens per month. That is $900 + $300 = $1,200 per month.

Now move it to Sonnet 5 unchanged. Input tokens inflate by the vendor's ~1.30 factor to 390M, costing $780. Output inflates too — and, because adaptive thinking is now on by default, output also grows by however much reasoning the model decides to do. Call that multiplier T:

Two numbers fall out of this that you cannot look up anywhere:

Your break-even inflation factor is 1.5x. The price ratio is identical on input and output ($2/$3 = $10/$15 = 0.667), so a single threshold governs the whole bill. If your text inflates less than 50%, Sonnet 5 is cheaper. At the vendor's ~30%, you are 13.3% cheaper on a like-for-like request. That is real, and it is a third of what the price cut implied.

Thinking eats the discount at T = 1.15. Once default reasoning adds more than about 15% to your output tokens, the output half of your bill is above where it was, and on an output-heavy or agentic workload the total flips. Nobody flipped a switch to cause this. It is the model's new default.

Now add the architecture. With 70% of input served from cache and roughly ten reads per write, the effective input multiplier is (1 − 0.7) + (0.1 × 0.7) + (1.25 × 0.7 / 10) = 0.4575. Input cost falls from $780 to $357. At T = 2.0, the same feature that cost $1,300 unmanaged costs $877 — 27% below the Sonnet 4.6 baseline it started at.

The headline price cut moved the bill by 13% in the best case and by −8% in a plausible one. The caching architecture moved it by 27%. That ratio is the whole argument: the vendor's price list is not where your unit economics are decided. They are decided by who assembles your requests.

Can this survive your workflow?#

Run these four checks before committing to a migration date.

1. Do you have a corpus? You need 20–50 real requests, split by content shape (prose, JSON, code, non-English). Without it, step 1 gives you the vendor's average instead of your number. Half a day of work.
2. Is request assembly centralised? If more than one service constructs prompts, the caching work is blocked until it is consolidated. This is usually the real schedule risk, not the model swap.
3. Are you graphing cache_read_input_tokens per route? If not, you have no way to detect a silent cache invalidation, and every deploy is a potential 10x input-price regression.
4. Can you tolerate the latency shape? Thinking on by default, with display omitted, means a longer silent gap before the first visible token. If your product is a streaming chat UI, set display: "summarized" and test with real users before you ship.

When to skip this entirely. If your monthly inference spend is under roughly $500, the engineering time costs more than the saving — take the 13%, stay on defaults, and revisit at scale. If your traffic has no shared prefix at all (every request is unique short text with no system prompt), caching has nothing to grip and routing is your only lever. And if you are mid-way through a funding process, note that fixing attribution usually matters more than fixing the total: see our write-up on LLM cost attribution architecture.

For your engineers#

The migration-blocking specifics, in one place:

• thinking: {type: "enabled", budget_tokens: N} returns a 400 on Sonnet 5. It was already deprecated on Sonnet 4.6. Replace with thinking: {type: "adaptive"} and control depth via output_config: {effort: ...}.
• Non-default temperature, top_p, or top_k returns a 400 on every Sonnet 5 request, whether or not thinking is used. Grep for these before the cutover; they are frequently buried in a shared client wrapper.
• thinking.display defaults to "omitted" on Sonnet 5. Thinking blocks come back with empty text and a populated signature. Set display: "summarized" if you stream reasoning to users.
• Any change to the thinking configuration or resolved effort value renders into the prompt and starts a new cache prefix. Treat effort as a per-route constant, not a per-request variable.
• Sonnet 5 is not available on Priority Tier. If your peak-hour capacity plan depends on it, that plan needs revisiting.
• Cache prefix order is tools → system → messages; up to 4 breakpoints. Tool definition changes invalidate everything downstream, so freeze and sort your tool list.
• The Batch API remains a 50% discount on both directions: $1 / $5 per MTok on Sonnet 5. For anything not user-facing, this stacks with caching and beats every prompt-level optimisation combined.
• Declaring tools is not free: the tool-use system prompt is 354 tokens on Sonnet 5 at tool_choice: auto, and 474 at any/tool. It sits inside your cacheable prefix, which is an argument for caching it rather than trimming it.

What Effloow added#

Anthropic publishes the price cut and the tokenizer note on separate pages and never multiplies them together. This guide does the multiplication: the 1.5x break-even inflation factor, the T = 1.15 point where default thinking cancels the discount, the effective-input-multiplier formula for a cached workload, and the Haiku 4.5 cache-floor trap that silently fires when a routing layer sends a 2,000-token prompt to a model that needs 4,096 to cache it. Every price and limit here is quoted from Anthropic's own documentation, read on 31 August 2026 and linked below. The token inflation figures in the worked model use the vendor's stated ~30% average — they are not Effloow measurements, which is exactly why step 1 of the architecture is measure your own corpus first. For the broader inventory of levers this article does not cover, see our token optimisation guide.

Working on this?#

Effloow builds and audits exactly this layer: the request-assembly service, the cache instrumentation, the routing policy, and the cost model that tells your board which customers are profitable. If you are migrating models this quarter and want the measurement done before the invoice arrives, see our services or get in touch with your current monthly token volume and we will come back with the break-even number for your workload.

Sources#

• Claude Platform release notes — Claude Sonnet 5 launch entry (30 June 2026) and the pricing entry (10 August 2026)
• Pricing — per-MTok model table, prompt caching multipliers, Batch API discount, tool-use system prompt token counts, tokenizer note
• Prompt caching — minimum cacheable prefix per model, breakpoint limit, prefix hierarchy, invalidation rules
• Thinking — thinking billed as output tokens, default-on models, display default, effort-change cache invalidation
• Token counting — the count_tokens endpoint used in the measurement script