Skip to content
ISSUE 001·LIVE·13:44 IL
← Journal/2026-09-29·8 min·claude sonnet

Claude Sonnet 5.5 Is Faster. Is It Cheaper for Your Agent?

Sonnet 5.5 keeps its token price but changes speed and token use. A practical way to compare model, effort setting, task quality, and total cost instead of trusting a headline.

By Harel Asaf·AI Builder·Tel Aviv

Claude Sonnet 5.5 can cost less per completed task than Sonnet 5 without a lower token price: Anthropic says it generates output faster and often uses fewer tokens to finish the same work. But "cheaper" is not a model property in isolation. Raise its effort level, let a coding agent run for many steps, or compare it on the wrong tasks, and the bill can move the other way. Measure the completed workflow, not the price list.

A new-model email landed in my inbox overnight. The headline was about speed. The useful question for someone building agents is more specific: **at what effort setting does the model finish your job accurately enough, and what does that run actually cost?** Anthropic's release and an independent benchmark give different but compatible views of that question.

What changed with Claude Sonnet 5.5?

Anthropic introduced Sonnet 5.5 on September 28 as a faster counterpart to Opus 5.5. Its announced API prices match Sonnet 5: $2 per million input tokens, $10 per million output tokens, and $0.20 per million cache-read tokens. Anthropic says generation is more than 30% faster, and its own tests show up to 30% lower per-task cost because the model often takes fewer tokens or steps to get the job done. Those are vendor measurements, not a promise about every workload.

The model has adjustable effort levels. Anthropic says Claude apps and Claude Code default to Medium, while its platform defaults to High. The same model name can therefore hide different budgets and behavior depending on where you call it. Before comparing screenshots of two runs, check the effort setting, prompt, tools, cache behavior, and what counted as a completed task.

A useful cost equation is simple, even if measuring its inputs is not:

Cost per successful task = total model and tool cost across all attempts / tasks that pass the acceptance check.

Retries, human repair, and failed runs belong in the numerator. A run that produced an answer but broke the workflow does not belong in the denominator.

Why can a model with the same token price cost less?

Because an agent is a loop, not one completion. It reads context, calls tools, receives results, and often starts another model turn. A model that reaches the correct end state in fewer turns can shrink both output and repeated input. A faster output stream can reduce user wait time without changing token usage, while better decisions can reduce repeated tool calls. These are separate benefits.

VariableWhat to recordCommon mistaken shortcut
Input tokensEvery turn, including repeated context and tool resultsPrice only the first prompt
Output tokensAll reasoning and visible output billed by the providerCount only the final answer
Cache reads/writesHit rate and billed tokensAssume caching worked because it was enabled
Agent stepsTool calls, retries, and escalationsTreat a failed run as zero cost
QualityPass rate on the actual end stateAccept a fluent answer as completion
LatencyEnd-to-end elapsed timeConfuse tokens per second with time to task completion

Anthropic's release includes examples where lower effort beats Sonnet 5's best benchmark score at much lower task cost. It also reports large coding gains. Those are reasons to run a trial, not numbers to paste into a budget for a different agent.

What does independent testing complicate?

Artificial Analysis independently evaluated the model across effort levels. Its max-effort configuration scored 56 on the Intelligence Index, just behind Opus 5.5 at 58. But it used about 193,000 output tokens per Index task, the highest token use that evaluator had measured. At that setting, Artificial Analysis said Sonnet 5.5 was not on its intelligence-versus-cost-per-task frontier. A near-top score did not mean the best purchase.

That does not refute Anthropic's claim that Sonnet 5.5 can be cheaper than Sonnet 5 for many tasks. The comparison points differ: vendor tests versus an independent index, Sonnet 5 versus other frontier models, and low/medium versus max effort. Artificial Analysis also noted that its pre-release deployment had a structured-output bug that Anthropic said was fixed for public release. Do not turn its exact pre-release scores into a universal production expectation.

There is a second comparison trap. Anthropic reports 70.6% on Terminal-Bench 4.0 for Sonnet 5.5; Artificial Analysis reports 64% in its own run. Neither number automatically invalidates the other. Harness, environment, effort and sampling can change benchmark results. If someone offers a single score without the setup, ask for the setup before choosing a model.

How should you compare Sonnet 5.5 in an agent?

Make the comparison small enough to finish and honest enough to decide:

1. Freeze a set of tasks. Include common requests, messy inputs, edge cases, and cases where a wrong action matters. Keep a separate set for final validation.

2. Define the end state. Did the code pass tests? Was the requested document complete and factually supported? Was the correct tool used? A polished reply alone is not a pass.

3. Run a baseline. Compare the current model and configuration with Sonnet 5.5 on identical inputs, tools, and timeout rules.

4. Sweep effort deliberately. Test Low, Medium and High before assuming Max is worth it. Record any higher-effort gain alongside its token and latency cost.

5. Price the whole attempt. Include retries, cache writes, tool calls, and human fixes. Report median and the costly tail, not just the best run.

6. Check sensitive failures separately. An agent that saves money but sends the wrong message or modifies the wrong file is not an optimization.

For coding, test changes in a disposable branch and run the repository's real tests. For research, compare cited claims with their original sources. For a production workflow, roll out to a small, reversible slice before changing routing for everyone. This isn't ceremony. It's how you find out whether the speed claim buys a better day of work or only a more expensive leaderboard score.

When would you route to Sonnet rather than Opus?

The release positions Sonnet 5.5 as a fit for well-scoped everyday tasks and Opus 5.5 for work needing careful judgment. That is a useful starting hypothesis, not a routing rule. You can route ordinary extraction, formatting, or bounded code changes to the cheaper configuration if your eval shows it reliably reaches the right end state. Escalate ambiguous, costly, or high-stakes cases to stronger review or a more capable model where that improves outcomes.

Don't make the model choose its own budget without constraints. A hard class of task may cause many retries at low effort; a high-effort run may solve it once; or both may need a human. Your routing rule should consider expected total cost and the consequence of being wrong, not only per-token price.

Anthropic's listed price for Opus 5.5 is $4 per million input tokens and $20 per million output tokens, twice Sonnet 5.5's uncached input/output unit price. That says nothing on its own about the cost of a successful task. If Opus needs much less work, or Sonnet repeatedly fails, the apparent saving evaporates. Measure rather than assert.

What would I watch after switching?

Treat model changes as code changes. Keep a fixed regression set, log model and effort level on every run, and compare the same failure categories over time. Watch for new tool-use loops, unsupported citations, malformed structured output, and cost spikes in the expensive tail. If a new release improves the median but creates a small number of long, costly failures, the average can hide the operational problem.

The one-sentence version: Sonnet 5.5 makes lower cost per successful task plausible, not automatic. Same token price, faster output, and stronger benchmarks are good reasons to test it. The model's effort setting and your agent's actual end-to-end behavior decide whether to keep it.

Sources

Frequently Asked Questions

Is Claude Sonnet 5.5 cheaper per token than Sonnet 5?

Anthropic lists the same input, output and cache-read prices as Sonnet 5. Its claim of lower cost refers to fewer tokens or steps per completed task in its tests, not a price cut per token.

Why did an independent evaluator call max effort expensive?

Artificial Analysis measured about 193,000 output tokens per Intelligence Index task at max effort. In its comparison, the extra quality did not put that configuration on its cost-versus-intelligence frontier. Lower effort settings can have a different tradeoff.

Should I always use the lowest effort setting?

No. Low effort can fail a hard task or require retries, making total cost higher. Compare quality, cost and latency across effort settings on your workload.

Can I compare benchmark percentages from different sites directly?

Not without checking the test harness, environment, settings and scoring method. Anthropic and Artificial Analysis published different Terminal-Bench figures under different evaluations. Keep each number with its source and method.

Is Sonnet 5.5 as capable as Opus 5.5?

Not across all tasks. Some benchmark scores are close, while independent results show gaps in factual knowledge and reasoning. Test the work you need done, including failures that matter, rather than substituting a headline ranking.

What should I track after a model switch?

Task pass rate, category-specific errors, latency, all billed tokens, retries, tool calls, and human intervention. Keep a regression set and log the model and effort setting on each run so you can explain changes later.

Related reading

The build log

Follow the work.

New essays and prototypes, in your feed reader. Email subscriptions are paused while I connect a working delivery service. No email is collected here.

Follow via RSS