Pareto 26.9 vs l'aperçu Pareto 26.10 d'Unbiased : la version stable épinglée et l'aperçu

La gamme Pareto d’Unbiased propose désormais deux versions appelables avec deux réponses différentes à la même question, et depuis cette semaine, vous devez en choisir une délibérément. Pareto 26.9 est la version vers laquelle l’alias par défaut du fournisseur pointe : 262 144 tokens de contexte, 2,50 $ par million de tokens d’entrée, aucune date d’expiration associée. Pareto 26.10 Preview est la version à activer volontairement : quatre fois plus de contexte, environ un tiers du prix d’entrée, quatre scores de benchmark que le fournisseur lui-même qualifie de préliminaires, et une date d’expiration inscrite dans sa fiche catalogue. Les deux sont disponibles. Les deux acceptent du texte et des images en entrée et renvoient du texte. Ni l’une ni l’autre n’est une variante de l’autre que vous pouvez basculer avec un indicateur au moment de la requête.

Ce qui a changé, ce n'est ni l'un ni l'autre des modèles. C'est que la version stable dispose enfin de sa propre adresse. Le 13 octobre 2026, le catalogue routé qui répertorie cette famille a commencé à référencer unbiased/pareto-26.9 comme une entrée appelable distincte, aux côtés d'une entrée alias qui redirige toujours vers la version en cours. Avant cela, le seul moyen d'atteindre le modèle stable avec certitude était de demander Pareto et d'accepter ce que l'alias vous renvoyait. Désormais, les deux versions figurent dans la même liste avec leurs propres tarifs, leurs propres limites et leurs propres métadonnées d'expiration — et choisir entre elles est une décision que vous prenez, plutôt qu'une décision prise à votre place.

Les deux versions, dimension par dimension

Chaque différence publiée entre eux tient dans ces sept lignes. À gauche : Pareto 26.9 ; à droite : Pareto 26.10 Preview.

• Fenêtre de contexte — 262 144 tokens vs 1 048 576 tokens. Quatre fois plus de place, sans palier inférieur proposé pour l'un ou l'autre. • Sortie maximale — 131 072 tokens vs 131 072 tokens. La fenêtre d'entrée plus grande n'a pas apporté de réponse plus grande. • Prix d'entrée — 2,50 $ par million de tokens vs 0,80 $. L'aperçu représente environ 32 % du tarif stable. • Prix de sortie — 7,50 $ par million de tokens vs 3,20 $. Environ 43 % de celui-ci. • Entrée mise en cache — 0,25 $ par million de tokens vs 0,03 $. L'aperçu est à peu près un huitième, ce qui est la ligne qui modifie le plus la facture d'un agent de longue durée. • Fiche de référence publiée — un score, sur une tranche de tâches partielle, vs quatre scores que le fournisseur qualifie de préliminaires. • Conditions de stabilité — aucune expiration sur la fiche, et le fournisseur appelle ceci la version par défaut vs un aperçu opt-in dont la fiche catalogue porte une date d'expiration au 15 octobre 2026.

Deux de ces lignes font l'essentiel du travail. Le taux d'entrée mise en cache est celui qui décide si une longue trajectoire agentique reste abordable, quelle que soit la version, et le champ d'expiration est celui qui décide si le preview est véritablement quelque chose sur lequel on peut construire.

Pourquoi les numéros de version ne correspondent pas

Les nombres sont des étiquettes de mois, pas une séquence à partir de laquelle raisonner. La fiche de modèle d’Unbiased elle-même date Pareto 26.9 d’une exécution du 20 septembre 2026 et décrit 26.10 Preview comme la version du 1er octobre qui a suivi. Le catalogue qui liste 26.9 montre qu’elle entre dans son registre le 13 octobre — trois semaines après la date de sortie que le fournisseur imprime. Et l’article de lancement du fournisseur pour l’aperçu indique que la version précédente « 26.9 » avait tourné pendant deux semaines sur des passerelles tierces sous un nom temporaire avant d’être nommée.

Réunissez ces trois affirmations, et la leçon pratique est qu’un numéro de version ici vous indique de quel mois provient une build, et rien sur le fait qu’elle soit encore actuelle, encore prise en charge, ou encore celle qui se cache derrière l’alias. Cela signifie aussi que la date que vous voyez sur une page de catalogue est une date de référencement, pas une date de sortie. L’interpréter comme cette dernière est l’erreur la plus courante commise à propos de cette famille, et elle est désormais commise dans les deux sens : 26.9 semble trois semaines plus récent qu’il ne l’est, et l’aperçu semble cinq semaines plus ancien.

Ce que l'aperçu apporte, et ce que dit réellement la fiche de benchmark

L’argument en faveur de la preview est arithmétique. Quatre fois le contexte pour un tiers du prix d’entrée, avec un tarif de lecture de cache suffisamment bas pour qu’une longue trajectoire coûte une fraction de ce qu’elle coûterait sur 26.9. Unbiased affirme également une latence plus faible sur la preview, le gain le plus important étant sur les longues exécutions agentiques — une affirmation qu’aucune mesure publiée ne vient étayer, ni de la part du fournisseur ni de qui que ce soit d’autre.

L'argument contre le fait de s'y précipiter par réflexe est plus subtil et se niche dans le seul endroit où les deux versions peuvent réellement être comparées. Sur DeepSWE v1.1, le benchmark de codage agentique sur lequel les deux versions figurent, la fiche modèle du fournisseur indique Pareto 26.9 à 70,0 % à 0,29 $ par tâche et Pareto 26.10 Preview à 69,9 % à 0,24 $ par tâche. La version plus récente et moins chère obtient un score légèrement inférieur sur le seul benchmark où les deux disposent d'un chiffre, et elle l'emporte sur le coût par tâche d'environ 17 %. Ce n'est pas un scandale et ce n'est pas une erreur d'arrondi qu'on peut balayer d'un revers de main — c'est exactement à quoi devrait ressembler un système mixte moins cher, et cela vaut la peine de le savoir avant de supposer que la preview est une mise à niveau stricte.

Deux mises en garde s'imposent sur cette comparaison, et le fournisseur publie les deux. Le chiffre de 26,9 provient d'un sous-ensemble de 30 tâches, et non de l'ensemble complet DeepSWE v1.1, donc ce n'est pas la même mesure que celle de l'aperçu. Et tous les chiffres ici sont exécutés par le fournisseur : les quatre scores de l'aperçu — 92,4 % sur GPQA-Diamond, 49,9 % sur Humanity's Last Exam en version texte, 69,9 % sur DeepSWE v1.1, 50,8 % sur Terminal-Bench 4.0 — portent la mention « préliminaire, susceptible de changer avant la publication finale » du fournisseur lui-même, et la fiche du modèle indique que les dénominateurs et la méthodologie de coût « nécessitent encore une confirmation ». Personne en dehors d'Unbiased n'a publié de score pour l'une ou l'autre version. Considérez l'ensemble du tableau comme une raison de tester, et non comme une raison de changer.

L’expiration est la partie à anticiper.

La fiche de l’aperçu porte une date d’expiration au 15 octobre 2026 — un jour après que ces lignes ont été écrites. Ce qui se passe à cette date n’est documenté nulle part, pour autant que nous ayons pu le trouver : ni dans le journal des modifications, ni sur la fiche du modèle, ni sur la page des tarifs. Rien dans la documentation du fournisseur n’indique que l’aperçu cesse d’être servi, et l’article de lancement dit, dans l’esprit, l’inverse d’un arrêt — que « le prix n’augmentera pas, et que le slug de l’aperçu ne vous lâchera pas », et qu’au passage en version définitive, 26.10 devient la version par défaut des abonnés tandis que les quotas hebdomadaires doublent, de 25 M à 50 M de tokens sur le forfait Personal à 10 $ et de 300 M à 600 M sur l’offre à 100 $.

Donc, la lecture honnête n'est pas « la préversion meurt demain ». C'est que la préversion est régie par des conditions qui évoluent, et qu'un build dont l'enregistrement comporte un champ d'expiration n'est pas la version à épingler pour un système que vous ne voulez pas revisiter. C'est tout l'argument en faveur de 26.9 comme valeur par défaut : il est plus lent à s'améliorer et il est facturé trois fois plus cher en entrée, mais c'est celui que le fournisseur appelle la version plutôt que l'expérimentation, et son enregistrement ne porte aucune horloge.

Maintenir les deux sans réécrire l'intégration

Si c'est une décision de routage et non de modélisation, c'est parce que les deux versions acceptent la même forme de requête. Même famille de points de terminaison, mêmes paramètres, même interface texte-et-image en entrée / texte en sortie — la seule chose qui diffère, c'est la chaîne que vous placez dans le champ model. La surface de migration s'en trouve donc minuscule, et toute la difficulté tient dans la discipline d'épinglage : une seule valeur, à un seul endroit, détermine lequel de deux systèmes aux tarifs très différents vous répond.

C'est le cas pour lequel le DSL de routage sur OrcaRouter a été conçu. Vous composez un appel à partir de segments nommés et conservez la chaîne de modèle comme valeur de configuration plutôt qu'une constante enfouie dans le code de l'application, de sorte que passer d'un aperçu à une version stable épinglée est une modification de la route plutôt qu'un déploiement. Il en va de même pour la chaîne de basculement : un aperçu qui change, expire ou commence à renvoyer des erreurs devient un événement de repli plutôt qu'un incident. Nous ne proposons aucune des deux versions d'Unbiased — il s'agit d'une famille servie par un fournisseur unique, le fournisseur lui-même — de sorte que pour l'appeler, il faut passer par l'API d'Unbiased elle-même, et si votre objectif est de comparer les deux versions à votre propre charge de travail, les deux y sont accessibles aujourd'hui.

Lequel épingler ?

Si vous livrez quelque chose qui doit répondre le mois prochain sans que personne n’y touche, épinglez Pareto 26.9. Il coûte trois fois plus cher par token d’entrée et vous donne un quart du contexte, et en échange, c’est la version vers laquelle pointe l’alias du fournisseur, elle n’a pas de champ d’expiration, et son seul benchmark publié — un score sur une tranche partielle — se trouve être le plus élevé des deux. C’est la réponse ennuyeuse, et c’est la bonne pour un chemin de production.

Si vous êtes en phase d'évaluation, ou si votre charge de travail est à contexte long et suffisamment sensible aux coûts pour qu'un tiers du prix d'entrée change ce qui est viable, exécutez Pareto 26.10 Preview délibérément et derrière un mécanisme de repli. Un tarif d'entrée mise en cache de 0,03 $ par million contre 0,25 $, c'est la différence entre une boucle d'agent que vous pouvez vous permettre toute la journée et une que vous rationnez, et la fenêtre de 1 048 576 jetons est la seule des deux qui puisse contenir un grand dépôt ou un long ensemble de documents en une seule requête. Prenez le prix, prenez la fenêtre, et gardez la date d'expiration dans une entrée de calendrier plutôt que dans vos hypothèses.

Ce qui changerait ce conseil est précis et vérifiable : une annonce indiquant que la préversion est passée en disponibilité générale et que l’alias a été déplacé, un benchmark indépendant pour l’une ou l’autre version, ou le fait que la préversion continue d’être servie au-delà du 15 octobre aux mêmes tarifs. N’importe lequel de ces éléments transforme un choix à deux options en un choix à sens unique. Tant qu’aucun ne se concrétise, les deux versions de cette famille sont véritablement des produits différents avec des profils de risque véritablement différents, et la seule chose que vous contrôlez est la chaîne que transportent vos requêtes.

Une version susceptible de changer sous vos pieds en milieu de semaine est le cas pour lequel le basculement automatique a été conçu : basculement automatique une préversion qui expire ou commence à générer des erreurs devient un événement de repli plutôt qu'un incident.