Claude Sonnet 5.5 Migration: Three Settings to Check and What Three Tasks Cost

ยท
6 min read
ยท
AI-assisted

AI tooling disclosure

Generative AI materially contributed to this article.

Human review confirmed by the author.

Claude Sonnet 5.5 Migration: Three Settings to Check and What Three Tasks Cost

A newer model with an unchanged price table can still raise or lower your bill per task. Here is what to check before switching, and what three measured calls actually returned.

Claude Sonnet 5.5: deep ink-green cover with three empty outlined boxes

Changing claude-sonnet-5 to claude-sonnet-5-5 is one line in a config file. Everything that makes the switch safe or unsafe sits outside that line: the model is a separate model rather than a version, one thinking setting has a new name, and the effort level that governs how much work the model does is not the same in every environment.

The official page promises 30%+ faster output and up to 30% lower cost per task, with the price per token unchanged. Those are results, not rules. To see whether they hold for a specific job, three calls were run with only the model string changed, and the response fields were recorded as they came back.

What was measured, and what was not

Three tasks, one call each, on 2026-10-22, through an OpenAI-compatible endpoint. The calls went through Crazyrouter, and nothing else about the setup changed between the two models. Effort was left at the default.

This is a directional test, not a benchmark. One call per task, one day, one route. There is no repetition, no controlled comparison, and no scoring of answer quality. The value is in showing where to look, not in producing numbers you can reuse.

Output tokens and cost per task

The three settings to check

1. The model string points at a different model

claude-sonnet-5-5, claude-sonnet-5, and claude-sonnet-4-6 are not three versions of one model. They are three separate models. Editing the string in a config is a migration, not an update.

The practical consequence is that the name in a response is weak evidence. It tells you what the endpoint reported, not what handled the request. Run a few representative tasks by hand before moving real traffic.

2. Thinking, if you had it switched off

The official page states that if you run Sonnet with thinking off, you need to switch to the new between_tools setting, which keeps up-front thinking off, before moving to Sonnet 5.5.

This is the item most likely to be missed, because it fails quietly. Leave it alone and requests still return normally. Nothing in a passing test suite tells you the behaviour changed, so the difference surfaces in production rather than in CI.

3. Effort, which has two different defaults

Five effort levels and two defaults

The official page gives the defaults in one line: in Claude Code and the apps, the default effort is Medium; on the Claude Platform, the default is High. A request that is never given an explicit level runs at different amounts of computation depending on where it is sent.

There are five levels in total โ€” Low, Med, High, Xhigh, and Max. Raising the level makes the model work longer, generally raises scores, and raises cost with them. The same page also notes that Low or Medium already exceeds Sonnet 5's best results at roughly one tenth of the cost per task, which makes the default worth overriding rather than inheriting.

resp = client.chat.completions.create(
    model="claude-sonnet-5-5",   # not a version of claude-sonnet-5
    max_tokens=2000,             # cap the output yourself
    temperature=0,
    messages=[{"role": "user", "content": task}],
)

print(resp.usage.completion_tokens)  # this is the number that moves the bill

What the three tasks cost

The first two tasks had a fixed output shape, and the bill went down. A schema extraction task with an explicit field list returned 410 output tokens for $0.0049, against 682 tokens and $0.0076 on Sonnet 5. A table conversion task returned 628 tokens for $0.0066, against 911 tokens and $0.0095.

The third task went the other way. It asked for a payment retry routine to be rewritten, and the prompt included the sentence "do not omit anything." Sonnet 5.5 returned 5,753 output tokens for $0.0579. Sonnet 5 returned 4,012 tokens for $0.0405 on the same request. On that one task, the newer model costs 43% more.

The difference was in the request, not the model. A task that tells the model where to stop gets cheaper; one that does not, gets more expensive. "Do not omit anything" reads as a requirement rather than a hint on a model that follows instructions more closely, so the implementation grows denser, the comments multiply, and the explanation of each choice gets longer. None of that is a defect. None of it is free either.

Time followed the same split, though less dramatically. The two fixed-shape tasks finished in 4.41 s and 7.48 s, against 11.68 s and 13.04 s. The open-ended rewrite took 42.73 s against 45.78 s โ€” faster, but only by about 7%, not by 30%.

flowchart TD
    A[Change the string to claude-sonnet-5-5] --> B{Was thinking off?}
    B -- Yes --> C[Move to between_tools]
    B -- No --> D[Leave thinking as it is]
    C --> E[Set effort explicitly]
    D --> E
    E --> F{Is the output shape fixed?}
    F -- Yes --> G[Expect fewer output tokens]
    F -- No --> H[Expect more output tokens]
    G --> I[Measure completion_tokens on one real task]
    H --> I

What I got wrong

The first assumption was that cheaper meant cheaper everywhere. The announcement says up to 30% lower cost, and it was easy to read that as a property of the model. One of three tasks came back 43% more expensive, which is the kind of number that only appears when you measure your own work.

The second mistake was looking at the price table first. The per-token price did not change at all, so the table explains nothing about the outcome. Output length is what moves the bill, and completion_tokens is where it shows up.

A third trap was a single sentence. The rewrite task carried the sentence "do not omit anything," and that one instruction accounts for the gap between $0.0579 and $0.0405. Better instruction-following turns a reassuring phrase into a requirement.

The third mistake was letting the default decide. Measuring while effort is unset means the comparison depends on where the calls were made. The apps default to Medium and the API defaults to High, so two environments can produce different numbers for the same request and neither is wrong.

Two lines of the price table are also easy to skip. Cache reads are $0.10 per million tokens and cache writes are $2.50. If the same system prompt, tool definitions, or file context is resent on every call, those two lines matter more than the headline input and output prices. If calls are short and different every time, they are irrelevant.

What this test cannot tell you

Two facts about the model are not on the official page, and are therefore not asserted here: the maximum output token count and the knowledge cutoff date.

The cost figures are arithmetic on measured token counts at published rates. They are not invoices.

One more caveat applies before any of this is used to plan a migration. The official page says that on complex, open-ended work requiring sustained judgment, Opus 5.5 remains clearly stronger. A cheaper model that handles fixed-shape tasks well does not take over the tasks that need the more capable one.

Frequently Asked Questions

Which effort level is actually being used?

Claude Code and the Claude apps default to Medium. The Claude Platform defaults to High. Unless a level is set explicitly, the answer depends on where the request is sent.

What happens if I change the model string but leave thinking disabled?

The official page says to move to the between_tools setting, which keeps up-front thinking off. The request still returns normally if this is skipped, which is exactly what makes it easy to overlook.

Why did the newer model cost more on one task?

Output length. The price per token is unchanged at $2 per million tokens for input and $10 for output. A request with no fixed output shape lets the model keep going, and the bill tracks output tokens.

Which tasks should move first?

Tasks with a fixed output shape: schema extraction, table conversion, and narrow rewrites. Open-ended rewriting is the last candidate, because that is where output grows.

Can a higher effort level ever produce a worse result?

Yes. The official page's own footnote notes cases where Max scored lower than Xhigh, and describes an evaluation where the top level split review work across subagents and produced two timeouts and out-of-scope edits.

Is Claude Sonnet 5.5 cheaper overall?

On two of the three measured tasks, yes. On the third, no. Treat "up to 30% lower cost" as a description of typical tasks rather than a guarantee.

Do the price table's other lines matter?

Cache reads are $0.10 per million tokens and cache writes are $2.50. Workloads that resend the same system prompt or tool definitions are sensitive to those lines; short, varied calls are not.

Sources and method

Official figures, the five effort levels, and the between_tools note come from Anthropic's Claude Sonnet 5.5 page, published 2026-09-28 and checked 2026-10-22. Token counts, costs, and timings were recorded on 2026-10-22 from one call per task through an OpenAI-compatible endpoint. The three calls were routed through Crazyrouter's endpoint; the same request shape works against any OpenAI-compatible provider, and the check is the same wherever it runs: pick one real task, change only the model string, and compare completion_tokens.

Comments(0)

Join the discussion by logging into your account.

No comments yet. Be the first to comment!

xiaoying zhou

Passionate developer sharing knowledge about modern web technologies and best practices.

Subscribe to xiaoying zhou's Newsletter

Direct email dispatches when new stories are published. Zero algorithms.