Pareto 26.10 vs Pareto 26.9: één getal scheidt deze twee releases

Het vergelijken van Pareto 26.10 met Pareto 26.9 is grotendeels een studie naar zaken die niet zijn veranderd. Dezelfde leverancier, dezelfde samengestelde architectuur, dezelfde maximale respons van 131,072 tokens, dezelfde vijf gedeclareerde parameters, dezelfde gepubliceerde tarieven op de prijspagina van de leverancier zelf, en — op de enige benchmark die beide releases gemeen hebben — een verschil van een tiende punt in het voordeel van het oudere model. Op de vlakken waarop men modellen gewoonlijk vergelijkt, zijn deze twee hetzelfde product met een ander versienummer. Op één vlak niet, en dat is juist het vlak dat bepaalt welke workloads überhaupt een van beide kunnen gebruiken: het contextvenster, waar 26.9 262,144 tokens biedt en 26.10 1,048,576. De gedocumenteerde AI-fouten en agent-incidenten achter releases als deze zijn verzameld in het OrcaRouter AI Incident Archive, waar elke vermelding haar eigen bronnen, ernstniveau, betrouwbaarheidsgraad en markering "betwist" bevat.

Beide zijn live. pareto-26.10 is de release die op 15 oktober 2026 de standaard achter de pareto alias werd, toen Unbiased zijn algemeen beschikbare release daarop overzette; pareto-26.9 is de septemberrelease waarvan de leverancier zegt dat die "beschikbaar blijft" voor iedereen die wil blijven. Dat is de hele beslissing waar een beller vandaag voor staat, en de rest van deze pagina bevat de details daarachter.

De omringende feiten

Beide modellen staan gedocumenteerd als modellen die tekst- en afbeeldingsinvoer accepteren en tekst retourneren, en geen van beide publiceert een Hugging Face-identifier — de gewichten zijn aan beide zijden van deze vergelijking gesloten, dus er is niets om te downloaden en zelf te hosten. Geen van beide heeft een onafhankelijke benchmark. Beide worden aangeboden door één enkele provider, Unbiased zelf, wat betekent dat er binnen de eigen stack van de leverancier voor geen van beide releases een tweede host is om op terug te vallen. De onderstaande vergelijking is daarom tussen twee configuraties van één productlijn van één leverancier, niet tussen twee ecosystemen.

Context is het hele argument.

Een 4× grotere context klinkt als een regel op een specificatieblad, tot je het naast de praktijk legt van wat mensen daadwerkelijk doen met modellen met een lange context.

Bij 262.144 tokens is een agent-sessie voor een volledige repository, een lang supporttranscript of een onderzoeksdraad van meerdere uren een chunkingprobleem. Je haalt op, je vat samen, je houdt een rollend venster bij, en je accepteert dat het model een reconstructie van de taak ziet in plaats van de taak. Bij 1.048.576 tokens passen die workloads — niet altijd comfortabel, en niet goedkoop tegen $0,80 per miljoen inputtokens zonder cache-hit, maar ze passen. Het praktische verschil tussen de twee releases is of je pipeline een retrievallayer tussen je data en het model nodig heeft.

Dat is een echte technische beslissing, en het is ook de enige op deze pagina met een verdedigbaar antwoord. Al het andere ligt zo dicht bij elkaar dat de keuze op iets anders dan kwaliteit gebaseerd zou moeten worden.

Zij aan zij, dimensie voor dimensie

• Modelstring — pareto-26.10 (standaard achter pareto sinds 2026-10-15) versus pareto-26.9 (behouden, niet standaard).

• Contextvenster — 1,048,576 tokens versus 262,144 tokens.

• Maximale respons — 131.072 tokens voor beide. Ongewijzigd tussen releases.

• Modaliteiten — tekst + afbeelding in, tekst uit, op beide.

• Gedeclareerde parameters — max_tokens, temperature, top_p, tools, tool_choice op 26.10; dezelfde set plus response_format op 26.9.

• Tool-aanroepen — tool_choice beperkt tot auto op 26.10; het model beslist of het aanroept, je kunt het niet forceren.

• Gewichten — beide gesloten; in geen van beide records een Hugging Face-identifier.

• Aanbiedende providers — één, de leverancier, op beide.

• Gepubliceerd tarief — $0,80 invoer / $0,03 gecachet / $3,20 uitvoer per miljoen voor beide, volgens de actuele prijspagina van de leverancier.

• DeepSWE v1.1 — 69,9% bij $0,24 per taak op 26.10 versus 70,0% bij $0,29 per taak op 26.9, beide door de leverancier uitgevoerd.

Twee van die rijen verdienen een eigen alinea, want dat zijn degenen die verkeerd worden gerapporteerd.

Het verschil in gestructureerde output waar niemand reclame voor maakt

De parameterlijsten zijn niet identiek. Het catalogusrecord voor 26.9 vermeldt response_format onder de ondersteunde parameters; het record voor 26.10 doet dat niet. Het voor 26.10 gedeclareerde oppervlak bestaat uit max_tokens, temperature, top_p, tools en tool_choice, en verder niets.

Lees dat aandachtig en niet als een krantenkop: het ontbreken van een parameter in een gedeclareerde lijst is geen bewijs dat het endpoint die parameter weigert, en de eigen API-documentatie van de leverancier somt geen van beide lijsten op. Maar als je pipeline afhankelijk is van JSON-modus of door een schema beperkte uitvoer, en je stapt over van 26.9 naar 26.10 in de veronderstelling dat de nieuwere release een strikte superset is, dan wordt die veronderstelling door niets gepubliceerds ondersteund. Test het met je eigen verkeer voordat je migreert, of plan om de uitvoer aan de clientzijde te valideren. Het is iets kleins dat op een dinsdag een incident wordt.

Twee actuele tariefkaarten zijn het oneens over wat 26,9 kost

Dit is het rommeligste onderdeel van de vergelijking en het onderdeel dat het meest waarschijnlijk van invloed is op een echte beslissing.

Unbiased publiceert één tarievenkaart — {{1}}$0,80 invoer{{/1}}, {{2}}$0,03 gecachte invoer{{/2}}, {{3}}$3,20 uitvoer{{/3}} — en versioneert die niet per release. Letterlijk gelezen betekent dit dat {{4}}26.10 en 26.9 vandaag hetzelfde per token kosten{{/4}}, waardoor {{5}}de migratie gratis is{{/5}} en {{6}}de contexttoename de enige variabele is{{/6}}. Ondertussen bevat {{7}}het eigen technische registratieoverzicht van het model nog steeds de septembercijfers voor 26.9{{/7}}: {{8}}$2,50 invoer{{/8}}, {{9}}$0,25 gecacht{{/9}}, {{10}}$7,50 uitvoer{{/10}}. {{11}}Beide bronnen waren live toen dit werd geschreven{{/11}}. {{12}}Geen van beide is gedateerd{{/12}}, en {{13}}de leverancier heeft geen changelogvermelding gepubliceerd die de wijziging verklaart{{/13}}, dus {{14}}er staat nergens in het record een citeerbare regel "op deze dag daalde de prijs"{{/14}}.

De praktische richtlijn is weinig glamoureus. Ga uit van de lagere kaart, omdat twee van de drie oppervlakken die je kunt lezen het publiceren en een ervan de pagina is op basis waarvan een klant wordt gefactureerd — controleer het dan opnieuw voordat je een bedrag in een budget vastlegt. Als je een van beide releases vastpint voor kostentoerekening, weet dan dat een gemengde maand die de overgang van 15 oktober overspant, achteraf niet netjes te splitsen zal zijn, omdat de releases op verschillende momenten anders geprijsd waren en de leverancier zijn wijzigingen niet dateert.

Eén score, één tiende van een punt, en niets om conclusies uit te trekken.

De enige benchmark die beide releases gemeen hebben, is DeepSWE v1.1, en de eigen cijfers van de leverancier zetten 26.9 op 70,0% en 26.10 op 69,9%. Beide cijfers zijn door de leverancier uitgevoerd, het oudere op een deelverzameling van 30 taken in plaats van de volledige evaluatieset, en de hele vergelijking wordt door Unbiased beschreven als niet onafhankelijk gevalideerd.

De eerlijke lezing is dat deze meting de releases niet van elkaar onderscheidt. Een tiende punt op een gedeeltelijke subset van taken valt binnen de ruis van één enkele run, en het in welke richting dan ook als een rangorde behandelen — "26.10 is achteruitgegaan", of "26.10 is beter omdat het per taak goedkoper is" — is koffiedik kijken. De cijfers voor kosten per taak lopen sterker uiteen ($0.24 tegenover $0.29), en zelfs die komen uit runs in verschillende maanden op een samengesteld model waarvan de leverancier de onderliggende samenstelling niet bekendmaakt.

Wat de sheet je wél vertelt, is waar je niet moet kijken. Als je op kwaliteit tussen deze twee kiest, kies je op basis van een getal dat die keuze niet kan onderbouwen. Het bewijs dat hen onderscheidt is architecturaal — het contextvenster en het parameteroppervlak — en beide zijn verifieerbaar op een manier waarop de scores dat niet zijn.

Welke je moet aanroepen, afhankelijk van de werkbelasting

• Agentic coding over een volledige repository — 26.10. Het 1M-venster is het verschil tussen de repository versturen en er een samenvatting van versturen.

• Analyse van lange documenten of lange transcripties — 26.10, om dezelfde reden, en let op de inputrekening: 1M tokens zonder cache-hit kost $0,80 per verzoek, alleen al aan input.

• JSON-modus- of schema-beperkte outputpijplijnen — 26.9 totdat je zelf het gedrag van 26.10 hebt getest, omdat de gedeclareerde parameterlijst van 26.9 response_format bevat en die van 26.10 niet.

• Een workload die al in productie is en binnen 262K past — 26.9. Er is geen gepubliceerd bewijs dat overstappen de output verbetert, en vastzetten is de goedkopere beslissing.

• Alles waarbij je de huidige standaard van de leverancier wilt zonder een pin te onderhouden — 26.10, via de kale pareto-alias, met de wetenschap dat de alias de kalender van de leverancier volgt in plaats van die van jou.

Voor teams die beide kanten van een build-and-verify-lus draaien, is het nuttige patroon om 26.10 vast te zetten voor de long-contextronde en 26.9 beschikbaar te houden als vergelijkingsarm — precies waarvoor een routeringslaag dient. OrcaRouter voert geen enkel Unbiased-model, dus beide strings worden via de eigen API van de leverancier aangeroepen; wat wij bieden is één sleutel en één integratie voor de modellen die je 26.10 tegen wilt benchmarken, zodat het evalueren van de overstap niet betekent dat je een tweede contract moet tekenen. OrcaRouter geeft de lijstprijs van de provider rechtstreeks door met 0% opslag, wat een uitspraak is over de modellen die we wél aanbieden, niet over dit model.

De migratie die niemand had gepland

De reden dat deze vergelijking actueel is in plaats van academisch, is dat de verandering al is gebeurd bij mensen die er niet om hadden gevraagd. Op 15 oktober verschoof de pareto-alias van de septemberrelease naar 26.10. Iedereen die de kale string aanriep, kreeg een verviervoudigd contextvenster en een ander parameteroppervlak zonder codewijziging — en omdat de documentatie van de leverancier vermeldt dat onbekende modelidentificaties niet worden geweigerd, wordt een verkeerd gespelde pin nog steeds geserveerd en gefactureerd als Pareto in plaats van luid te falen.

Als je in plaats daarvan op de preview-string zat, is die weg nu afgesloten: Unbiased heeft previewgebruikers laten weten dat ze moesten overstappen naar pareto of pareto-26.10. Als je op pareto zat en stabiliteit aannam, is die aanname nu zichtbaar in je eigen logs, of die nu wel of niet een probleem heeft veroorzaakt.

Hoe dan ook, de oplossing is dezelfde en kost één regel: noem de release die je hebt getest. Een string met versieaanduiding is wat een kostenmodel aftrekbaar maakt en een regressie toerekenbaar, en het is het enige mechanisme dat deze leverancier je voor beide biedt.

Wat is nog onbevestigd?

Geen van beide releases heeft een onafhankelijke benchmark. Artificial Analysis heeft voor geen van beide een pagina, en geen enkele evaluator heeft een nieuwe run van de harness van de leverancier gepubliceerd. Elk cijfer in deze vergelijking — de vier scores, de kosten-per-taakcijfers, de contextvensters — is ofwel door de leverancier gepubliceerd of afkomstig uit het technische registratiedossier van het model, en de scores dragen specifiek de eigen labels "voorlopig" en "niet onafhankelijk gevalideerd" van de leverancier.

Dat is geen reden om welk van beide modellen dan ook te vermijden. Het is een reden om te beslissen over de dingen die controleerbaar zijn: of je workload in 262K past, of je pipeline response_format nodig heeft, en of je op de alias of op een pin wilt zitten. Die drie vragen hebben een antwoord. Welk model beter is, heeft dat niet, en hoe vaak je de gepubliceerde sheet ook leest, er komt geen antwoord uit.