Claude Opus 5.5 API-guide: Modell-ID:t, fyra brytande ändringar och den tysta femte

Ändra modellsträngen från claude-opus-5 till claude-opus-5-5 och din kod kompilerar fortfarande, typkontrolleras fortfarande och klarar fortfarande vad som än räknas som en testsvit. Sedan svarar den 400 i produktion. Fyra förfrågningsformer som Claude Opus 5 accepterade avvisas direkt av Claude Opus 5.5, och en femte ändring bryter inte någonting alls — vilket är precis varför det är den som kommer att nå dina användare. Detta är integrationsreferensen för modellen: identifieraren, ytorna som betjänar den, förfrågningskontraktet, de fyra felen, den tysta femte och hur effort-parametern fungerar nu. Där beteendet matchar Claude Fable 5.1 har ett team som redan migrerat dit gjort en del av arbetet, så varje ändring nedan anger om den gäller den modellen också.

Allt här är hämtat från Anthropics egen Claude-dokumentation den 24 september 2026, två dagar efter att modellen släpptes. Leverantörspåståenden märks som leverantörspåståenden, oberoende siffror som oberoende, och de två presenteras aldrig vid samma ansträngningsnivå som om de vore jämförbara.

Modell-ID:t och var den serveras

Identifieraren är claude-opus-5-5 – ett fast modell-id utan datasuffix, samma schema som claude-opus-5. Det finns ingen separat pinnad snapshot-form att använda och inget alias som löser upp till något annat.

Anthropics modellöversikt listar fem ytor, med dessa exakta strängar:

• Claude API — claude-opus-5-5, tillgänglig för alla kunder.

• Amazon Bedrock — anthropic.claude-opus-5-5 (den enda ytan som har leverantören som prefix).

• Claude Platform on AWS — claude-opus-5-5, med Claude API-id:n i stället för id:n i Bedrock-stil.

• Google Cloud — claude-opus-5-5.

• Microsoft Foundry — claude-opus-5-5; det du skickar är distributionsnamnet, och Foundry följer livscykelschemat för Claude API.

Två av dessa fem är viktigare än resten av det här avsnittet. Amazon Bedrock och Google Cloud sätter sina egna datum för livscykel och avveckling, och – som de brytande ändringarna nedan visar – är Bedrock också den enda plattformen där det gamla datoranvändningsverktyget fortfarande fungerar. Om du kör på Bedrock är du inte i samma migrering som alla andra.

Vad varje förfrågan måste uppfylla nu

Anthropics migreringsguide anger kontraktet i form av en lista, och listan är tillräckligt kort för att du ska kunna kontrollera din egen klient mot den. Oavsett vilken modell du kommer från måste en begäran till claude-opus-5-5:

• Skicka antingen inget thinking-fält eller thinking: {"type": "adaptive"} – de två är likvärdiga, eftersom adaptivt tänkande alltid är på.

• Styr tankedjupet med effort, den enda förfrågningsparametern som gör det; alla fem nivåerna stöds och standardvärdet är medium.

• Använd tool_choice med {"type": "auto"} (standard) eller {"type": "none"}. Att tvinga fram ett verktyg avvisas.

• Utelämna temperature, top_p och top_k, eller lämna dem vid sina standardvärden. Alla andra värden avvisas, på den här modellen liksom på allt från Claude Opus 4.7 och framåt.

• Avsluta inte meddelanden med en förifylld assistenttur; det avvisades redan på Opus 4.6 och senare.

• Deklarera datoranvändning som computer_toolset_20260801 verktygsuppsättningen i Claude API och Google Cloud.

• Skicka ingen beta-header för kontextfönstret. Kontextfönstret på 1M är standard, och en header skriven för en äldre modell har ingen effekt.

Där guiden säger att en inställning avvisas returnerar API:et HTTP 400. Det är hela felmoden med att gå över till den här modellen: inte försämrad utdata, inte en varning i en logg – en begäran som aldrig körs.

De fyra brytande ändringarna

1. Tänkande kan inte inaktiveras

Adaptivt tänkande är alltid på. thinking: {"type": "disabled"} returnerar en 400, och det gör även en manuell budget — thinking: {"type": "enabled", "budget_tokens": N}. Felmeddelandet namnger typen du skickade och namnger sedan ersättningen:

• "thinking.type.disabled" stöds inte för den här modellen. Använd "thinking.type.adaptive" och "output_config.effort" för att styra tänkandebeteendet.

• "thinking.type.enabled" stöds inte för den här modellen. Använd "thinking.type.adaptive" och "output_config.effort" för att styra tänkandebeteendet.

Den praktiska konsekvensen är inte felet, utan vad som händer efter att du har åtgärdat det. På Claude Opus 4.8 och tidigare kördes en förfrågan utan thinking-fält utan thinking. På Claude Opus 5.5 tänker varje förfrågan, och max_tokens är fortfarande en hård gräns som omfattar thinking plus svarstext. Thinking-tokens faktureras som output-tokens även när thinking-texten aldrig returneras till dig. En endpoint som tidigare kördes utan thinking kan därför producera fler output-tokens per förfrågan efter ”fixen” än den gjorde tidigare. Anthropics råd är att sänka effort där du tidigare inaktiverade thinking, och – vid xhigh eller max effort – att börja med max_tokens på 64k och finjustera därifrån.

Svarets form ändras också. Ett svar kan börja med ett eller flera tankeblock före det första textblocket, så kod som läser svaret utifrån position — content[0].text, eller en strömhanterare som behandlar det första content_block_start som text — går sönder på dessa svar även när begäran lyckades. Välj block utifrån deras type-fält i stället.

2. Tvingad verktygsanvändning returnerar ett fel

tool_choice typer any och tool returnerar en 400, och samma validering gäller för slutpunkten för tokenräkning, så en förhandskontroll misslyckas på samma sätt som det verkliga anropet gör:

• tool_choice: typerna "tool" och "any" stöds inte för den här modellen.

Auto och none påverkas inte. Den dokumenterade ersättningen är att behålla tool_choice: {"type": "auto"}, markera verktyg med strict: true för schema-giltiga argument, eller flytta schemat till strukturerade utdata – och att ange i prompten när verktyget gäller, eftersom auto inte garanterar ett anrop. Strikt verktygsanvändning accepterar en delmängd av JSON Schema: varje objekt i ett verktygs input_schema måste ange additionalProperties: false, så kontrollera varje schema innan du slår om flaggan. Och notera luckan detta lämnar: om din kod var beroende av att tvinga fram ett anrop i stället för att bara tillåta ett, återställer auto tillståndet och inte garantin. Kontrollera att ett tool_use-block faktiskt kom tillbaka.

3. Tankeblock är bundna till modellen och till konversationen

Varje tankeblock registrerar vilken modell som producerade det, och varje modell läser sina egna block plus en definierad uppsättning av andras. Reglerna gäller i båda riktningarna:

• Claude Opus 5.5 läser tankeblock från Claude Opus 5 och tidigare Opus-, Sonnet- och Haiku-modeller – men inte från modellerna Claude Fable eller Claude Mythos.

• I Claude API:t läser Claude Fable 5.1 och Claude Mythos 5.1 block från Claude Opus 5.5. Ingen annan modell gör det.

• Ett samtal som går från Claude Opus 5.5 till något annat än dessa två kör sina senare turer utan det tidigare resonemanget.

En router eller fallback som flyttar en konversation är det uppenbara sättet att åstadkomma detta. Den subtilare hälften är att blocket också är bundet till konversationens prefix – systemprompten, verktygen och varje meddelande före det. Anthropic tillämpar prefixkontrollen som standard för konton som skapats den 2026-08-31 00:00 UTC eller senare, i Claude API och på molnplattformar: spela upp ett block igen efter att ha redigerat systemprompten, verktygslistan eller ett tidigare meddelande, och begäran returnerar 400. Det finns två nödutgångar. Skicka betarubriken thinking-binding-controls-2026-08-01 och ställ in thinking.block_binding.prefix_mismatch_behavior på "drop_block" för att släppa de berörda blocken i stället för att begäran misslyckas. Eller håll konversationen enbart tilläggande och ändra instruktioner med ett systemmeddelande mitt i konversationen i stället för en redigering – vilket Claude Code, claude.ai, Claude Managed Agents och Claude Agent SDK redan gör.

Det finns en god nyhet som är lätt att missa: när en begäran innehåller ett block som målmodellen inte kan läsa, tar API:et bort det innan modellen ser det. Begäran lyckas, och borttagna block debiteras inte.

4. Det äldre verktyget för datoranvändning avvisas i Claude API och Google Cloud

En verktygspost av typen computer_20251124 returnerar en 400 i Claude API och Google Cloud. Meddelandet namnger den avvisade typen och listar sedan de typer som modellen faktiskt accepterar:

• 'claude-opus-5-5' stöder inte verktygstyper: computer_20251124.

Ersättningen är computer_toolset_20260801 verktygsuppsättningen: ta bort computer-use-2025-11-24 betahuvudet och skicka tools-posten utan namn och utan visningsdimensioner. Detta är inte bara en ändring i begäran – agentloopen ändras med den. Åtgärder anländer som member tool_use-block i stället för ett enda datorverktyg, det kan finnas flera i en tur, åtgärden är blockets name i stället för input.action, och varje resultat måste eka tillbaka toolset_name. På Amazon Bedrock fortsätter computer_20251124 att fungera precis som det gör på Claude Opus 5 och ingen ändring behövs.

Vilka av de fyra gäller också för Claude Fable 5.1?

Anthropic uppger att de tre första även gäller för Claude Fable 5.1 – alltid påslaget tänkande, inget framtvingat verktygsval samt tänkandeblock som är bundna till modell och konversation. Ändringen för datoranvändning gör det inte: den är specifik för den här modellen i Claude API och Google Cloud. Ett team som redan har gått över till Claude Fable 5.1 har alltså avvecklat sina kodvägar med tänkandet avstängt och sina framtvingade verktygsval, och har ett konversationsmönster där man bara lägger till i slutet; det som återstår är modell-id:t och verktygsuppsättningen för datoranvändning. Ett team som kommer från Claude Opus 5 möter alla fyra på en gång. Det är migreringen som är värd att planera in, och det är en annan mängd arbete beroende på var man börjar.

Den femte ändringen: inga fel uppstår, och ditt framstegsflöde tystnar

På Claude Opus 5 kommer de korta anteckningar som modellen skriver mellan verktygsanrop tillbaka som vanliga textblock. På Claude Opus 5.5 – liksom på Claude Fable 5.1 – returneras den berättande texten som tankeblock för förloppsuppdateringar, som mest ett före varje verktygsanrop. Och thinking.display är standardinställt på "omitted", så dessa block anländer med ett tomt thinking-fält vid sidan av sin signatur.

Ingen förfrågan misslyckas. Inget fel loggas. En applikation som strömmar texten mellan verktygen till sina användare som en förloppsindikator slutar helt enkelt visa förlopp mellan verktygsanrop och börjar visa ingenting. Det synliga symptomet är ett gränssnitt som verkar fryst under den exakta arbetsperioden där användaren som mest vill bli lugnad, och det kommer att rapporteras som ett prestandaproblem, ett nätverksproblem eller en hängning — inte som en migreringsbugg. Det här är ändringen som går ut i produktion.

Lösningen är en visningsinställning, plus en läsning som matchar den:

• Ställ in thinking.display till "updates" — beta, bakom thinking-display-updates-2026-08-18-headern — för att få tillbaka förloppsuppdateringarna medan själva resonemanget förblir dolt. Det här är inställningen som ett förloppsflöde vill ha.

• Eller ställ in det på "summarized" för att få förloppsuppdateringar och sammanfattningar av resonemang blandade i samma block.

• Läs sedan texten från thinking-block i stället för text-block, rendera varje icke-tomt thinking-block före det tool_use-block som det föregår, och skicka tillbaka blocken oförändrade tillsammans med resten av assistentturen.

Anthropics egen anteckning om detta är värd att citera till sin anda: ett gränssnitt som renderar text mellan verktygsanrop förväntas ange ett visningsvärde i stället för att förlita sig på standardvärdet. Om din integration helt ignorerar tänkandeblock i dag, är det den enda platsen där standardvärdet är säkert.

Ansträngning är API-ytan

När tänkandet inte går att stänga av, output_config.effort blir den enda ratten för hur mycket modellen resonerar, och därmed den enda ratten för kostnad och latens vid en given uppgift. Fyra saker om den är värda att känna till innan du kopierar över en inställning från den gamla modellen.

Standardinställningen har ändrats. Claude Opus 5.5 har medium effort som standard, medan Claude Opus 5 och tidigare Opus-modeller hade high som standard. En begäran som utelämnar effort körs nu en nivå lägre än den gjorde före bytet. Anthropic dokumenterar också att modellen tenderar att tänka mer per tur vid en given effort-inställning än Claude Opus 5 gjorde, framför allt vid xhigh och max. Dessa två effekter drar i motsatta riktningar, vilket är precis anledningen till att leverantörens instruktion är att köra en ny svepning av effort-inställningar på dina egna utvärderingar i stället för att översätta en inställning rakt av.

Skalan är low / medium / high / xhigh / max, alla fem stöds här. Den namngivna nivån är inte ens från början en fast tokenbudget – Anthropic beskriver effort som en beteendesignal, inte en strikt budget – och tokenallokeringen bakom varje nivå ändrades mellan modeller, så "high" på Claude Opus 5.5 är inte "high" på Claude Opus 5. Att ställa in effort till modellens standardvärde är identiskt med att utelämna det.

Två operativa detaljer, eftersom båda kostar pengar om de missas. För det första: att ändra effort-värdet på toppnivå mellan förfrågningar ogiltigförklarar promptcachen: välj en nivå och håll den konstant i en konversation som förlitar sig på cacheträffar, och variera den mellan arbetsbelastningar i stället. För det andra stöder den här modellen effort per meddelande (beta-header mid-conversation-output-config-2026-07-01), som ändrar nivån från en senare tur utan att starta om promptcachen. Minimigränsen för promptcachen här är 512 tokens, ned från 1 024 i föregående generation, så prompter som tidigare var för korta för att cachelagras kan nu skapa poster utan kodändringar.

Maxgränser för utdata: 128K synkront, 300K i Batch

Det synkrona Messages API:et begränsar utdata till 128K tokens. Message Batches API:n går upp till 300K utdatatokens bakom betarubriken output-300k-2026-03-24 — exakt den strängen. Indata är som standard hela kontextfönstret på 1M tokens utan att någon rubrik krävs.

Den praktiska tolkningen: taket på 128K är oförändrat från Claude Opus 5, så inget med en synkron integration behöver ombudgeteras enbart på den axeln. Det som däremot behöver ombudgeteras är tänkandet i den. Eftersom max_tokens nu täcker tänkande plus text vid varje anrop, är ett värde som var lagom för svarstext på Claude Opus 5 tajtare här – och vid xhigh eller max effort föreslår leverantören att börja på 64k och finjustera. Om ett långkörande jobb dimensionerades mot det synkrona taket på 128K och nu trunkeras, är det inte taket som har flyttats.

Safeguard-routning är en del av specifikationen

Detta är ett integrationsfaktum, inte en policyfotnot: i vissa prompter beskriver modellsträngen du skickar inte vad som svarade.

Claude Opus 5.5 levereras med säkerhetsklassificerare, och en avböjd begäran kommer tillbaka som HTTP 200 med stop_reason: "refusal" och ett stop_details-objekt som anger policyområdet. Den här modellen täcker fler kategorier än Claude Opus 5 — förvänta dig bio, frontier_llm och reasoning_extraction tillsammans med de välbekanta cyber. reasoning_extraction-avböjandet blockeras helt i stället för att göras om: Anthropics server-side-fallback gör inget nytt försök med det, och avböjandet returneras till dig.

För de kategorier som gör nya försök är mekanismen en parameter. Ställ in fallbacks på "default" med server-side-fallback-2026-07-01 betarubriken, och API:et kör om en avvisad begäran på den modell som Anthropic rekommenderar för den kategorin, inom ett enda anrop, och returnerar ett svar. Anthropics hjälpcenter anger routningen för den här modellen direkt: flaggade cybersäkerhetsbegäranden faller tillbaka till Claude Opus 4.8, och dess biologiklassificerare – uppsättningen i Fable-5-stil – orsakar en återgång till Claude Opus 5 för livsvetenskapligt arbete med dubbla användningsområden. En snäv uppsättning avancerade LLM-utvecklingsfunktioner dirigeras också till Claude Opus 5. Anthropic noterar också att kontrollerna granskar allt modellen läser, inte bara ditt senaste meddelande, så minne, innehåll från anslutningar, sökresultat och filer kan utlösa en växling.

Tre saker följer av detta för din integration. Läs det översta model-fältet i varje svar, eftersom det rapporterar den modell som faktiskt producerade meddelandet, och ett fallback-innehållsblock markerar varje överlämningspunkt. Verifiera fallbackens egna hastighetsbegränsningar, eftersom en hastighetsbegränsad fallback inte försöks och avvisningen returneras i stället — fallbackar degraderar till avvisningar under belastning. Och behandla alla publicerade benchmarkkörningar med skyddsåtgärder aktiverade som en mätning av det routade systemet snarare än av Claude Opus 5.5 ensamt, vilket är exakt vad Anthropic säger om sina egna siffror nedan.

Reservlösningen på serversidan är i beta och endast för Claude API: den stöds inte i Message Batches API och är inte tillgänglig på Amazon Bedrock, Google Cloud eller Microsoft Foundry, där SDK-mellanvaran i stället är den dokumenterade vägen. På verifieringssidan finns åtkomstvägar för båda kategorierna – Cyber Verification Program och Life Sciences Verification Program – men notera den asymmetri som Anthropics hjälpcenter dokumenterar i skrivande stund: Claude Opus 5.5 finns för närvarande inte med i Cyber Verification Program, medan livsvetenskapsprogrammet beskrivs ge verifierade organisationer tillgång till de mest kapabla modellerna.

Kontext, brytpunkt, utfasning och snabbläge

Resten av kuvertet, från modellsidan och tabellen över utfasningar:

• Kontextfönster — 1M tokens, standard, ingen beta-header.

• Kunskapsgräns — juni 2026, vilket också är gränsen för träningsdata.

• Utfasning – tidigast 2027-09-22 på plattformar som drivs av Anthropic, med minst 60 dagars varsel. Amazon Bedrock och Google Cloud sätter sina egna datum. Claude Opus 5 är aktiv till åtminstone 2027-07-24, så det finns ingen tvingande övergång.

• Prislista — $4.00 per miljon indata, $20.00 per miljon utdata, $5.00 per miljon cacheskrivningar för 5 minuter, $8.00 per miljon cacheskrivningar för 1 timme, $0.20 per miljon cacheläsningar. Batch är halva priset i båda riktningarna vid $2.00 / $10.00.

• Cache-läsningar är avvikelsen värd att notera: 0,20 USD är 5 % av basindata, medan de flesta Claude-modeller ligger på 10 % och Claude Fable 5.1 på 2,5 %. Blandade arbetsbelastningar med hög cache-återanvändning upplever det som en verklig rabatt.

• Fast mode — fortfarande dokumenterat som en forskningsförhandsvisning, endast Claude API, prissätts separat till $8,00 för indata / $40,00 för utdata per miljon. Aktivera med speed: "fast" och den fast-mode-2026-02-01 beta-headern. Det är inte tillgängligt på Bedrock, Claude Platform on AWS, Google Cloud eller Microsoft Foundry, inte med Batch API, och inte med ett Priority Tier-åtagande. Observera att Claude Opus 5.5 inte stöder Priority Tier alls.

Vad benchmarkarna säger, och vid vilken inställning

Inställningar för ansträngning är orsaken till att en leverantörstabell och en oberoende tabell inte kan jämföras rad för rad, och till att varje siffra nedan anger sin inställning.

Leverantörsrapporterat, Anthropics eget testramverk. I Anthropics lanseringsnotis står det att om inget annat anges använder alla resultat för Claude Opus 5.5 adaptivt tänkande vid maximal ansträngning; undantaget är Terminal-Bench 4.0, som rapporteras vid xhigh för Claude Opus 5.5 och high för GPT-6 Astra, eftersom dessa är respektive modells högsta poäng. På den grunden rapporterar leverantören Terminal-Bench 4.0 till 66,4 %, FrontierCode v1.1 Main till 54,4 %, CursorBench 4.0 till 57,8 %, GDPval-AA v2.1 till 1 846 Elo, AutomationBench till 40,0 %, Humanity's Last Exam med verktyg till 67,7 %, Terminal-Bench-Science 0.1 till 58,7 %, OSWorld 2.0 till 81,8 % partiellt och Chartography med verktyg till 89,0 %. Vid modellens förvalda medelhöga ansträngningsnivå anger leverantören FrontierCode till 54,6 % och CursorBench till 52,5 %. Notera vad samma notis avslöjar: utvärderingarna kördes med produktionsskyddsåtgärder aktiverade, och när dessa utlöstes slutfördes cybersäkerhetsuppgifter av Claude Opus 4.8 och biologi- och frontier-LLM-utvecklingsuppgifter av Claude Opus 5 — Anthropic säger att detta sannolikt minskar Claude Opus 5.5:s prestanda på dessa benchmarkar. Publicerade poäng på de berörda utvärderingarna är därför inte rena mätningar av denna modell.

Oberoende, Artificial Analysis. På Intelligence Index v4.3.2 får Claude Opus 5.5 58 i konfigurationen som Artificial Analysis kallar "Adaptive Reasoning, Max Effort, Default Fallback" – dess högsta uppmätta poäng, flera poäng högre, och den toppar sex av de tio ingående utvärderingarna. På samma index och med samma testramverk får Claude Fable 5.1 53 och Claude Opus 5 51. Artificial Analysis publicerar hela ansträngningsstegen, som är den mest användbara oberoende artefakten här: max 58, xhigh 56, high 54, medium 51, low 42. Dess egna mätningar placerar Claude Opus 5.5 på ungefär 119 000 utdata-tokens per indexuppgift vid maximal ansträngning, mot cirka 73 000 för Claude Opus 5, 78 000 för Claude Fable 5.1 och 27 000 för GPT-6 Astra – tokens som faktureras som utdata-tokens – och dess sida rapporterar en kostnad på 5,98 USD per indexuppgift. Den mäter också Terminal-Bench 4.0 till 59,6 % och Humanity's Last Exam till 61,4 %, mot leverantörens 66,4 % och 67,7 % vid maximal ansträngning i ett annat testramverk.

Läs de två styckena mot varandra, och den ärliga slutsatsen är begränsad. Leverantörens 66,4 % på Terminal-Bench och den oberoende siffran 59,6 % är samma benchmark körda av olika personer med inställningar som inte garanterat matchar, och ingen av dem utgör bevis om din arbetsbelastning. Ansträngningsstegen är den överförbara slutsatsen: i ett oberoende index spänner den här modellens egna inställningar över sexton punkter, vilket är en bredare spridning än gapet mellan den och dess föregångare. Att välja en ansträngningsnivå har större betydelse än att välja mellan dessa modeller, och klausulen ”Default Fallback” i den beteckningen är den skyddsroutning som beskrivs ovan, inte en artefakt i benchmarken.

Leverantörsrapporterad effektivitet, med angiven källa. Anthropic säger att Claude Opus 5.5 presterar på Claude Fable 5.1:s nivå i de flesta arbetsuppgifter till cirka 40 % lägre driftskostnad, och att typiska arbetsbelastningar kostar ungefär 40 % mindre än med Claude Opus 5, trots en sänkning av listpriset med 20 %. Utdata går mer än 30 % snabbare. Detta är leverantörens beskrivningar av genomsnitt över arbetsbelastningar som leverantören har valt ut. Kunduttalandena vid lanseringen utgör samma typ av bevis: Box rapporterar en tredjedel av tokens och svar som är cirka 40 % mindre utförliga, Kiro ungefär hälften av tokens och omkring 40 % färre anrop, Factory 20–25 % färre utdatatokens, GitHub bland de lägsta antal tokens och steg som har uppmätts. Anthropic rapporterar också ett internt faktakontrolltest där 16 av dess 18 rapporter klarade en kvalitetsnivå som varken Claude Fable 5.1 eller Claude Opus 5 klarade i något enda försök. Allt är leverantörsrapporterat och inget av det är granskat. Den redovisade begränsningen är ovanligt uppriktig och värd att ta med sig: Anthropic säger att Claude Opus 5.5 "ofta misstänker att den blir utvärderad".

Till sist, syskonmodellerna: Anthropic säger att Claude Sonnet 5.5 och Claude Haiku 5.5 anländer "under de kommande veckorna". Ingen av dem har släppts, ingen av dem har ett pris, och ingen av dem finns på någon yta i dag.

Testar de fyra ändringarna utan en fullständig övergång

Migreringsrisken här är inte kvaliteten – det är att en kodväg som du aldrig körde i staging är den som returnerar 400 i produktion. De fyra brytande ändringarna är alla ändringar i förfrågans form, vilket innebär att de misslyckas deterministiskt och omedelbart, och det enda sättet att hitta de vägar du missat är att köra verklig trafik genom dem.

Claude Opus 5.5 finns på OrcaRouter som anthropic/claude-opus-5.5till Anthropics eget listpris med 0 % påslag – leverantörens listpris förs vidare, så en prisändring från leverantören slår igenom här samma dag.

Det låter dig rikta en procentandel av produktionstrafiken mot modellen medan resten fortfarande körs på Claude Opus 5, se vilka förfrågningar som misslyckas och varför, och åtgärda dem en i taget. De fyra felen beskriver sig själva: var och en anger namnet på parametern som avvisades och, i tre av de fyra fallen, ersättningen. Automatisk redundansväxling täcker luckan medan en väg fortfarande är trasig — en förfrågan som misslyckas mot en modell som du inte har karaktäriserat fullt ut faller tillbaka till en som du har, i stället för att exponera 400-felet för en användare.

En praktisk arbetsordning: byt modell-id och ställ in effort uttryckligen först, eftersom standarden har flyttats till medium; ta bort vägarna för thinking-disabled och forced-tool-choice därefter; åtgärda sedan streaming-läsaren – blockval efter typ och inställningen thinking.display – eftersom det är den som misslyckas tyst i stället för högljutt; och lämna migreringen av computer-use-verktygsuppsättningen till sist om du kör på Bedrock, eftersom det är den som inte gäller där. Allt annat – pris, kontextfönster, cache-priser och 1M-token-standarden – är redan där du lämnade det.

Dirigera en andel av den aktiva trafiken till den nya modellen utan en fullständig övergång: Claude Opus 5.5 på OrcaRouter körs till Anthropics listpris med automatisk failover till en modell som du redan har karakteriserat.