Claude Sonnet 5.5 vs Kimi K3: Ingen av modellerna kommer att ta din temperaturinställning

Här är en jämförelse där de två modellerna är överens om något som kommer att bryta din kod oavsett. Claude Sonnet 5.5, som släpptes den 28 september 2026, avvisar varje begäran som ställer in temperature, top_p eller top_k till ett icke-standardvärde med ett 400-fel. Kimi K3, allmänt tillgänglig från Moonshot AI sedan mitten av juli 2026, accepterar inga samplingsparametrar alls — ingen temperature, ingen top_p, inget seed — och exponerar resonemangsdjup endast genom en reasoning_effort-kontroll. Två olika labb, två olika arkitekturer, en gemensam slutsats: samplingsreglagen som de flesta integrationer fortfarande ställer in av vana är borta hos båda.

Det är inte den jämförelsen som någon skriver om. Jämförelsen som alla skriver om är priset: Kimi K3 till $3 per miljon indata-tokens och $15 utdata mot Claude Sonnet 5.5 till $2 och $10, vilket är en tydlig vinst för Anthropic på prislistan. Men Kimi K3 är en mixture-of-experts-modell med öppna vikter och 2,8 biljoner parametrar som du kan ladda ner och köra inom din egen gräns, och Claude Sonnet 5.5 är en sluten modell som finns på fyra moln. Mellan en billigare sluten modell och en dyrare nedladdningsbar sådan fattas beslutet inte alls utifrån priset per token.

Vad var och en av dem är, i ett stycke vardera

Claude Sonnet 5.5 är den andra modellen i Anthropics 5.5-generation och följde efter Claude Opus 5.5 till Claude API fem dagar efter den lanseringen. Den levereras som claude-sonnet-5-5 via Claude API, Amazon Bedrock, Google Cloud och Microsoft Foundry, behåller ett kontextfönster på 1 miljon tokens och ett synkront utdatatak på 128K samt har exakt samma prissättning som Claude Sonnet 5: 2 USD in, 10 USD ut, 0,20 USD per miljon för cacheläsningar. Adaptivt tänkande är aktiverat som standard vid high ansträngningsnivå. Den finns tillgänglig med noll datalagring, och Artificial Analysis ger den ett Intelligence Index på 56 i sin v4.3.2-revision – på tredje plats av de 216 modeller den mäter.

Kimi K3 är Moonshot AI:s flaggskepp: en mixture-of-experts-modell med 2,8 biljoner parametrar som aktiverar cirka 104 miljarder parametrar per token, med ett kontextfönster på 1 miljon token och inbyggd visuell förståelse. Den är byggd för kodning över långa tidshorisonter och kunskapsarbete i flera steg, och Moonshot positionerar den vid namn för programmeringsagent-ramverk. Den talar OpenAI API-formatet, exponerar reasoning_effort som sin enda styrning av resonemang, och har öppna vikter under Kimi K3-licensen – vilket inte är samma sak som öppen källkod, och skillnaden är det man bör läsa innan man bygger vidare på den.

Prislistan, och numret under den

Ställ de två mot varandra utifrån de dimensioner som avgör ett lagförslag snarare än en rubrik:

• Indatapris — Claude Sonnet 5.5 $2 per miljon mot Kimi K3 $3 per miljon

• Utdatapris — Claude Sonnet 5.5 $10 per miljon mot Kimi K3 $15 per miljon

• Cacheläsningar — 0,20 USD per miljon jämfört med 0,30 USD per miljon

• Kontextfönster — 1 000 000 tokens mot 1 048 576 tokens

• Vikter — proprietära, fyra värdbaserade plattformar vs öppna vikter under Kimi K3-licensen

• Intelligence Index — Claude Sonnet 5.5 56 vs Kimi K3 44 på samma v4.3.2-revision

• Kostnad per uppgift i Intelligence Index — Claude Sonnet 5.5 $7.60 vs Kimi K3 $2.00

• Mångordighet i indexet — Claude Sonnet 5.5 410M utdatatoken mot Kimi K3 160M

Det sista paret är den vändning som är värd att stanna upp vid. Anthropics modell är 50 % billigare på indata och en tredjedel billigare på utdata, och kostar ändå 3,8 gånger så mycket för att slutföra samma utvärdering, eftersom den gör av med 2,6 gånger så många tokens på vägen dit. På det sammansatta måttet får den också tolv poäng högre, så det här är inte ett fall där en slösaktig modell inte får något för pengarna. Det handlar om två modeller vars kostnadsbeteende inte går att jämföra genom att läsa två prislistor, vilket är anledningen till att siffran för indexuppgiften finns.

Ingen av de där tokenräkningarna kommer att vara din tokenräkning. Moonshots egen dokumentation påpekar att K3:s resonemangsdjup styrs av reasoning_effort snarare än av sampling, och i praktiken gäller samma sak för Sonnet 5.5:s effort-parameter — så på båda modellerna är den enskilt största hävstången på din faktura en effort-inställning, inte en prisförhandling.

400-felen, i detalj

Det gemensamma avvisandet av samplingsparametrar är den mest praktiska överlappningen här, eftersom det är det fel som visar sig morgonen efter ett modellbyte.

I Claude Sonnet 5.5 är reglerna uttryckliga och obevekliga. En icke-standardmässig temperature, top_p eller top_k returnerar 400. Att skicka thinking: {"type": "disabled"} returnerar 400 med hänvisning till between_tools, den nya lägsta tänkandeinställningen, som accepteras vid låg, medelhög och hög ansträngning men avvisas vid xhigh eller max. Påtvingad verktygsanvändning – tool_choice inställt på "any" eller på ett namngivet verktyg – returnerar 400 med meddelandet "tool_choice: type \"tool\" and \"any\" are not supported for this model", och lösningen är auto plus strikt verktygsanvändning eller strukturerade utdata. Och ännu mer: tankeblock är nu bundna till den modell och det konto som producerade dem, så en konversation kan flyttas från Claude Sonnet 5 till Sonnet 5.5 med sitt resonemang intakt, men kan inte föra det resonemanget vidare till en annan modellfamilj, och ett redigerat prefix kan göra att en återuppspelning returnerar 400.

På Kimi K3 är ytan mindre men konsekvenserna är likartade. Det finns inga samplingsparametrar att skicka, så varje klient som hårdkodar en skickar redan en parameter som modellen inte läser. Resoneringsdjupet är ett toppnivå-reasoning_effort-fält i stället.

Båda förändringarna pekar åt samma håll: metoden med deterministiska rattar för promptstyrning håller på att ersättas av ett effort-reglage på modellsidan. Varje pipeline som trimmade sig själv med temperatur 0,2 och ett fast slumpfrö måste trimmas om efter effort-nivå på båda dessa modeller, och omtrimningen är migreringen.

Vad öppna vikter faktiskt ger dig här

Anledningen att överväga Kimi K3 gentemot en billigare och högre poängvinnande sluten modell är varken kapacitet eller pris. Det är gränsen.

Att köra K3 i din egen infrastruktur innebär att promptar, dokument och utdata aldrig lämnar ett nätverk som du kontrollerar, vilket är en annan efterlevnadsdiskussion än ett avtal om noll datalagring med en leverantör. Det innebär också att modellen inte kan avvecklas under fötterna på dig – Claude Sonnet 5.5 levereras med ett Anthropic-åtagande om avveckling tidigast den 28 september 2027, och en nedladdad checkpoint har inget sådant datum. Och det innebär att marginalkostnadskurvan planas ut: efter hårdvara är tokens gratis, vilket är den enda strukturen där en modell med 2,8 biljoner parametrar någonsin blir det billiga alternativet.

Licensen är vad du faktiskt skriver under. Kimi K3 är en modell med öppna vikter, inte öppen källkod, och Moonshot använder inte det senare begreppet. Licensen för Kimi K3 är bred för de flesta användningsområden, men en verksamhet med modell-som-tjänst över en rullande intäktströskel behöver ett separat kommersiellt avtal, och produkter som överskrider stora trösklar för användare eller intäkter måste visa attributionen "Kimi K3". Att kalla den för MIT-licensierad är en felaktighet från K2-eran som fortfarande cirkulerar. Om du planerar att bygga på vikterna i stället för att anropa API:et, är detta en juridisk granskning snarare än en fotnot.

Och vikterna är tillräckligt stora för att självhosting ska vara ett kapitalbeslut. En MoE med 2,8 T parametrar och ungefär 104 B aktiva parametrar är inte en driftsättning på en enda server, och den ansträngning som krävs för att sätta upp den är den verkliga kostnaden för alternativet — en som överskuggar skillnaden på 5 USD per miljon i priser för utdata.

Var OrcaRouter passar

De flesta team som utvärderar dessa två vill inte välja mellan ett hanterat API och en hårdvaruanskaffning. De vill routa.

OrcaRouter är en OpenAI-kompatibel endpoint över 200+ modeller, med leverantörernas listpris vidarebefordrat utan påslag, så att en prisändring hos leverantören på endera sidan slår igenom samma dag i stället för vid nästa faktureringscykel. Kimi K3 har funnits i katalogen sedan juli till Moonshots eget $3 / $15, med en uppmätt p50-tid till första token på omkring åtta sekunder och ungefär 371,9 miljoner tokens som passerade genom den den senaste veckan. Claude Sonnet 5 – modellen som fortfarande driver merparten av Claude API-trafiken, med en uppmätt hastighet på 150 utdatatokens per sekund – har varit routbar sedan den 30 juni till Anthropics $2 / $10.

Claude Sonnet 5.5 finns ännu inte i vår katalog. Där det stämmer, säg det och routa runt det: leverantörens eget API är vägen dit, och sättet att testa den utan att binda dig är en procentandel av trafiken bakom automatisk failover, med Claude Sonnet 5 eller Kimi K3 som reserv. Om anledningen till att du tittar på K3 är gränsen snarare än priset, går vikterna att ladda ner i dag och API:et är en tillfällig lösning – vilket är ett beslut om din infrastruktur, inte om en modelljämförelse.

Omdömet, uppdelat efter vad du faktiskt köper

Välj Claude Sonnet 5.5 när arbetet har lång kontext och är utdatatungt, när tolv punkter i sammansatt index är det som köps, och när ett hanterat API med noll datalagring klarar din granskning. Räkna med token-vanan — 410M tokens på Index mot K3:s 160M är en verklig multiplikator — och avsätt en dag för ändringarna i verktygsanvändning och tänkblock.

Välj Kimi K3 när gränsen är kravet, när du vill ha en checkpoint som ingen leverantör kan avveckla, eller när din arbetsbelastning är agentisk kodning i hög volym där $2.00 per indexuppgift mot $7.60 ackumuleras. Acceptera att det är en modell med 2,8 biljoner parametrar att hosta, att dess licens har attributions- och intäktsklausuler, och att den får lägre poäng än Anthropic-nivån på kompositen.

Det som ingen av valen kommer undan är första stycket: samplingsparametrarna är borta i båda, och effort-ratten är den kontroll som ersatte dem. Vilket av dessa två du än väljer, är det den ändring din kod behöver.