Pareto 26.10 Preview vs Pareto: Samma modellsträng, två olika modeller

Unbiased släppte Pareto 26.10 Preview den 1 oktober 2026 och lät den tidigare utgåvan, Pareto, stå listad bredvid den. De två är inte varianter av en familj som du väljer mellan med en flagga. De är två utgåvor under ett och samma varumärke, och leverantörens egen modellsträng — pareto — pekar nu på den nyare, uttryckligen instabila utgåvan. Så jämförelsefrågan är egentligen inte ”vilken som är bättre”. Den är: vilken av dem din begäran faktiskt når, och vad händer med svaret när det förändras under fötterna på dig?

Det enda stället där de två beskrivs i samma andetag är modellens offentliga tekniska specifikation. Unbiaseds eget modellkort, prissida och FAQ beskriver en enda sammansatt produkt och nämner aldrig uppdelningen. Den asymmetrin – en detaljerad offentlig diff på ena sidan, tystnad på den andra – är den ärliga utgångspunkten för en direkt jämförelse, eftersom den talar om varifrån varje siffra nedan kommer.

Sex dimensioner, båda sidorna

Allt som skiljer utgåvorna åt ryms i dessa sex rader. Den vänstra sidan är Pareto 26.10 Preview; den högra är Pareto-utgåvan från 17 september, den som förhandsversionens katalogtext kallar det stabila valet.

• Kontextfönster — 1 048 576 tokens mot 262 144 tokens. Fyra gånger utrymmet, på papperet, utan att någon mindre nivå erbjuds för någon av dem.
• Maximal utdata — 131 072 tokens mot 131 072 tokens. Oförändrat. Det större fönstret innebar inte ett större svar.
• Indatapris, enligt routning — 0,80 USD per miljon mot 2,50 USD per miljon. Förhandsversionen är ungefär en tredjedel av priset i den listningen.
• Utdatapris, enligt routning — 3,20 USD per miljon mot 7,50 USD per miljon. Mindre än hälften.
• Cachad indata, enligt routning — 0,03 USD per miljon mot 0,25 USD per miljon. De längsta agenttrajektorierna vinner mest här.
• Publicerat benchmarkblad — fyra poäng, uttryckligen "preliminära" och "kan ändras före slutlig publicering" mot ingen publicerad benchmarktabell alls.

Två av dessa rader är de som avgör det verkliga arbetet. Kontextfönstret är den rubrik som leverantören inte kommer att uppge på sin egen webbplats – den finns i listningen, inte på modellkortet – och priset för cachad indata är det som förändrar en agents räkning snarare än dess tak. Allt annat är antingen ett marknadsföringsdelta eller, när det gäller poängen för utdata, ett medgivande: att publicera siffrorna för en förhandsversion med märkningen "preliminär" är ärligare än alternativet, och det är också en varning.

Priset du tittar på är där du tittar.

Kör de två taxekorten sida vid sida och de stämmer inte överens, vilket är den del av den här jämförelsen som ingen har förklarat.

Unbiaseds egen plattform listar fortfarande $2.50 per miljon indata, $0.25 cachad och $7.50 utdata den dag då 26.10 Preview blev den aktuella versionen. Det är septemberpriserna, oförändrade, både på prissättningssidan och på modellkortet. Den lägre uppsättningen – $0.80, $0.03, $3.20 – visas i den routade kataloglistningen för samma preview. Så en kund som anropar pareto direkt via leverantörens API betalar enligt det gamla priskortet för den nya modellen, medan den routade listningen annonserar ungefär en tredjedel av det. Båda är live. Leverantören har inte publicerat något slutdatum för kampanjen och inget uttalande som bringar dem i överensstämmelse.

Det är en kanalfråga, och i en förhandsversion är det också en tidsfråga: vilket av talen du än räknar dina kostnader utifrån, är det andra bara ett versionsmeddelande ifrån att bli korrekt. En router som för vidare en leverantörs listpris med 0 % påslag tar bort precis denna friktion – en leverantörsprisändring går live samma dag i stället för vid nästa avtalsgenomgång – och det är den enda strukturella saken värd att låna från OrcaRouter här. Vi tillhandahåller inte någon av Unbiased-utgåvorna i dag, så det direkta svaret på ”var anropar jag den” är Unbiaseds eget API, utifrån vilken av de två prisuppsättningarna som listningen du köper via råkar ha. Anledningen till att säga det högt är att skillnaden är en faktor tre, och en förhandsversion är inte rätt plats att upptäcka att du prissatte fel.

Vad förhandsvisningen ger dig, och vad den kostar dig

Förhandsversionens kanoniska beskrivning: den ”kan ändras utan föregående meddelande”, och den som behöver förutsägbarhet hänvisas tillbaka till september. Det är inte standardtext — det är produktdefinitionen. Jämför det med den praktiska formen av en produktsession, och avvägningen blir konkret.

En agent som håller en konversation vid liv samlar på sig kontext, och det är i långa konversationer som prompt-cachning verkligen lönar sig. En ändrad modell bakom en oförändrad endpoint är det klassiska sättet att förlora den: cachen nycklas till den modell som producerade tokenarna, så ett tyst versionsbyte mitt i en trajektoria kan ogiltigförklara det du hade cachat och fakturera om arbete som du trodde redan var betalt. Unbiaseds egen dokumentation argumenterar denna poäng i motsatt riktning — den framställer sin blandning som cache-stabil där en växlande router inte är det — så detta är en risk som leverantören förstår väl och helt enkelt accepterar i utbyte mot att kunna släppa en förhandsversion. Det är värt att sätta ord på eftersom felet är osynligt i en dashboard: dina tokens faktureras fortfarande, dina svar returneras fortfarande, och siffran är bara större än förra veckan.

Previews uppsida är verklig och speglar nedsidan. Fyra gånger så mycket kontext, cachad indata till en åttondel av den stabila versionens pris i den routade listningen, och ett benchmark-ark över huvud taget — septemberversionen hade aldrig några publicerade resultat. Om din arbetsbelastning är långkontextig och kostnadskänslig är previewn den du vill ha, och sättet att ta den utan att satsa hela stacken är att låsa den medvetet: en namngiven endpoint för previewn, en namngiven endpoint för den stabila versionen, och en reservväg mellan dem konfigurerad en gång. Routnings-DSL:en finns till för precis den här typen av problem — sätt samman de två som separata ben, skicka en del av den verkliga trafiken genom vardera, och låt förfrågningsloggen berätta vad vardera faktiskt kostade. En preview bör vara ett beslut du kan backa med en enda konfigrad, inte en egenskap hos din endpoint som du upptäcker via fakturan.

En prestandabild som inte är tillräckligt stabil för att gå att lita på

Varje siffra ovan kommer från den offentliga listningen, och listningens egen prestandapanel förändrades mellan avläsningarna på lanseringsdagen. En avläsning av sidan för 26.10 Preview rapporterade en medianlatens på 5,28 sekunder och 35 tokens per sekund; en jämförande vy som publicerades samma dag rapporterade 3,54 sekunder och 21 tokens per sekund för förhandsversionen och 1,05 sekunder och 45 tokens per sekund för septemberversionen. Det är inte små avvikelser. En helt ny modell som betjänas av en enda leverantör har en tunn mätbas, och ett rullande fönster över timmar kommer att förändras.

Det ärliga läget är att ingen av utgåvorna har en genomströmnings- eller latenssiffra som är tillräckligt stabil för att planera efter, och för förhandsversionen är det inbyggt i produkten snarare än ett ögonblicksbildsproblem. Septemberutgåvan har åtminstone haft veckor av trafik – dess listning visar tillgänglighet över flera dagar i den högre delen av 90-procentsintervallet med en fullständig leverantörshistorik bakom sig. Förhandsversionen har timmar. Om ditt skäl att välja mellan dem är hastighet snarare än pris eller kontext, finns det ännu inga bevis att välja utifrån, och det ansvarsfulla draget är att mäta på dina egna prompter snarare än att läsa av en siffra från någon av sidorna.

Vilken man ska ringa, och hur man slutar bry sig

Använd förhandsversionen om ditt arbete har lång kontext, är kostnadskänsligt och kan utvärderas – agentsessioner, batchbearbetning, allt där fyra gånger fönstret och en tredjedel av indatapriset betalar för risken med en ändring mitt i veckan. Behandla den som en provperiod med en konfigrad under, och behåll dina egna siffror, eftersom leverantörens kommer att ändras.

Välj den stabila Pareto om din arbetsbelastning är produktionskritisk, latenskänslig eller omfattas av en compliance-granskning som inte vill ha en modell som beskrivs kunna ändras utan förvarning. Du avstår från 1M-fönstret, den billigare cachen och de publicerade resultaten; du behåller en endpoint med dokumenterad historik och ett namn som betyder samma sak nästa vecka. För många team är det hela kravet.

Misstaget är att behandla detta som en permanent förgrening. Unbiased byggde delningen för att vara tillfällig – förhandsversionen finns för att utvärderas och sedan absorberas – och beslutet som spelar roll är inte vilken av de två du väljer, utan om att byta mellan dem är en femminutersändring eller ett kvartalsprojekt. På en endpoint med en enda modellsträng är det för närvarande inget av dem: det är ett tillkännagivande du måste fånga upp. Konfigurera i stället valet som ett routingbeslut, och versionen du anropar blir en ratt, vilket är den enda hållning en förhandsversion någonsin verkligen har belönat.