Originally published on Extenify.
The Claude API 2026-10-21 migration is the first new anthropic-version since 2023-06-01, and it arrives bundled with new major SDKs, including @anthropic-ai/sdk 1.0.0. The catch for Node.js teams: a plain npm install @anthropic-ai/sdk now pulls 1.x, and 1.x quietly switches you to the new API version. Here are the four changes most likely to break a working backend, and how to get through them without a bad deploy.
The rule is tied to your SDK's major version. Stay on 0.x and your requests keep sending 2023-06-01. Move to 1.x and every request sends 2026-10-21. The same jump happened across the other official SDKs (Python 2.0, Go 2.0, Java 3.0 and so on).
Two reassuring facts before the bad news:
2023-06-01 is still listed, and 2026-10-21 only works for Claude 4.7 and later models, so older Bedrock calls should stay on the current SDK until you move the model.
This is the one most backends will hit. Version 2026-10-21 removes all three sampling parameters from the Messages API. Send any of them, even at its default value, and the request fails with a 400 on every model.
The sneaky part is the language you write in. With TypeScript, a leftover temperature fails to compile against SDK 1.x. With plain JavaScript there is no such guard: the SDK forwards it in the body, and your first warning is a 400 in production.
Before upgrading, sweep the codebase:
grep -rnE "temperature|top_p|top_k" src/
Look beyond direct calls. Shared config objects, a model-settings table, or an OpenAI-style wrapper that injects temperature for every provider will all trip the new validation. Without the parameters, requests sample with defaults (temperature 1.0). Claude 4.7+ already only accepted defaults, so nothing changes there, but on older models that honored a low temperature, that effect is simply gone. If a request truly depends on it, the option is to keep that request on 2023-06-01.
Message Batches follow the same rule, so a nightly job that still sets temperature will fail request by request.
SDK 1.x sends the key as Authorization: Bearer <key> instead of X-Api-Key. The Claude API accepts either, so code talking to Anthropic directly is fine. What breaks is whatever sits in between: a gateway set via baseURL, logging middleware, or a rate limiter that reads X-Api-Key.
That is a common shape for AI-powered browser extensions, where the provider key lives on a server behind your own proxy. The proper fix is to teach the proxy to read the bearer token. As a stopgap, you can point the SDK back at the old header while you update the gateway:
const client = new Anthropic({
baseURL: process.env.LLM_GATEWAY_URL,
defaultHeaders: { 'X-Api-Key': process.env.ANTHROPIC_API_KEY, Authorization: null },
});
If you call the API with fetch instead of the SDK, migration is two edits: send anthropic-version: 2026-10-21 and drop the sampling parameters. Either key header works.
client.completions, the Completion types and the HUMAN_PROMPT / AI_PROMPT constants are gone in 1.x. Any legacy code still building "\n\nHuman: ..." prompts needs to move to client.messages.create(), where the reply lives in message.content.
Two smaller changes catch typed codebases and server configs:
MessageParam is now a unioninterface can no longer extend it (use an intersection type instead), and any helper that rewrites content for every role must check the role first, since system content only accepts text.apiKey and authToken now throws a TypeError. If both environment variables are set on a server, the API key wins and a warning is logged once.
Also on the list: Node.js 20 or later is required, the Bedrock/Vertex/Foundry platform packages must move to v1 in the same upgrade (or you end up with two copies of the SDK), and the license changes from MIT to Apache 2.0, which belongs in your dependency records.
There are API-level changes outside the SDK too: document blocks are rejected in assistant messages, citations are rejected in user messages, and several Admin API fields were renamed.
anthropic-version. X-Api-Key. tsc --noEmit.
Logs only show request errors. If output quality shifts after the default temperature kicks in, the first signal is often a user review saying the AI feature "got worse", so watch reviews and ratings after the deploy too.
temperature, top_p and top_k now cause a 400. TypeScript catches them, plain JavaScript does not.Authorization: Bearer, which breaks proxies that read The original post has the full side-by-side test of SDK 0.137.0 vs 1.1.0 and a FAQ: read the complete Claude API 2026-10-21 migration guide for Node.js. If you ship an AI extension or app, Extenify tracks reviews, ratings and versions across the stores so you can see how a release lands with users.
Have you upgraded to @anthropic-ai/sdk 1.x yet, and did the temperature removal or the header change bite you first?