Skip to main content

What Actually Changed in Claude Sonnet 5 (and Why I'm Switching My Agents to It)

By Upendra

A precision-cut gem focusing a beam of light to a single bright point

Claude Sonnet 5 shipped on June 30. Anthropic's framing was "a cheaper way to run agents," which is technically accurate but undersells what's actually interesting here. The benchmark I keep coming back to is Terminal-Bench 2.1: Sonnet 5 scores 80.4%, while Opus 4.8 scores 74.6%. The mid-tier model now beats the top tier on agentic terminal tasks. On GDPval-AA v2, a knowledge work eval, Sonnet 5 scores 1,618 Elo versus Opus 4.8's 1,615, basically a dead heat.

Opus 4.8 still leads on SWE-bench Pro (69.2% vs Sonnet 5's 63.2%) and OSWorld-Verified (83.4% vs 81.2%). For hard multi-step coding and complex computer-use flows, Opus is still the call. But for most of what shows up in an agent loop, Sonnet 5 at $2 per million input tokens and $10 per million output tokens (introductory pricing, through August 31) is a genuinely different calculus than Sonnet 4.6 was.

That said, migrating isn't a find-replace on the model ID. Three changes in Sonnet 5 will break code that worked fine on Sonnet 4.6.

Adaptive Thinking Is On by Default Now

On Sonnet 4.6, if you didn't pass a thinking field, the model ran without thinking. On Sonnet 5, that same request runs with adaptive thinking enabled. For latency-sensitive paths, this will surprise you. And if you've tuned max_tokens around expected response length without accounting for thinking tokens, you may start seeing truncation.

To disable it explicitly:

thinking = {"type": "disabled"}

Manual extended thinking with budget_tokens now returns a 400 error on Sonnet 5, the same as on Opus 4.8. If you were using extended thinking on Sonnet 4.6, you need to migrate to the new effort parameter (low, medium, high, max, x-high) before you update the model ID. The old budget_tokens approach is gone.

The New Tokenizer Changes Your Cost Model

Same text, approximately 30% more tokens than on Sonnet 4.6. This is the one that catches you off guard, because everything else in the API looks identical. Same request shape, same response format, same streaming events. The usage field just comes back with higher counts for inputs and outputs that haven't changed.

What that means practically:

  • Re-run your cost estimates. The per-token price is unchanged ($2/$10 intro, $3/$15 standard from September 1), but 30% more tokens means 30% higher cost for the same text. Model your costs against claude-sonnet-5, not your Sonnet 4.6 numbers.
  • Your effective context capacity shrinks. 1M token context window still, but each token covers less text now. A prompt that fit cleanly before may run tight.
  • max_tokens limits may truncate. If you sized max_tokens close to your expected output length on Sonnet 4.6, revisit those limits before migrating.

I haven't run this across a large production pipeline yet, so I don't have an empirical multiplier for code-heavy versus text-heavy workloads. Budget conservatively until you do.

Temperature and Top-P Now Return 400

If your code passes temperature, top_p, or top_k to Sonnet 4.6, those same calls fail on Sonnet 5 with a 400 error. This constraint already existed on Opus 4.7 and 4.8. Anthropic has now extended it to Sonnet-class models.

The fix is the same one that works on Opus: use system prompt instructions to guide tone and behavior instead of sampling parameters. If you have a shared wrapper or middleware that injects sampling params for all Claude calls, that wrapper needs updating before you flip model IDs anywhere.

When to Still Use Opus 4.8

Sonnet 5 doesn't retire Opus 4.8. The SWE-bench Pro gap (63.2% vs 69.2%) matters for hard coding tasks where correctness is load-bearing. If your agent is doing complex multi-file refactors or algorithmic problem-solving where a mistake downstream compounds, Opus is still the more reliable choice.

My current routing after this launch: Sonnet 5 as the default for agentic loops, tool use, search, computer use, and anything where throughput matters. Opus 4.8 reserved for final synthesis steps in a pipeline, or tasks where the cost of a coding error is genuinely high.

Two things to check before switching: Sonnet 5 isn't available on the Priority Tier service tier, and it's not supported on the legacy InvokeModel or Converse APIs on Amazon Bedrock (only the newer Bedrock API). If you're on either path, confirm compatibility before updating configs.

The Pricing Window

The $2/$10 intro pricing holds through August 31, then moves to $3/$15. That's about two months to measure actual costs under the new tokenizer and decide whether the performance-to-cost ratio holds up for your specific workloads before the full rate kicks in.

The official migration guide covers all the API changes in detail. Read it before you touch the model ID string.

Labels:

Comments

Post a Comment

Popular posts from this blog

AngularJs call one method of controller in another controller .

By Upendra
I have seen many question about calling one method of one controller in another controller or extending scope of one controller in another controller.so here are the ways. if you want to call one controller into another or extending scope of controllers there are four methods available $rootScope.$emit() and $rootScope.$broadcast() If Second controller is child ,you can use Parent child communication . Use Services Kind of hack - with the help of angular.element() 1. $rootScope.$emit() and $rootScope.$broadcast() Controller and its scope can get destroyed, but the $rootScope remains across the application, that's why we are taking $rootScope because $rootScope is parent of all scopes . If you are performing communication from parent to child and even child wants to communicate with its siblings, you can use $broadcast If you are performing communication from child to parent ,no siblings invovled then you can use $rootScope.$emit HTML <body ng-app = ...
7 comments
Read more

Closures in javascript and how do they work ?

By Upendra
JavaScript Closures for Dummies  Closures Are Not Magic This page explains closures so that a programmer can understand them — using working JavaScript code. It is not for gurus or functional programmers. Closures are  not hard  to understand once the core concept is grokked. However, they are impossible to understand by reading any academic papers or academically oriented information about them! This article is intended for programmers with some programming experience in a mainstream language, and who can read the following JavaScript function: function sayHello ( name ) { var text = 'Hello ' + name ; var sayAlert = function () { alert ( text ); } sayAlert (); } An Example of a Closure Two one sentence summaries: a closure is the local variables for a function — kept alive  after  the function has returned, or a closure is a stack-frame which is  not deallocated  when the function returns (as if a 'stack-fr...
Post a Comment
Read more

250,000 AI Agent Instances Exposed on the Internet — Is Yours One of Them?

By Upendra
If You're Running OpenClaw, You May Want to Read This A public watchboard has surfaced listing over 250,000 OpenClaw instances that are directly reachable from the internet. Some of these instances have leaked credentials. Many are running on infrastructure already flagged for known CVEs and threat actor activity. This isn't theoretical. It's happening right now. You can check the exposure list yourself at openclaw.allegro.earth . Why This Is a Big Deal OpenClaw is a powerful AI agent framework. That power comes with serious responsibility. A typical OpenClaw deployment runs with: Personal API keys — OpenAI, Anthropic, Google, cloud provider credentials Broad system permissions — file access, shell execution, network requests Autonomous execution capabilities — the agent can act without human approval Complex codebases — large attack surfaces that haven't been fully audited When one of these instances is publicly reachable without authentication...
Post a Comment
Read more