Anthropic
Blogcast

Alex: Welcome back to the Anthropic Blogcast, where we break down the latest from Anthropic so you don't have to read the blog yourself. I'm Alex.

Jordan: And I'm Jordan. Today we're digging into the claude dot dev developer guide for Claude Sonnet 5.5, the newest model in the Claude 5.5 family.

Alex: Right, Sonnet 5.5 landed as the second model in the 5.5 lineup, right after Opus 5.5. And the headline numbers are pretty striking. It's a clear upgrade over Sonnet 5, it runs thirty percent faster, and because it typically needs far fewer tokens to do the same work, it costs up to thirty percent less for most work, even though the per-token price hasn't moved.

Jordan: Same price on the invoice line, but the model is just more efficient, so your actual bill drops.

Alex: Exactly. Now, the guide is aimed at builders, so let's start with the big question it answers: when do you reach for Sonnet 5.5 versus Opus 5.5?

Jordan: The rule of thumb is pretty clean. Opus 5.5 is built for complex work that requires careful judgment, long-horizon agentic coding, the hardest problems. Sonnet 5.5 is for well-scoped everyday tasks: fixing bugs, quickly iterating on features, verifying against requirements.

Alex: Plus high-volume everyday development, polished documents, slides and spreadsheets, and well-defined agent tasks you run repeatedly, like investigation, review, and drafting. The guide's phrasing is nice: Sonnet 5.5 fits best when the task has a clear spec and a way to check the result.

Jordan: Plus it has a strong design eye for documents, slides, and spreadsheets.

Alex: Okay, pricing. This is concrete and worth getting right. Per million tokens, Sonnet 5.5 charges two dollars for input and ten dollars for output. Opus 5.5 is exactly double: four dollars in, twenty dollars out.

Jordan: Cache pricing matters too. Cache writes are two fifty for five minutes, four dollars for one hour, and cache reads are just twenty cents per million tokens, same on both models. And all Sonnet 5.5 prices match Sonnet 5's, so swapping the model ID doesn't change your per-token bill.

Alex: One pricing nuance: US-only inference costs one point one times the standard price.

Jordan: Good tip. Now the model details table. The model ID is claude-sonnet-5-5 on the Claude API, on the Claude Platform on AWS, Google Cloud, and Microsoft Foundry, and anthropic dot claude-sonnet-5-5 on Amazon Bedrock. Native one-million-token context window, no beta header needed. Max output of one hundred twenty-eight thousand tokens, and up to three hundred thousand on the Message Batches API with a beta header.

Alex: Knowledge cutoff is June twenty twenty-six. Thinking is on by default, adaptive thinking, and you can turn off upfront thinking with a new between_tools mode. Effort levels are low, medium, high, extra high, and max, with high as the default on the API and medium in Claude Code. Minimum cacheable prompt dropped to five hundred twelve tokens, half of Sonnet 5's one thousand twenty-four, so shorter system prompts and tool definitions now qualify for caching.

Jordan: That cache threshold change is quietly big for agents with compact tool definitions. Now, migration. If you're moving from Sonnet 5, change the model ID, then work through five breaking changes and one response-shape change.

Alex: Let's walk them. First, turn off upfront thinking with between_tools. On Sonnet 5.5, a request with no thinking field runs with adaptive thinking, and the old thinking-disabled setting returns a 400 error. You send the new between_tools type instead, which only thinks between tool calls, and total response time is the same or faster.

Jordan: But between_tools has limits: it only works at low, medium, and high effort. At extra high or max it errors, so use adaptive thinking there. And the progress updates the model writes between tool calls still come back as thinking blocks, so read content blocks by type instead of grabbing the first block.

Alex: Which is a code change for a lot of people, because Sonnet 5.5 thinks by default and a response can begin with a thinking block. The guide even gives a sample request that loops over response blocks and checks the block type before printing.

Jordan: Second breaking change: replace forced tool_choice with auto plus strict tools. A tool_choice of type any or tool now returns a 400 error. Instead, send auto, mark the tool strict true, and say in the prompt when to use it.

Alex: Third: keep conversations append-only. Sonnet 5.5's thinking blocks are tied to the model and the conversation. It reads Sonnet 5's thinking blocks, so a conversation you switch mid-stream keeps its reasoning, but no other model reads Sonnet 5.5's blocks.

Jordan: Fourth: move computer use to the toolset. On the Claude API and Google Cloud, Sonnet 5.5 supports computer use only through the computer toolset type, and the old computer_20251124 declaration errors out. You also drop the old beta header. Amazon Bedrock still accepts the old style, which is worth knowing.

Alex: Fifth: check your advisor pairing. A Sonnet 5.5 executor rejects older advisors like Opus 4.8 and Sonnet 5; accepted advisors include Opus 5.5 and Opus 5, and their advice comes back encrypted.

Jordan: And the sixth change, the response-shape one: read text between tool calls from thinking blocks. A UI can stop showing the model's notes between tool calls, because longer notes come back as progress-update thinking blocks that are empty at the default display setting. With adaptive thinking, set thinking display to updates or summarized, and render each non-empty thinking block before the tool use block that follows it.

Alex: Good news for migration: Claude Code can do it for you. Run the slash claude-api migrate command with the new model ID, and the bundled skill applies the model ID swap and the breaking parameter changes across your codebase.

Jordan: Now tuning. First: re-run your effort sweep. Effort levels are recalibrated, so a level doesn't produce the same thinking as it did on Sonnet 5. Start with high unless your workload is agentic or latency-sensitive. For agentic coding, start medium for well-specified tasks and move to high for harder ones. For chat, start medium or low. Use extra high or max only where your evals show a quality gain.

Alex: And remember thinking counts toward max tokens, so leave room. For agentic coding, set max tokens to one hundred twenty-eight thousand and stream the response. To get less thinking, lower the effort level, because asking the model in the system prompt to think less doesn't reliably reduce it.

Jordan: Second tuning tip: remove your Sonnet 5 workarounds. If your prompts carry refusal steering, tool-call retry shims, or do-not-be-lazy instructions, remove them and re-run your evals before tuning anything else. The new model shouldn't need them.

Alex: Third: ask for real checks at low effort. Sonnet 5.5 generally checks its work before reporting a change as done, but at low effort it sometimes skips a check that exercises the change. The guide gives a system-prompt paragraph you can add: when you change code that can be run, built, or type-checked, run a real check that exercises the change before reporting it done, the project's tests, type-checker, or build. A syntax-only check doesn't count.

Jordan: I like that one. Fourth: use thinking display for progress. Don't ask the model to write out its reasoning in the response, because that invites reasoning extraction declines. Read summarized thinking instead. And fifth: cache more of your prompt. With the minimum down to five hundred twelve tokens, shorter prompts qualify, and a cache read costs a tenth of the input price. One caveat: changing top-level effort between requests invalidates the cache, so use per-message effort in beta to keep it.

Alex: Let's talk refusals, because the behavior changed in a way developers should know. On their automated behavioral audit, Sonnet 5.5 improves on or matches Sonnet 5 on most measures of alignment and honesty, and it's the first Sonnet model with cybersecurity safeguards similar to the most capable models. Most routine software development is unaffected.

Jordan: The API shape is the important part: a declined request returns HTTP 200 with stop reason refusal, and stop details names one of five categories: cyber, bio, frontier LLM, reasoning extraction, or general harms. So your code should check stop reason, not just status codes.

Alex: And server-side fallback, in beta on the Claude API, retries cyber and frontier LLM declines on Sonnet 5. You can also roll your own retry with the SDK middleware.

Jordan: Availability. Sonnet 5.5 is available today on the Claude API, Amazon Bedrock, the Claude Platform on AWS, Google Cloud, and Microsoft Foundry, where it's Global Standard deployments only. In Claude Code, from version 2.1.284, the sonnet alias resolves to Sonnet 5.5 on the Claude API. It runs at medium effort by default, with the one-million context native, and you can't turn thinking off in Claude Code. The default model stays Opus 5.5, so switch with slash model sonnet for well-scoped tasks.

Jordan: So the bottom line for builders: Sonnet 5.5 is faster, cheaper in practice, and tuned for the everyday work, but migration has real breaking changes, so read the guide, run your evals, and re-sweep your effort levels before you swap the model ID.

Alex: That's the guide. As always, links to the full article are on the episode page. Thanks for listening to the Anthropic Blogcast.

Jordan: Produced by The Joy Digi. We'll catch you on the next one.