Pareto 26.10 vs Pareto 26.9 : un seul chiffre sépare ces deux versions

Comparer Pareto 26.10 à Pareto 26.9 revient surtout à examiner ce qui n'a pas changé. Même fournisseur, même architecture composite, même longueur maximale de réponse de 131 072 tokens, mêmes cinq paramètres déclarés, mêmes tarifs publiés sur la page de tarification du fournisseur et — sur le seul benchmark commun aux deux versions — un écart d'un dixième de point en faveur du modèle plus ancien. Sur les aspects sur lesquels on compare habituellement les modèles, ces deux versions sont le même produit arborant des numéros de version différents. Sur un aspect, elles ne le sont pas, et c'est cet aspect qui détermine quelles charges de travail peuvent utiliser l'un ou l'autre tout court : la fenêtre de contexte, où 26.9 propose 262 144 tokens et 26.10 en propose 1 048 576. Les défaillances documentées de l'IA et les incidents d'agents derrière des versions comme celle-ci sont recensés dans l'OrcaRouter AI Incident Archive où chaque entrée comporte ses propres sources, sa gravité, son niveau de confiance et son indicateur de contestation.

Les deux sont en service. pareto-26.10 est la version qui est devenue celle par défaut derrière l’alias pareto le 15 octobre 2026, lorsque Unbiased a basculé sa version de disponibilité générale sur celle-ci ; pareto-26.9 est la version de septembre que l’éditeur indique comme « toujours disponible » pour quiconque souhaite rester. C’est là toute la décision à laquelle un appelant fait face aujourd’hui, et le reste de cette page en détaille les éléments.

Les faits environnants

Les deux modèles sont documentés comme acceptant du texte et des images en entrée et renvoyant du texte, et aucun des deux ne publie d’identifiant Hugging Face : les poids sont fermés des deux côtés de cette comparaison, il n’y a donc rien à télécharger ni à auto-héberger. Aucun des deux ne dispose non plus de benchmark indépendant. Tous deux sont servis par un unique fournisseur, Unbiased lui-même, ce qui signifie qu’il n’existe, pour l’une comme pour l’autre version, aucun second hébergeur vers lequel basculer au sein même de l’infrastructure du fournisseur. La comparaison ci-dessous porte donc entre deux configurations d’une seule gamme de produits d’un seul fournisseur, et non entre deux écosystèmes.

Le contexte, c’est tout l’argument.

Une augmentation de contexte de 4× ressemble à une ligne de fiche technique jusqu'à ce qu'on la mette en regard de ce que les gens font réellement avec les modèles à long contexte.

À 262 144 jetons, une session d'agent sur un dépôt complet, une longue transcription de support ou un fil de recherche de plusieurs heures pose un problème de découpage. Vous récupérez, vous résumez, vous maintenez une fenêtre glissante et vous acceptez que le modèle voie une reconstruction de la tâche plutôt que la tâche elle-même. À 1 048 576 jetons, ces charges de travail tiennent — pas toujours confortablement, et pas à bas prix à 0,80 $ par million de jetons d'entrée sans accès au cache, mais elles tiennent. La différence pratique entre les deux versions est de savoir si votre pipeline a besoin d'une couche de récupération entre vos données et le modèle.

C’est une véritable décision d’ingénierie, et c’est aussi la seule sur cette page qui ait une réponse défendable. Tout le reste est suffisamment proche pour que le choix doive se faire sur autre chose que la qualité.

Côte à côte, dimension par dimension

• Chaîne de modèle — pareto-26.10 (par défaut derrière pareto depuis le 2026-10-15) vs pareto-26.9 (conservé, non par défaut).

• Fenêtre de contexte — 1,048,576 jetons vs 262,144 jetons.

• Réponse maximale — 131 072 jetons pour les deux. Inchangé entre les versions.

• Modalités — texte + image en entrée, texte en sortie, sur les deux.

• Paramètres déclarés — max_tokens, temperature, top_p, tools, tool_choice sur 26.10 ; le même ensemble, plus response_format, sur 26.9.

• Appel d’outils — tool_choice limité à auto sur 26.10 ; le modèle décide s’il faut appeler, vous ne pouvez pas le forcer.

• Poids — fermés dans les deux cas ; aucun identifiant Hugging Face dans aucun des deux enregistrements.

• Fournisseurs de services — un seul, le fournisseur, sur les deux.

Tarif publié — 0,80 $ en entrée / 0,03 $ en cache / 3,20 $ en sortie par million pour les deux, selon la page de tarification actuelle du fournisseur.

• DeepSWE v1.1 — 69,9 % à 0,24 $ par tâche sur 26.10 contre 70,0 % à 0,29 $ par tâche sur 26.9, les deux exécutés par le fournisseur.

Deux de ces lignes méritent leur propre paragraphe, car ce sont celles qui sont mal rapportées.

La différence de sortie structurée dont personne ne parle

Les listes de paramètres ne sont pas identiques. La fiche catalogue de 26.9 déclare response_format parmi ses paramètres pris en charge ; celle de 26.10 ne le fait pas. La surface déclarée pour 26.10 est max_tokens, temperature, top_p, tools et tool_choice, point final.

Lisez cela attentivement plutôt que comme un simple titre : l’absence d’un paramètre dans une liste déclarée ne prouve pas que le point de terminaison le rejette, et la documentation API du fournisseur n’énumère ni l’une ni l’autre des listes. Mais si votre pipeline dépend du mode JSON ou d’une sortie contrainte par schéma, et que vous passez de 26.9 à 26.10 en supposant que la version plus récente est un sur-ensemble strict, cette hypothèse n’est étayée par rien de publié. Testez-le sur votre propre trafic avant de migrer, ou prévoyez de valider la sortie côté client. C’est un petit détail qui se transforme en incident un mardi.

Deux grilles tarifaires en vigueur ne s’accordent pas sur ce que coûte 26,9

C’est la partie la plus confuse de la comparaison, et celle qui a le plus de chances d’influencer une vraie décision.

Unbiased publie une grille tarifaire unique — 0,80 $ en entrée, 0,03 $ en entrée mise en cache, 3,20 $ en sortie — et ne la versionne pas par édition. Lu littéralement, cela signifie que 26.10 et 26.9 coûtent aujourd’hui le même prix par token, ce qui rend la migration gratuite et l’augmentation du contexte la seule variable. Pendant ce temps, la fiche technique de référence du modèle conserve encore les chiffres de septembre pour 26.9 : 2,50 $ en entrée, 0,25 $ en cache, 7,50 $ en sortie. Les deux sources étaient en ligne au moment de la rédaction. Aucune des deux n’est datée, et le fournisseur n’a publié aucune entrée de journal des modifications expliquant ce changement, de sorte qu’il n’existe nulle part dans les archives de ligne citable du type « ce jour-là, le prix a baissé ».

Le conseil pratique est peu glamour. Partez de la carte inférieure, car deux des trois surfaces que vous pouvez consulter l’affichent et l’une d’elles est la page sur laquelle un client est facturé — puis vérifiez à nouveau avant de retenir un chiffre dans un budget. Si vous figez l’une ou l’autre version pour l’imputation des coûts, sachez qu’un mois mixte à cheval sur la transition du 15 octobre ne se décomposera pas proprement après coup, car les versions ont été tarifées différemment à des moments différents et le fournisseur ne date pas ses changements.

Un score, un dixième de point, et rien à conclure.

Le seul benchmark que les deux versions ont en commun est DeepSWE v1.1, et les propres chiffres du fournisseur placent 26.9 à 70,0 % et 26.10 à 69,9 %. Les deux chiffres proviennent d’exécutions réalisées par le fournisseur, le plus ancien portant sur un sous-ensemble de 30 tâches plutôt que sur le jeu d’évaluation complet, et l’ensemble de la comparaison est décrit par Unbiased comme n’ayant pas été validé de manière indépendante.

L'interprétation honnête est que cette mesure ne permet pas de distinguer les versions. Un dixième de point sur une tranche partielle de tâches se situe dans le bruit d'une seule exécution, et l'interpréter comme un classement, dans un sens comme dans l'autre — « 26.10 a régressé » ou « 26.10 est meilleur parce qu'il coûte moins cher par tâche » —, c'est lire dans les feuilles de thé. Les chiffres du coût par tâche divergent davantage (0,24 $ contre 0,29 $), et même ceux-ci proviennent d'exécutions réalisées à des mois différents sur un modèle mixte dont le fournisseur ne divulgue pas la composition sous-jacente.

Ce que la fiche vous dit, c’est où ne pas chercher. Si vous choisissez entre ces deux modèles sur la qualité, vous vous appuyez sur un chiffre qui ne peut pas justifier ce choix. Les éléments qui les distinguent sont architecturaux — la fenêtre de contexte et la surface des paramètres — et tous deux sont vérifiables d’une manière que les scores ne sont pas.

Lequel appeler, selon la charge de travail

• Codage agentique sur un dépôt complet — 26.10. La fenêtre de 1 M fait la différence entre envoyer le dépôt et en envoyer un résumé.

• Analyse de documents longs ou de transcriptions longues — 26.10, pour la même raison, et surveillez la facture d’entrée : 1M de tokens sans hit de cache, c’est $0.80 par requête rien qu’en entrée.

• Pipelines de sortie en mode JSON ou contraints par schéma — 26.9 jusqu’à ce que vous ayez testé vous-même le comportement de 26.10, car la liste des paramètres déclarés de 26.9 inclut response_format, alors que celle de 26.10 ne l’inclut pas.

• Une charge de travail déjà en production et tenant dans 262K — 26.9. Aucune preuve publiée n'indique qu'un changement améliore les résultats, et l'épinglage est la décision la moins coûteuse.

• Tout cas où vous souhaitez la valeur par défaut actuelle du fournisseur sans maintenir une version épinglée — 26.10, via l’alias pareto nu, en sachant que l’alias suit le calendrier du fournisseur plutôt que le vôtre.

Pour les équipes qui exécutent les deux côtés d’une boucle de construction et de vérification, le schéma utile consiste à épingler 26.10 pour la passe en contexte long et à garder 26.9 disponible comme bras de comparaison — ce à quoi sert précisément une couche de routage. OrcaRouter ne propose aucun modèle Unbiased, donc les deux chaînes sont appelées via l’API propre du fournisseur ; ce que nous fournissons, c’est une clé et une intégration pour les modèles, ce qui vous permet de comparer 26.10 à ces derniers, donc évaluer le changement ne signifie pas signer un second contrat. OrcaRouter répercute directement le prix catalogue du fournisseur avec 0 % de marge, ce qui porte sur les modèles que nous servons, pas sur celui-ci.

La migration que personne n’a planifiée

La raison pour laquelle cette comparaison est concrète plutôt qu’académique, c’est que le changement s’est déjà produit pour des personnes qui ne l’avaient pas demandé. Le 15 octobre, l’alias pareto est passé de la version de septembre à 26.10. Toute personne appelant la chaîne nue a obtenu une fenêtre de contexte quadruplée et une interface de paramètres différente sans modification du code — et, comme la documentation du fournisseur indique que les identifiants de modèle inconnus ne sont pas rejetés, une référence de version mal orthographiée est toujours servie et facturée comme Pareto au lieu d’échouer explicitement.

Si vous étiez plutôt sur la chaîne preview, cette voie est désormais fermée : Unbiased a demandé aux utilisateurs de preview de passer à pareto ou pareto-26.10. Si vous étiez sur pareto et que vous supposiez une stabilité, cette hypothèse est désormais visible dans vos propres journaux, qu’elle ait ou non causé un problème.

Dans les deux cas, le correctif est le même et tient en une ligne : nommez la version que vous avez testée. Une chaîne qualifiée par la version est ce qui rend un modèle de coût soustractable et une régression attribuable, et c’est le seul mécanisme que ce fournisseur vous offre pour l’un comme pour l’autre.

Qu'est-ce qui reste encore non vérifié ?

Aucune des deux versions ne dispose d’un benchmark indépendant. Artificial Analysis ne propose de page pour aucune des deux, et aucun évaluateur n’a publié de nouvelle exécution du harnais du fournisseur. Chaque chiffre de cette comparaison — les quatre scores, les coûts par tâche, les fenêtres de contexte — est soit publié par le fournisseur, soit issu de la fiche technique de référence du modèle, et les scores portent spécifiquement les libellés « préliminaire » et « non validé indépendamment » du fournisseur lui-même.

Ce n’est pas une raison pour éviter l’un ou l’autre modèle. C’est une raison de trancher sur ce qui est vérifiable : si votre charge de travail tient dans 262K, si votre pipeline a besoin de response_format, et si vous préférez rester sur l’alias ou sur un pin. Ces trois questions ont des réponses. La question de savoir quel modèle est meilleur n’en a pas, et aucune lecture, même attentive, de la fiche publiée ne permettra d’en produire une.