Claude API version 2026-10-21 removes temperature, top_p, and top_k entirely and ships SDK 2.0 with breaking changes. Here's what broke and how to migrate.
Vamsi Tallapudi
Manager, Architect Technology at Cognizant
Anthropic shipped a new Claude API version on October 21, 2026 (2026-10-21), and it's the first version bump since 2023-06-01. Three years of stability, then in one release: temperature, top_p, and top_k are gone from the Messages API, every official SDK jumped a major version, and the license switched from MIT to Apache 2.0. If you run anything against the Claude API, you have work to do before you touch this version.
Here's the short version: none of this breaks you until you opt in. The old 2023-06-01 version keeps working with no deprecation date attached. But every SDK released on or after October 21 defaults to 2026-10-21, so the moment you run npm install @anthropic-ai/sdk@latest or pip install -U anthropic, you're on the new rules whether you read the changelog or not.
Sampling parameters are deleted, not deprecated. Send temperature, top_p, or top_k on a 2026-10-21 request (even set to the exact default value) and you get a 400 error. Not a warning, not a silent ignore. A hard failure. There's no replacement setting. If your evals or your product depend on a specific temperature for consistent output, that lever is gone.
Document blocks can't sit directly in assistant messages anymore. Put a document block straight into an assistant message and it's a 400. Nest it inside something Claude returned, like a web fetch tool result, and it's still fine, just not as a raw top-level block.
Citations are off-limits in user messages. A text block with a non-empty citations array in a user message now 400s too, including inside search_result blocks. Citations on assistant messages you send back (Claude's own earlier replies) are untouched, and the "citations": {"enabled": true} setting on documents still works fine.
A chunk of Admin API and Enterprise Analytics fields got renamed, and the old names just vanish from responses on this version:
| Endpoint | Old field | New field |
|---|---|---|
| RBAC groups | roles | role_ids |
| RBAC group members | group_id | rbac_group_id |
| RBAC roles | name | display_name |
| Rate limits | group_type | group.type |
| API keys | workspace_id | scope |
| Per-user usage/cost reports | actor.email | actor.email_address |
| Activity summaries | summaries | data |
If your billing dashboard or internal tooling reads any of these by name, it silently breaks: no error, just missing data where the old key used to be.
This is the part that actually matters, and it's not really about this specific release: Anthropic is just catching up to a trend. OpenAI locked sampling on o1, o3, and GPT-5. Google tells you not to touch it on Gemini 3. Anthropic had already deprecated temperature on Opus 4.7 and kept that going through 4.8. Reasoning models do internal multi-pass verification and self-correction, and an external "make it more random" knob fights against that process instead of tuning it. So 2026-10-21 just makes official, at the API level, what the frontier models were already doing.
Here's my honest take: for most people reading this, nothing changes. If you're already on Claude Opus 5, Opus 5.5, Sonnet 5.5, or anything 4.7+, those models only ever accepted the default anyway: you were sending a parameter that did nothing. The group that actually gets hurt is anyone still pinned to an older model like Sonnet 4.6 who was relying on a lowered temperature for more deterministic output. That control just disappears with no substitute. If that's you, the honest move is to stay on 2023-06-01 for that specific integration until you can validate the model switch, not to just strip the parameter and hope.
Every official SDK bumped its major version on the same day, and they all default to 2026-10-21 now:
anthropic 2.0.0@anthropic-ai/sdk 1.0.0 (yes, TypeScript was still pre-1.0)github.com/anthropics/anthropic-sdk-go/v2com.anthropic:anthropic-java 3.0.0Anthropic 13.0.0anthropic-ai/sdk 1.0.0anthropic gem 2.0.0ant CLI: 2.0.0The biggest structural change across languages: MessageParam used to be one type for every role. Now it's a union (UserMessageParam, AssistantMessageParam, SystemMessageParam) because system messages in the beta surface carry fields (clear_at, output_config) that user and assistant messages never had, and cramming them into one shape was getting awkward. If your code builds messages as plain dict/hash/object literals with a role key, you're probably fine. If you construct MessageParam objects directly, subclass them, or write a function generic over "any message role," you need to touch that code.
A few other things that'll trip people up:
Authorization: Bearer <key> instead of X-Api-Key. The API still accepts either, so direct callers are safe. But any proxy or gateway that reads X-Api-Key specifically will see requests with no credential it recognizes. Silent failure, not an error.compactionControl is deleted; you need context_management with the compact-2026-01-12 beta header instead, which moves the summarization server-side.client.completions.create() instead of client.messages.create(), this is the version that finally forces the move.On Amazon Bedrock, 2026-10-21 only works with Claude 4.7 and later models: anything older on Bedrock has to stay on the SDK version it's already running.
This is where I'd stop reading the diff line by line and just let the tooling do it. Claude Code ships with the claude-api skill, and it's built specifically for this kind of migration. It activates automatically the moment your project imports an Anthropic SDK, or you can call it directly:
/claude-api migrate this project to the latest Claude Opus model
It handles the mechanical stuff: swapping model ID constants, stripping temperature/top_p/top_k calls, converting thinking: {type: "enabled", budget_tokens: N} to the newer adaptive form, cleaning up beta headers your target model doesn't need anymore, and recommending an effort level for the model you're moving to. It explains each edit as it makes it and hands you a checklist at the end: mostly things like "re-run your evals" and "re-baseline rate limits" that no tool can verify for you.
If you'd rather do it by hand, the full breaking-changes list and per-language before/after code lives in the official migration guide. Either way, test against 2026-10-21 in staging before you ship it. Don't find out about a stripped temperature call in production logs.
temperature, top_p, top_k in Messages/Batch calls and decide, per call site, whether you drop the parameter or pin that integration to 2023-06-01X-Api-KeyMessageParam/BetaMessageParam construction or subclassing in your languagecompactionControl, move it to context_management with the compact-2026-01-12 betaNone of this is urgent in the sense of "your integration breaks tomorrow." It's urgent in the sense of "the next time you run an SDK upgrade without reading the changelog, you're already on it."
Related reading: if you're also deciding which model to target during this migration, see our breakdown of the Claude Opus 5 launch and Claude Haiku 5.5 explained. If you're trying to control API spend while you migrate, check Claude Code usage limits and cost.
New AI tools, automation workflows, and course drops — straight to your inbox. Join 2,400+ builders.
Earshot is an open-source, CPU-only MCP server that gives Claude Code and other coding agents the ability to hear, score, and synthesize sound effects.
A $7 ESP32-S3 board lets any OpenAI-compatible vision model see and control a real iPhone via AirPlay and USB HID, no jailbreak or Mac required at run time.
Mistral's Voxtral 3 adds a LiveKit-based voice agent SDK with tool calling, starting at $0.04 a minute, plus new speech-to-text and TTS models.
Comments