Sonnet 5 Per-Task Cost Checklist for Claude Bills

In a live Claude workload, Sonnet 5 can look cheaper on the rate card, but Sonnet 5's new tokenizer can make the same text consume about 1.0 to 1.35 times the token count, depending on content. The trade-off is cost per task: multiply input tokens by the input rate, output tokens by the output rate, divide by one million, then add cached reads, retries, and fallback calls.

Per-token price is not the invoice

A per-token rate becomes a bill only after it is multiplied by the tokens your serving path actually emits. That includes prompt tokens, completion tokens, retries, and any cached reads your stack bills separately. The model name changes the rate, the workload changes the count, and the invoice is the number you need to explain.

Short prompts can make the rate dominate. Long context, repeated system prompts, and tool-heavy loops can make the token count dominate. A headline price change can therefore leave monthly spend flat when the new model changes how many tokens each task consumes.

Tokenizer drift changes the token count

The initial Sonnet 5 schedule ran at $2 per million input and $10 per million output through August 31, with a planned step to $3 and $15 afterward. Fable 5.1's release pricing table showed the same $2 and $10 rates. On August 10, Anthropic made the $2 and $10 Sonnet 5 rates permanent and abandoned the planned September jump to $3 and $15.

Claude Sonnet 5 appeared on June 30, positioned by Anthropic as the most agentic Sonnet release. Anthropic described it as stronger than Sonnet 4.6 for reasoning, tool use, coding, and knowledge work, and closer to Opus 4.8. Anthropic presented the launch price as a way to keep the migration roughly cost-neutral for users.

That cost-neutral framing assumes the token count stays fixed. Tool-using workloads can add tool calls, intermediate reasoning, and repeated context before the final answer is returned, so the same task may consume more tokens under the new tokenizer.

Compute task cost before cutover

Start with one task class, not the whole product. Pick a representative request from production: a support reply, a code edit, a document summary, or a tool-using agent turn. Log the input tokens, output tokens, and any cached tokens your serving layer reports.

Run the same request on the model you are replacing and on the candidate model. Keep the prompt identical. Keep the serving config identical. Record the token count for each run, then multiply each token field by the applicable rate. Capture the old model's task cost before you change the pin, because the new model's token count will not be visible until you run the same traffic.

More tokens can outweigh the rate; fewer tokens compound the rate change; stable tokens make the rate the whole story. The task cost tells you which case you are in.

Do the same for the failure path. A retry can add another output cost, a fallback can send the same prompt to a second model, and a batch job can change the effective rate. These are not edge cases; they are part of the serving config you already operate.

Cache reads matter when repeated prefixes dominate your traffic. If your system prompt, tool schema, or retrieved context is stable, cache reads can change the cost more than the base rate. Measure the cache hit rate before you assume the new model will save money.

Make the switch reversible

The checklist below turns a rate change into a budget decision. The order matters: confirm the price, measure the delta, compute the task, then change the serving config. Each item is testable if you already have logs.

• Confirm the current rate card for the candidate model.
• Measure token delta on a sample of live prompts.
• Compute cost per task using input, output, and any cached fields.
• Compare the task cost against the model you are replacing.
• Check serving config for context limits, retries, and batch behavior.
• Update the model pin, fallback, budget alerts, and evals.
• Re-run the same task on the old and new model before cutover.

If any item fails, stop.

Treat the re-run as a control. If the task cost is higher, you can still switch for quality, but you need to know the budget impact before you do. If the task cost is lower, you still need the alerts and evals to catch regressions after the token count shifts in production.