Pareto 26.10 vs Pareto 26.9: Ett nummer skiljer dessa två versioner åt

Att jämföra Pareto 26.10 med Pareto 26.9 är mestadels en studie i saker som inte förändrades. Samma leverantör, samma sammansatta arkitektur, samma maximala svar på 131 072 token, samma fem deklarerade parametrar, samma publicerade priser på leverantörens egen prissida och – i det enda benchmark som båda utgåvorna delar – en skillnad på en tiondels poäng till den äldre modellens fördel. På de ytor där man vanligtvis jämför modeller är dessa två samma produkt med olika versionsnummer. På en yta är de inte det, och det är den ytan som avgör vilka arbetsbelastningar som över huvud taget kan använda någon av dem: kontextfönster, där 26.9 erbjuder 262 144 token och 26.10 erbjuder 1 048 576. De dokumenterade AI-felen och agentincidenterna bakom utgåvor som denna samlas i OrcaRouter AI Incident Archive där varje post har sina egna källor, allvarlighetsgrad, konfidensgrad och omtvistad flagga.

Båda är live. pareto-26.10 är den version som blev standard bakom aliaset pareto den 15 oktober 2026, när Unbiased flyttade sin allmänt tillgängliga version till den; pareto-26.9 är septemberversionen som leverantören säger "fortfarande är tillgänglig" för alla som vill stanna kvar. Det är hela beslutet som en uppringare står inför i dag, och resten av den här sidan är detaljerna bakom det.

De omgivande fakta

Båda modellerna dokumenteras som att de tar emot text- och bildindata och returnerar text, och ingen av dem publicerar en Hugging Face-identifierare – vikterna är stängda på båda sidor av denna jämförelse, så det finns inget att ladda ned och självhosta. Ingen av dem har ett oberoende benchmark. Båda tillhandahålls av en enda leverantör, Unbiased självt, vilket innebär att det inte finns någon andra värd att redundansväxla till inom leverantörens egen stack för någon av utgåvorna. Jämförelsen nedan är därför mellan två konfigurationer av en leverantörs enda produktlinje, inte mellan två ekosystem.

Kontexten är hela argumentet.

En kontextökning på 4× låter som en rad på ett specifikationsblad tills man kopplar det till vad folk faktiskt gör med långkontextmodeller.

Vid 262 144 token är en agentsession för ett helt kodarkiv, en lång supporttranskription eller en forskningstråd som pågår i flera timmar ett chunkningsproblem. Du hämtar, sammanfattar, håller ett rullande fönster och accepterar att modellen ser en rekonstruktion av uppgiften i stället för uppgiften. Vid 1 048 576 token ryms dessa arbetsbelastningar – inte alltid bekvämt, och inte billigt med $0,80 per miljon indatatoken utan cacheträff, men de ryms. Den praktiska skillnaden mellan de två utgåvorna är huruvida din pipeline behöver ett hämtningslager mellan dina data och modellen.

Det är ett riktigt ingenjörsmässigt beslut, och det är också det enda på den här sidan som har ett försvarbart svar. Allt annat är så pass jämnt att valet bör göras utifrån något annat än kvalitet.

Sida vid sida, dimension för dimension

• Modellsträng — pareto-26.10 (standard bakom pareto sedan 2026-10-15) vs pareto-26.9 (behållen, inte standard).

• Kontextfönster — 1 048 576 tokens vs 262 144 tokens.

• Maximalt svar — 131 072 token på båda. Oförändrat mellan versionerna.

• Modaliteter — text + bild in, text ut, på båda.

• Deklarerade parametrar – max_tokens, temperature, top_p, tools, tool_choice i 26.10; samma uppsättning plus response_format i 26.9.

• Verktygsanrop – tool_choice begränsat till auto på 26.10; modellen avgör om den ska anropa, du kan inte tvinga den.

• Vikter – stängda för båda; ingen Hugging Face-identifierare i någon av posterna.

• Tillhandahållande leverantörer — en, säljaren, på båda.

• Publicerat pris — $0,80 för indata / $0,03 för cachade / $3,20 för utdata per miljon på båda, enligt leverantörens aktuella prissida.

• DeepSWE v1.1 — 69,9 % till $0,24 per uppgift på 26.10 jämfört med 70,0 % till $0,29 per uppgift på 26.9, båda körda av leverantören.

Två av de där raderna förtjänar ett eget stycke, eftersom det är just de som rapporteras fel.

Skillnaden med strukturerad utdata som ingen gör reklam för

Parameterlistorna är inte identiska. Katalogposten för {{1}}26.9{{/1}} anger {{2}}response_format{{/2}} bland sina parametrar som stöds; posten för {{3}}26.10{{/3}} gör det inte. Den deklarerade ytan för {{4}}26.10{{/4}} är {{5}}max_tokens{{/5}}, {{6}}temperature{{/6}}, {{7}}top_p{{/7}}, {{8}}tools{{/8}} och {{9}}tool_choice{{/9}}, punkt.

Läs det noggrant i stället för som en rubrik: att en parameter saknas i en deklarerad lista är inte bevis för att slutpunkten avvisar den, och leverantörens egen API-dokumentation räknar inte upp någon av listorna. Men om din pipeline är beroende av JSON-läge eller schemabegränsad utdata, och du går från 26.9 till 26.10 med antagandet att den nyare versionen är en strikt supermängd, så stöds inte det antagandet av något som publicerats. Testa det på din egen trafik innan du migrerar, eller planera att validera utdata på klientsidan. Det är en liten sak som blir en incident på en tisdag.

Två aktuella priskort är oense om vad 26.9 kostar

Det här är den rörigaste delen av jämförelsen och den del som med störst sannolikhet påverkar ett verkligt beslut.

Unbiased publicerar ett enda priskort – 0,80 USD för indata, 0,03 USD för cachad indata, 3,20 USD för utdata – och versionshanterar det inte per release. Litterärt läst innebär det att 26.10 och 26.9 kostar lika mycket per token i dag, vilket gör migreringen gratis och kontextökningen till den enda variabeln. Samtidigt bär modellens egen tekniska förteckningspost fortfarande septemberiffrorna för 26.9: 2,50 USD för indata, 0,25 USD cachat, 7,50 USD för utdata. Båda källorna var live när detta skrevs. Ingen av dem är daterad, och leverantören har inte publicerat någon changelog-post som förklarar ändringen, så det finns ingen citerbar rad någonstans i underlaget om att "den här dagen sjönk priset".

Den praktiska vägledningen är oglamorös. Anta det lägre kortet, eftersom två av de tre ytor du kan läsa publicerar den och en av dem är den sida en kund faktureras mot – dubbelkolla det sedan innan du låser dig vid en siffra i en budget. Om du låser någon av utgåvorna för kostnadsallokering, tänk på att en blandad månad som sträcker sig över övergången den 15 oktober inte går att dela upp rent i efterhand, eftersom utgåvorna prissattes olika vid olika tidpunkter och leverantören inte daterar sina ändringar.

Ett mål, en tiondels poäng och ingenting att dra några slutsatser av.

Den enda benchmark som båda utgåvorna har gemensamt är DeepSWE v1.1, och leverantörens egna siffror anger 26.9 till 70,0 % och 26.10 till 69,9 %. Båda siffrorna är körda av leverantören, den äldre på en delmängd om 30 uppgifter i stället för hela utvärderingsuppsättningen, och hela jämförelsen beskrivs av Unbiased som inte oberoende validerad.

En ärlig tolkning är att den här mätningen inte skiljer utgåvorna åt. En tiondels poäng på en partiell uppgiftsdel ligger inom bruset för en enda körning, och att behandla det som en rangordning åt något håll – "26.10 har försämrats" eller "26.10 är bättre eftersom det är billigare per uppgift" – är att läsa teblad. Siffrorna för kostnad per uppgift skiljer sig mer ($0.24 mot $0.29), och även de kommer från körningar under olika månader på en blandad modell vars underliggande sammansättning leverantören inte redovisar.

Det tabellen faktiskt säger dig är var du inte ska titta. Om du väljer mellan dessa två utifrån kvalitet väljer du utifrån en siffra som inte kan bära valet. Bevisen som skiljer dem åt är arkitektoniska – kontextfönstret och parameterytan – och båda är verifierbara på ett sätt som poängen inte är.

Vilken som ska anropas, beroende på arbetsbelastning

• Agentisk kodning över ett helt kodförråd — 26.10. Fönstret på 1M är skillnaden mellan att skicka kodförrådet och att skicka en sammanfattning av det.

• Analys av långa dokument eller långa transkript — 26.10, av samma skäl, och håll koll på indatakostnaden: 1M tokens utan cacheträff kostar $0.80 per begäran bara i indata.

• JSON-läge eller schemabegränsade utdatapipelines – 26.9 tills du själv har testat 26.10:s beteende, eftersom 26.9:s deklarerade parameterlista innehåller response_format och 26.10:s inte gör det.

• En arbetsbelastning som redan är i produktion och ryms inom 262K – 26.9. Det finns inga publicerade bevis för att flytt förbättrar utdata, och att låsa är det billigare beslutet.

• Allt där du vill ha leverantörens nuvarande standard utan att underhålla en pin – 26.10, via det rena pareto-aliaset, med förståelsen att aliaset följer leverantörens kalender snarare än din.

För team som kör båda sidorna av en bygg-och-verifiera-loop är det användbara mönstret att låsa 26.10 för long-context-passet och hålla 26.9 tillgängligt som jämförelsearm — vilket är precis vad ett routningslager är till för. OrcaRouter har ingen Unbiased-modell, så båda strängarna anropas via leverantörens egen API; det vi tillhandahåller är en nyckel och en integration för de modeller du skulle benchmarka 26.10 mot, så att utvärdera bytet inte innebär att teckna ett andra avtal. OrcaRouter för vidare leverantörens listpris direkt med 0 % påslag, vilket är ett uttalande om de modeller vi faktiskt tillhandahåller, inte om den här.

Migrationen som ingen hade planerat

Anledningen till att den här jämförelsen är levande snarare än akademisk är att förändringen redan har drabbat människor som inte bad om den. Den 15 oktober flyttades pareto-aliaset från septemberversionen till 26.10. Alla som anropade den nakna strängen fick ett fyrdubblat kontextfönster och en annan parameteryta utan någon kodändring – och eftersom leverantörens dokumentation påpekar att okända modellidentifierare inte avvisas, betjänas och faktureras en felstavad pin fortfarande som Pareto i stället för att misslyckas högljutt.

Om du i stället var på preview-strängen är den vägen stängd: Unbiased sade åt preview-användare att flytta till pareto eller pareto-26.10. Om du var på pareto och antog att det var stabilt, är antagandet nu synligt i dina egna loggar, oavsett om det orsakade ett problem eller inte.

Hur som helst är fixen densamma och tar en rad: namnge den version du testade. En versionskvalificerad sträng är det som gör en kostnadsmodell subtraherbar och en regression tillskrivbar, och det är den enda mekanismen den här leverantören ger dig för något av dem.

Vad är fortfarande overifierat

Ingen av versionerna har ett oberoende benchmark. Artificial Analysis har ingen sida för någon av dem, och ingen utvärderare har publicerat en ny körning av leverantörens testramverk. Varje siffra i den här jämförelsen – de fyra poängen, siffrorna för kostnad per uppgift, kontextfönstren – är antingen publicerad av leverantören eller hämtad från modellens tekniska listningspost, och poängen är särskilt försedda med leverantörens egna etiketter "preliminär" och "inte oberoende validerad".

Det är inte ett skäl att undvika någon av modellerna. Det är ett skäl att bestämma sig för det som går att kontrollera: om din arbetsbelastning passar inom 262K, om din pipeline behöver response_format och om du vill ligga på aliaset eller på en fast pinnad version. De tre frågorna har svar. Vilken modell som är bättre har inte det, och hur mycket man än läser det publicerade databladet kommer man inte att få ett.