Pareto 26.10 Preview vs Pareto: dezelfde modelstring, twee verschillende modellen

Unbiased bracht Pareto 26.10 Preview op 1 oktober 2026 uit en liet de vorige release, Pareto, ernaast vermeld. De twee zijn geen varianten van een familie waar je met een flag tussen kiest. Het zijn twee releases achter één merk, en de modelstring van de leverancier zelf — pareto — verwijst nu naar de nieuwere, expliciet onstabiele versie. De vergelijkingsvraag is dus niet echt "welke is beter." Het is: welke van de twee bereikt je request daadwerkelijk, en wat gebeurt er met het antwoord wanneer dat onder je verandert?

De enige plek waar de twee in één adem worden genoemd, is de openbare technische specificatie van het model. De eigen modelkaart, prijzenpagina en FAQ van Unbiased beschrijven één gestapeld product en noemen de splitsing nooit. Die asymmetrie — een gedetailleerde openbare diff aan de ene kant, stilte aan de andere — is het eerlijke uitgangspunt voor een head-to-head, want die vertelt je waar elk getal hieronder vandaan komt.

Zes dimensies, twee zijden

Alles wat de releases van elkaar scheidt, zit in deze zes regels. De linkerkant is Pareto 26.10 Preview; de rechterkant is de Pareto-release van 17 september, degene die de catalogustekst van de preview de stabiele keuze noemt.

• Contextvenster — 1.048.576 tokens tegenover 262.144 tokens. Op papier vier keer zoveel ruimte, terwijl geen van beide een kleinere variant biedt.
• Maximale output — 131.072 tokens tegenover 131.072 tokens. Ongewijzigd. Het grotere venster ging niet gepaard met een groter antwoord.
• Invoerprijs, zoals gerouteerd — $0,80 per miljoen tegenover $2,50 per miljoen. De preview is op die vermelding ongeveer een derde van de prijs.
• Uitvoerprijs, zoals gerouteerd — $3,20 per miljoen tegenover $7,50 per miljoen. Minder dan de helft.
• Gecachte invoer, zoals gerouteerd — $0,03 per miljoen tegenover $0,25 per miljoen. De langste agenttrajecten profiteren hier het meest.
• Gepubliceerde benchmarktabel — vier scores, expliciet "voorlopig" en "kan veranderen vóór definitieve publicatie" tegenover helemaal geen gepubliceerde benchmarktabel.

Twee van die rijen zijn de rijen die het echte werk bepalen. Het contextvenster is het belangrijkste cijfer dat de leverancier niet op zijn eigen site zal vermelden — het staat op de listing, niet op de modelkaart — en de prijs voor gecachte input is degene die de rekening van een agent verandert, niet zijn plafond. Al het overige is ofwel een marketingdelta of, in het geval van de outputscore, een bekentenis: het publiceren van de cijfers van een preview met het label "voorlopig" is eerlijker dan het alternatief, en het is ook een waarschuwing.

De prijs die je ziet, hangt af van waar je kijkt.

Zet de twee tariefkaarten naast elkaar en ze komen niet overeen, en dat is precies het deel van deze vergelijking dat niemand heeft uitgelegd.

Het eigen platform van Unbiased vermeldt op de dag dat 26.10 Preview de huidige release werd, nog steeds $2,50 per miljoen input, $0,25 gecachet en $7,50 output. Dat zijn de septembercijfers, ongewijzigd, zowel op de prijspagina als op de modelkaart. De lagere set — $0,80, $0,03, $3,20 — staat in de gerouteerde catalogusvermelding voor dezelfde preview. Dus een klant die pareto rechtstreeks via de API van de leverancier aanroept, betaalt volgens de oude tariefkaart voor het nieuwe model, terwijl de gerouteerde vermelding met ongeveer een derde daarvan adverteert. Beide zijn live. De leverancier heeft geen einddatum van de promotie gepubliceerd en geen verklaring die de twee met elkaar verzoent.

Dat is een kanaalkwestie, en bij een previewrelease is het ook een timingkwestie: op welk getal je je kosten ook baseert, het andere is één releasenote verwijderd van kloppend zijn. Een router die de lijstprijs van een provider met 0% opslag doorgeeft, haalt precies deze frictie weg — een prijswijziging van de leverancier is dezelfde dag live in plaats van bij de volgende contractbespreking — en dat is het ene structurele ding dat het waard is om hier van OrcaRouter te lenen. We voeren vandaag geen van beide Unbiased-releases, dus het directe antwoord op 'waar roep ik het aan' is de eigen API van Unbiased, op welke van de twee prijssets de listing waarlangs je koopt ook maar heeft. De reden om het hardop te zeggen is dat het verschil een factor drie is, en een preview is niet de plek om erachter te komen dat je de verkeerde hebt geprijsd.

Wat de preview je oplevert, en wat het je kost

De eigen catalogusbeschrijving van de preview bepaalt de voorwaarden: de preview "kan zonder voorafgaande kennisgeving worden gewijzigd", en wie voorspelbaar gedrag nodig heeft, wordt terugverwezen naar de septemberrelease. Dat is geen standaardtekst — het is de productdefinitie. Vergelijk dat met de praktische vorm van een lange agentsessie en de afweging wordt concreet.

Een agent die een gesprek gaande houdt, verzamelt context, en lange gesprekken zijn waar prompt-caching zich terugverdient. Een gewijzigd model achter een ongewijzigd endpoint is de klassieke manier om dat te verliezen: de cache is gekoppeld aan het model dat de tokens heeft geproduceerd, dus een stille versiewissel midden in een traject kan ongeldig maken wat je in de cache had en werk opnieuw factureren waarvan je dacht dat het al betaald was. Unbiased' eigen documentatie beargumenteert dit punt in de andere richting — het positioneert zijn blend als cache-stabiel waar een wisselende router dat niet is — dus dit is een risico dat de leverancier goed begrijpt en simpelweg accepteert in ruil voor het uitbrengen van een preview. Het is de moeite waard om het te benoemen, want de fout is onzichtbaar in een dashboard: je tokens worden nog steeds gefactureerd, je antwoorden komen nog steeds terug, en het getal is gewoon hoger dan vorige week.

De voordelen van de preview zijn reëel en weerspiegelen de nadelen. Vier keer zoveel context, gecachte input tegen een achtste van het tarief van de stabiele release op de gerouteerde listing, en überhaupt een benchmarksheet — de septemberrelease had nooit gepubliceerde scores. Als je werkbelasting lang-context en kostengevoelig is, is de preview degene die je wilt, en de manier om hem te gebruiken zonder je hele stack op het spel te zetten, is hem bewust vast te pinnen: een benoemd endpoint voor de preview, een benoemd endpoint voor de stabiele release, en een fallback tussen beide die één keer wordt geconfigureerd. De routing-DSL bestaat precies voor dit soort problemen — stel de twee samen als afzonderlijke routes, stuur een deel van het echte verkeer door elk, en laat het requestlog je vertellen wat elk daadwerkelijk kostte. Een preview zou een beslissing moeten zijn die je met één configregel kunt terugdraaien, niet een eigenschap van je endpoint die je ontdekt via de factuur.

Een prestatiebeeld dat niet stabiel genoeg is om op te vertrouwen

Elk cijfer hierboven komt uit de openbare vermelding, en het eigen prestatiepaneel van de vermelding verschoof tussen uitlezingen op de dag van de lancering. Eén uitlezing van de 26.10 Preview-pagina meldde een mediane latentie van 5,28 seconden en 35 tokens per seconde; een zij-aan-zijweergave die dezelfde dag werd gepubliceerd, meldde 3,54 seconden en 21 tokens per seconde voor de preview en 1,05 seconden en 45 tokens per seconde voor de septemberrelease. Dat zijn geen kleine discrepanties. Een gloednieuw model dat door één aanbieder wordt bediend, heeft een dunne meetbasis, en een rollend venster over uren zal verschuiven.

Eerlijk gezegd heeft geen van beide releases een doorvoer- of latentiecijfer dat stabiel genoeg is om op te plannen, en bij de preview zit dat ingebakken in het product in plaats van dat het een snapshotprobleem is. De septemberrelease heeft tenminste weken aan verkeer gehad — de vermelding toont beschikbaarheid over meerdere dagen in de hoge negentig procent, met een volledige providerhistorie erachter. De preview heeft uren. Als je reden om tussen beide te kiezen snelheid is in plaats van prijs of context, bestaat het bewijs om op te kiezen nog niet, en de verantwoordelijke zet is om op je eigen prompts te meten in plaats van een getal van een van beide pagina's af te lezen.

Wie te bellen, en hoe te stoppen met je iets aan te trekken

Roep de preview aan als je werk long-context, kostengevoelig en evalueerbaar is — agentsessies, batchverwerking, alles waarbij een vier keer zo groot venster en een derde van de invoerprijs opwegen tegen het risico van een wijziging midden in de week. Zie het als een proef met een configregel eronder, en houd je eigen cijfers bij, want die van de leverancier zullen veranderen.

Kies de stabiele Pareto als je workload productie is, latentiegevoelig is, of onder een compliancereview valt die geen model wil dat beschreven wordt als mogelijk zonder kennisgeving veranderend. Je geeft het 1M-venster, de goedkopere cache en de gepubliceerde scores op; je behoudt een endpoint met een trackrecord en een naam die volgende week hetzelfde betekent. Voor veel teams is dat de hele vereiste.

De fout is om dit als een permanente splitsing te behandelen. Unbiased heeft de splitsing opgezet om tijdelijk te zijn — de preview bestaat om te worden geëvalueerd en daarna te worden opgenomen — en de beslissing die ertoe doet is niet welke van de twee je kiest, maar of het wisselen tussen beide een wijziging van vijf minuten is of een project van een kwartaal. Op één endpoint met één model-string is het momenteel geen van beide: het is een aankondiging die je moet opvangen. Configureer de keuze in plaats daarvan als een routeringsbeslissing en de versie die je aanroept wordt een knop, en dat is de enige houding die een preview-release ooit echt heeft beloond.