Claude Opus 5.5 sänker tokenpriset – tänkandet går inte att stänga av

Anthropic lanserade Claude Opus 5.5 den 22 september 2026. API-priset är 4 dollar per miljon inmatade token och 20 dollar per miljon utmatade token, jämfört med 5 respektive 25 dollar för Opus 5. Det är en sänkning av styckpriset med 20 procent i båda kategorierna.

Den billigare modellen ändrar samtidigt villkoren för den som använder API:et. Enligt Anthropics migrationsanvisning är adaptivt tänkande alltid aktivt, kontextfönstret är en miljon token och standardnivån för hur mycket modellen arbetar är medium. Tänkandet faktureras som utmatade token även när texten inte visas. Modellen finns via Claude API, Amazon Bedrock, Claude Platform on AWS, Google Cloud och Microsoft Foundry, men ett lägre pris per token garanterar därför inte en lika stor besparing per uppgift.

Priset per token och priset per färdig uppgift

Anthropics lanseringsuppgifter skiljer mellan den direkta prissänkningen och bolagets tester av hela arbetslaster. I dem anges 40 procent lägre typisk kostnad vid standardinställningar och drygt 30 procent snabbare utmatning än med Opus 5. Kiros Deepak Singh beskriver varför båda måtten spelar roll för utvecklare: ”Every call an agent makes is time and cost a developer feels.”

Skillnaden mellan 20 och 40 procent beror på vad som mäts. Det första talet gäller priset för samma mängd vanliga in- och utmatade token; det andra är ett leverantörsresultat där modellen också använder färre token för att slutföra uppgifter. Cacheläsningar har en egen taxa som sjunkit från 0,50 till 0,20 dollar per miljon token. Den rabatten kan få särskild betydelse i kodagenter som återanvänder stora delar av tidigare kontext, men förutsätter att innehållet faktiskt läses ur cache.

Ett villkorat månads­exempel visar gränsen för den enkla prisjämförelsen. Om ett svenskt utvecklingsteam använder 50 miljoner vanliga inmatade token och 10 miljoner utmatade token kostar mängden 400 dollar med Opus 5.5: 200 dollar för vardera kategorin. Med Opus 5:s tidigare taxor blir summan 500 dollar. Beräkningen håller tokenmängderna oförändrade och tar inte med cache, andra prislägen eller en eventuell förändring i hur många token modellen använder. Den beskriver alltså ingen faktisk kundfaktura.

En kodagent med många anrop kan få ett annat utfall än exemplet även om det synliga slutsvaret är lika långt. Verktygsanrop, återanvänd kontext och varierande mängd tänkande ändrar antalet fakturerade token under körningen. För ett svenskt team är dollarbeloppen också den stabila jämförelsen mellan API-taxorna; ett belopp i kronor skulle dessutom bero på växelkursen vid fakturering.

Alltid aktivt tänkande ändrar API-beteendet

Det obligatoriska tänkandet är en teknisk skillnad mot Opus 5, som kunde ta emot en begäran om att stänga av funktionen. Med Opus 5.5 avvisas både den inställningen och en manuellt angiven tokenbudget för tänkande. Parametern effort kan sänkas för att påverka hur mycket modellen arbetar, men den stänger inte av tänkandet och anger inte ett exakt antal fakturerade token.

Utmatningstaket max_tokens omfattar både tänkandet och svarets vanliga text. Ett tak som räckte för ett tidigare arbetsflöde utan tänkande kan därför lämna mindre utrymme för det färdiga svaret efter ett modellbyte. Även programmets hantering av svaret påverkas: ett svar kan börja med ett tänkandeblock i stället för läsbar text. Som standard utelämnas själva tanketexten, trots att blocket och dess signatur finns i svaret.

För verktygsbaserade program behöver sådana block följa med oförändrade när verktygsresultat skickas tillbaka till API:et. Om programmet tar bort, redigerar eller byter ordning på dem avvisas begäran. Opus 5.5 avvisar också verktygsval som tvingar fram ett visst verktyg eller kräver att något verktyg används; automatiskt verktygsval är den stödda vägen. Det är konkreta integrationsändringar för kod som byggts kring Opus 5:s svar och inställningar.

Prestandasiffrorna beror på testläget

De publicerade resultaten pekar på bättre kapacitet för agentbaserad programmering, men testvillkoren är viktiga för jämförelsen med den lägre taxan. Flera benchmarkresultat för Opus 5.5 är uppmätta med högre effort än standardnivån medium. En arbetslast som körs på standardnivå får därför inte automatiskt samma resultat som modellens högsta redovisade testpoäng.

Vissa säkerhetsåtgärder påverkar dessutom vilken modell som faktiskt slutför en testuppgift. När skyddet ingrep i de redovisade testerna slutfördes uppgifter inom cybersäkerhet av Claude Opus 4.8 och uppgifter inom biologi eller avancerad modellutveckling av Claude Opus 5. Resultat från den konfigurationen beskriver ett skyddat system, inte enbart Opus 5.5 utan ingripanden. Leverantörens uppgifter om hastighet, tokenåtgång och kvalitet bör läsas med samma avgränsning.

Den lägre taxan får störst effekt när hela körningen blir billigare

Det stora kontextfönstret och det lägre priset för cacheläsningar gör modellen relevant för långa arbetsflöden som återanvänder kod och tidigare instruktioner. Där kan färre anrop eller färre förbrukade token förstärka sänkningen av styckpriset. För korta uppgifter som tidigare kördes utan tänkande kan den obligatoriska extra utmatningen i stället äta upp en del av besparingen.

Den avgörande skillnaden för ett utvecklingsteam syns därför på kostnaden för en färdig uppgift: hur många anrop som krävs, hur mycket kontext som hämtas ur cache, hur många utmatade token som faktureras och om resultatet håller. Ett lägre listpris är redan fastställt; utfallet för teamets egna arbetslaster beror på hur modellen arbetar med just deras kod och valda effort-nivå.