Claude Sonnet 5.5 släpptes den 28 september 2026 som en snabbare modell för avgränsade uppgifter, kodändringar och dokumentarbete. Den finns enligt Anthropic på Claude API och flera molnplattformar. GitHub har samtidigt börjat rulla ut modellen i Copilot. Den tekniskt viktigaste nyheten för befintliga integrationer är att ett byte av modellnamn inte alltid räcker: flera tidigare giltiga API-inställningar ger nu fel, och anrop utan ett uttryckligt tänkandeläge får ett annat beteende.
Anthropic beskriver en betydligt effektivare modell än Sonnet 5, men företagets egna benchmarkresultat bör inte användas som ett löfte för varje kodbas eller agentflöde. En pilot behöver mäta rätt saker: uppgiftsresultat, svarstid, faktiska token, verktygsanrop och hur ofta skyddsmekanismer påverkar arbetet.
Tillgänglig nu, men utrullningen skiljer sig
Anthropics modellöversikt anger Claude Sonnet 5.5 som aktiv sedan den 28 september. Modellidentifieraren på Claude API är claude-sonnet-5-5. Dokumentationen listar också Amazon Bedrock, Google Cloud, Microsoft Foundry och Claude Platform on AWS. Amazon har publicerat ett eget modellkort och ett exempel med plattformens identifierare global.anthropic.claude-sonnet-5-5. Den som kör via en molnplattform behöver alltså kontrollera dess egna namn, regioner, kvoter och fakturering i stället för att anta att API-anropen är identiska.
GitHub anger allmän tillgänglighet i Copilot för Pro, Pro+, Max, Business och Enterprise, bland annat i VS Code, Visual Studio, Copilot CLI, kodagenten och GitHubs webbgränssnitt. Samtidigt skriver GitHub att utrullningen sker gradvis. Administratörer för Business och Enterprise kan styra tillgången genom modellpolicy. En användare som ännu inte ser modellen i väljaren ska därför inte tolka det som ett generellt tillgänglighetsfel.
Det här ger två praktiska införandespår. Copilot-team kan prova modellen i utvalda koduppgifter när den syns i deras klient och kontrollera policy och förbrukning. API-team behöver göra en versionsstyrd migrering där anrop och svar parsas om mot den nya modellen. Dessa spår har olika kontrollpunkter och bör testas var för sig.
Prestanda och kostnad måste mätas per uppgift
Anthropic uppger att Sonnet 5.5 genererar utdata mer än 30 procent snabbare än Sonnet 5 och kan kosta upp till 30 procent mindre per uppgift i deras tester. Listpriset är däremot oförändrat jämfört med Sonnet 5: 2 dollar per miljon inmatningstoken, 10 dollar per miljon utmatningstoken och 0,20 dollar per miljon token vid cacheläsning. En lägre uppgiftskostnad skulle alltså komma av färre token eller färre steg, inte av ett lägre ordinarie tokenpris.
Leverantören redovisar 70,6 procent på Terminal-Bench 4.0 mot 10,3 procent för Sonnet 5. Den mycket stora skillnaden bör läsas tillsammans med metoduppgifterna i systemkortet och inställningarna för testmiljön. Anthropic redovisar även separata resultat för andra tester och ansträngningsnivåer. Att blanda tal från Terminal-Bench, FrontierCode och interna kundtester till en enda rangordning vore missvisande. Vi har inte gjort en oberoende jämförelse.
För en driftbar agent är den relevanta kostnaden ofta pris per godkänd uppgift. Välj ett representativt paket med exempelvis felrättningar, kodgranskningar och dokumentändringar. Lås verktyg, prompt, data och utvärderingskriterier; kör sedan Sonnet 5 och 5.5 med redovisade effort-inställningar. Mät antal lyckade uppgifter, omarbete, total väntetid, tokenförbrukning och antal verktygsanrop. Samma standardpris kan ge olika total kostnad när modellens arbetssätt ändras.
API-migreringen innehåller brytande ändringar
Anthropics migreringsguide säger uttryckligen att kod mot Messages API behöver granskas. Adaptive thinking är standard i Sonnet 5.5 när thinking utelämnas. För äldre Sonnet-modeller kunde motsvarande anrop köras utan tänkande. Ett program som antar att första svarsblocket alltid är text kan därför fallera. Svarsblock ska läsas efter type, och tänkandeblock i ett verktygsflöde måste skickas tillbaka oförändrade. max_tokens omfattar dessutom både tänkande och text, vilket kan påverka budget och avbrutna svar.
Den som tidigare skickade thinking: {"type": "disabled"} för Sonnet 5 behöver använda between_tools för att undvika tänkande före ett verktygsanrop. between_tools är begränsat till effort-nivåerna low, medium och high. Kombinationen med xhigh eller max ger ett 400-fel. Anthropic rekommenderar att effort-nivåerna kalibreras på nytt per arbetslast; samma etikett innebär inte nödvändigtvis samma tokenförbrukning eller kvalitet som för föregångaren.
Tvingat verktygsval med tool_choice satt till any eller ett specifikt tool stöds inte och ger också 400-fel. Ersätt det med auto, använd vid behov strikta verktygsscheman där plattformen stöder dem och validera att modellen faktiskt anropade rätt verktyg. På Bedrock finns enligt guiden inte samma stöd för strict tool use för denna modell. En applikation som kräver ett obligatoriskt verktygsanrop måste därför ha en egen kontroll och felväg.
Migreringsguiden listar ytterligare fallgropar för äldre installationer: icke-standardvärden för temperature, top_p och top_k, gamla tänkandebudgetar och assistant-prefill kan ge fel. Datoranvändning kräver rätt verktygsversion för respektive plattform. Det är klokt att söka efter dessa parametrar i kodbasen innan modell-ID byts i produktion.
Säkerhetsfilter påverkar agentens drift
Sonnet 5.5 är den första Sonnet-modell som Anthropic säger sig lansera med ett cyberskydd av den typ företaget använder för sina mest kapabla modeller. Vissa högriskförfrågningar kan nekas. På Claude API kan en särskild serverstyrd fallback för vissa kategorier försöka igen med Sonnet 5; den gäller inte alla typer av avslag. Ett säkerhets- eller driftteam behöver därför hantera stop_reason: "refusal", förstå när en fallback kan ske och logga vilken modell som faktiskt svarade.
Anthropic beskriver även signerade tänkandeblock knutna till samtalshistoriken. För berörda konton kan redigering av tidigare historik innan ett sådant block spelas upp ge 400-fel. Behåll konversationer append-only och testa återupptagning, kontobyte och verktygsloopar. Detta är särskilt viktigt för agenter som lagrar mellanläge över långa jobb.
Skyddsbeskrivningen är leverantörens egen. Den visar inte att en agentmiljö är säker i sig. Behörigheter, isolering, verktygsgränser och mänskligt godkännande för skrivande åtgärder behöver fortsatt kontrolleras i det system som använder modellen.
LabOps IT:s bedömning
Sonnet 5.5 är värd att testa för kod- och kunskapsuppgifter där snabb återkoppling och kostnad per färdig uppgift betyder mer än maximal modellkapacitet. Det är en egen lansering med tydlig integrationspåverkan, skild från den tidigare publicerade Opus 5.5-nyheten. För den som redan kör Sonnet är den viktigaste första åtgärden en inventering av API-parametrar och svarshantering, följd av en liten jämförbar pilot.
Prioritera att få bort anrop som ger 400-fel, verifiera verktygsflöden och refusals, och mät sedan kvalitet, kostnad och svarstid mot den nuvarande modellen. Behåll en fungerande återgångsväg under utrullningen. För Copilot-team är motsvarande första steg att kontrollera organisationens modellpolicy och sedan prova modellen på representativa uppgifter när den blir synlig i klienten.