TokenLab Fusion : Preuves issues du jeu de données de recherche DRACO Weighted-100

Note sur l'état de la recherche : TokenLab Fusion : il s'agit d'une preuve de concept (proof-of-recipe), un résultat de recherche basé sur une référence historique solide, et non d'une revendication de production. Les résultats ont été obtenus en utilisant une ancre Gemini premium ; un test « canary » sans version premium et une nouvelle exécution finale utilisant uniquement Fusion sont en attente pour confirmer la reproductibilité sans dépendances premium. Le DRACO weighted-100 est une évaluation interne propriétaire de TokenLab et ne constitue pas un benchmark externe ou standardisé. À interpréter en conséquence.

Résumé

Ce rapport documente l'état actuel des preuves concernant TokenLab Fusion, un système d'orchestration d'inférence multi-modèle évalué par rapport à une suite de recherche fixe et pondérée de 100 tâches multi-domaines (le manifeste de recherche DRACO weighted-100, couvrant la finance, le shopping/comparaison de produits, l'académique, la technologie, les connaissances générales, le design UX, le droit, la médecine, la recherche d'aiguille dans une botte de foin et les tâches d'assistant personnalisé). La question centrale de la recherche n'est pas de savoir si un ensemble de modèles peut obtenir un score global plus élevé qu'un modèle unique sur une tranche de benchmark, mais si une recette disciplinée (composition du panel, synthèse, validation basée sur des rubriques, recherche de preuves et comptabilité des coûts) peut être organisée en un système reproductible, auditable et évolutif qui surpasse les références de modèles uniques solides dans tous les domaines, et pas seulement sur un sous-ensemble favorable.

Les preuves les plus solides à ce jour proviennent de l'exécution de recherche weighted-100, une évaluation appariée avec des références contre gpt-5.5 et claude-opus-4-8 sur le jeu de données fixe de 100 tâches DRACO. TokenLab Fusion a obtenu une moyenne de 86.04, avec un delta moyen apparié de +32.60 par rapport à gpt-5.5 (victoire/défaite/nul 95/4/1, coût 0.71x, score par dollar 2.26x) et de +45.63 par rapport à claude-opus-4-8 (victoire/défaite/nul 97/2/1, coût 0.69x, score par dollar 3.06x). Ces chiffres sont solides, appariés et reproductibles par rapport à un manifeste fixe, mais ils comportent deux qualifications importantes que ce rapport traite comme des conclusions de premier ordre, et non comme des notes de bas de page : la recette gagnante a utilisé un modèle Gemini Pro premium historique (gemini-3.1-pro-preview) comme ancre de synthèse/jugement/validation, et l'état de préparation à la mise en production du système nécessite encore une exécution finale utilisant uniquement Fusion avant que le résultat puisse être considéré comme complet. Le reste de ce rapport sépare ce qui a été prouvé lors de l'exécution de recherche avec références solides de ce qui reste bloqué avant toute revendication de production, et expose les preuves spécifiques encore nécessaires, plus urgemment un test « canary » sans Gemini premium, pour combler cet écart.

1. Portée et objectif de la recherche

TokenLab Fusion est défini ici comme une orchestration au moment de l'inférence à travers plusieurs modèles en amont, et non comme un modèle fusionné par entraînement. Une requête unique est acheminée à travers plusieurs rôles de modèles (panéliste, synthétiseur, validateur, juge, réviseur, propriétaire d'outil), et la recette contrôle la manière dont les sorties sont générées, comparées, réécrites et renvoyées. Cela se rapproche davantage d'une configuration de production multi-modèle vérifiable que d'un vote d'ensemble sans état ; cela partage une ascendance structurelle avec Mixture-of-Agents et LLM-Blender, bien que l'appareil de sélection de recette et de comptabilité des coûts décrit ci-dessous aille au-delà de l'un et de l'autre.

La cible de l'évaluation est la suite de recherche weighted-100 : un ensemble fixe de tâches de recherche multi-domaines, denses en preuves et strictement notées selon des rubriques. Le programme de recherche rejette explicitement les comparaisons avec des références faibles. Les seules références acceptées sont gpt-5.5 et claude-opus-4-8, et toutes deux sont strictement tenues à l'écart des rôles de panel, de synthèse, de juge, de validateur et de propriétaire d'outil de Fusion ; contaminer le panel avec le modèle de référence invaliderait toute revendication selon laquelle « une recette multi-modèle moins chère bat un modèle unique solide ».

Les identifiants de modèles référencés dans ce document--gpt-5.5, claude-opus-4-8, gemini-3.1-pro-preview, deepseek-v4-pro et glm-5.2--sont des identifiants de modèles logiques de la plateforme TokenLab Fusion et des identifiants de références de recherche capturés à partir de l'instantané de la source unique de vérité (SSOT) des modèles TokenLab observé le 07/07/2026. Ces identifiants désignent des étiquettes de routage et d'évaluation internes plutôt qu'un classement public indépendant et audité, et aucune prétention n'est faite que ces noms correspondent un à un à la dénomination de sortie publique d'un fournisseur externe. Les identifiants tels que gpt-5.5 et claude-opus-4-8 sont des étiquettes internes de référence et de routage tirées de la SSOT de TokenLab et ne doivent pas être interprétés comme des désignations de version de modèle de fournisseur public. Par conséquent, les comparaisons avec des références solides dans ce document ne doivent pas être lues comme une revendication complète de préparation à la production : l'évaluation « canary » sans Gemini premium et la nouvelle exécution finale utilisant uniquement Fusion n'ont pas encore été terminées et restent bloquées en attendant une validation supplémentaire. Les résultats présentés ici représentent une comparaison de recherche à un instant T, et non un résultat de benchmark de production finalisé ou entièrement validé.

Deux gammes de produits partagent cette infrastructure de recherche mais divergent sur la recette : une gamme Deep Research (fondée sur des preuves, vérifiée pour la suffisance des sources, lourde en validateurs) et une gamme Coding Agent (lourde en exécution d'outils, sensible à la latence, encore en phase pré-0). Ce rapport concerne principalement la gamme Deep Research, car c'est là que des preuves appariées contre des références solides existent actuellement.

2. Pourquoi un manifeste fixe de 100 tâches

Une exécution de benchmark sur une seule tranche ne peut pas soutenir des décisions de recette. Le manifeste de 100 tâches existe pour remplir six fonctions d'ingénierie distinctes simultanément : sélection de recette inter-domaines (évitant le surapprentissage sur une tranche chanceuse), données d'entraînement de la politique de routage, preuves d'attribution des rôles de modèles, construction de courbes coût/qualité/latence, bibliothèque d'échecs pour les tests de régression et futurs tests « canary » de mise à niveau de modèles, et un ensemble de régression en couches réutilisable qui ne nécessite pas une exécution complète à chaque fois qu'un modèle en amont change.

Le manifeste utilisé dans les expériences rapportées est weighted-100-v1, une tranche pondérée déterministe avec un hachage d'ensemble de tâches fixe (b08a09aacbc76c5e5aafd5ca0a6fa614a5061bc478f905007ae5aee4a93fc43a). Sa pondération par domaine n'est pas uniforme : Finance (20), Shopping/Comparaison de produits (16), Académique (12), Technologie (10), Connaissances générales (9), Design UX (9), Droit (6), Médecine (6), Recherche d'aiguille dans une botte de foin (6), Assistant personnalisé (6). Cette distribution est importante car les gains de Fusion dépendent du domaine, et la finance en particulier comporte le risque ouvert le plus persistant (Section 6).

DRACO weighted-100 est un jeu de données de recherche interne à TokenLab utilisé exclusivement au sein du pipeline d'évaluation TokenLab Fusion de ce document. Il ne s'agit pas d'un benchmark externe maintenu publiquement, et il n'est pas affilié à, approuvé par, ou tiré d'une suite de benchmark tierce. Le manifeste weighted-100, y compris son échantillonnage d'éléments, son schéma de pondération des catégories et ses métadonnées de provenance, est régi par une carte source privée de TokenLab qui n'est pas publiée avec ce document. Les scores rapportés doivent donc être interprétés comme des signaux comparatifs internes spécifiques à la méthodologie d'évaluation de TokenLab plutôt que comme des scores comparables aux classements publics ou aux benchmarks communautaires. Les lecteurs ne doivent pas supposer que les résultats de DRACO weighted-100 se généralisent à, ou peuvent être recoupés avec, tout autre jeu de données portant un nom ou une structure similaire.

3. Méthodologie

La boucle de recherche est axée sur les preuves : chaque revendication solide doit être traçable jusqu'à un manifeste fixe, des identifiants de tâches, des pondérations de domaine, des paramètres d'exécution, des fichiers de résultats bruts, des lignes de coûts et des lignes de référence. Les chiffres récapitulatifs agrégés sans ces artefacts ne sont pas traités comme des preuves.

Quatre engagements méthodologiques sont primordiaux.

Preuves partagées plutôt que recherche native opaque

Les outils de recherche, de récupération et de lecture produisent un pack de preuves externe aux modèles testés, et ce même pack est fourni à la fois au panel et aux modèles de référence dans la mesure du possible. Cela isole la capacité du modèle à « raisonner et synthétiser correctement » de celle à « avoir bien recherché », et c'est une exigence stricte pour les exécutions de preuve de la suite de recherche weighted-100, les comparaisons avec des références solides, les tests « canary » de mise à niveau de modèles et les exécutions finales.

Comptabilité des coûts séparée par rôle

Dans une exécution avec références, la colonne de coût agrégé mélange les appels Fusion et les appels de référence ; l'utiliser directement surestimerait ou sous-estimerait la revendication de coût propre à Fusion. L'analyse de l'exécution de recherche weighted-100 exclut explicitement les lignes de référence et de score de référence pour arriver à un total officiel propre à Fusion de 12.837461 $ sur 799 lignes de coûts. Cette distinction, des lignes de coûts séparées par rôle plutôt que des totaux mélangés, est la base de chaque revendication de qualité ajustée au coût dans ce rapport.

Comparaison appariée plutôt que moyennes non appariées

Les sorties de Fusion et de référence sont comparées sur des identifiants de tâches identiques, et les résultats sont rapportés sous forme de delta moyen, intervalle de confiance bootstrap, valeur p du test de signe, nombre de victoires/défaites/nuls, multiplicateur de coût, multiplicateur de latence et delta du taux d'échec. Les moyennes non appariées avec une couverture de tâches différente ne sont pas acceptées comme preuve.

Exécution résumable et fragmentée

L'exécution de recherche weighted-100 a été réalisée en dix fragments de dix tâches chacun, puis agrégée en un seul artefact de preuve. L'exécution finale utilisant uniquement Fusion (Section 6) utilise le même modèle étagé et résumable.

Dimension des méthodes	Approche utilisée	Justification
Sélection des tâches	Manifeste fixe pondéré de 100 tâches, haché	Empêche les tranches sélectionnées, permet les réexécutions
Recherche de preuves	Pack de preuves partagé et reproductible	Isole la qualité du raisonnement de la chance lors de la recherche
Isolation des références	gpt-5.5, claude-opus-4-8 exclus du panel/synth/juge/validateur	Empêche la contamination des références dans la revendication Fusion
Comptabilité des coûts	Lignes séparées par rôle ; les totaux Fusion excluent les appels de référence	Évite la distorsion des coûts/dollar due aux coûts mélangés
Conception de la comparaison	Appariée, mêmes identifiants de tâches, IC bootstrap, test de signe	Contrôle la variance du domaine et de l'échantillon
Exécution	Exécuteurs fragmentés et résumables	Permet le suivi des progrès partiels et les réexécutions par étapes
Notation	Notation par validateur/juge basée sur des rubriques de domaine	Permet l'ablation du validateur et la décomposition des scores

TokenLab Fusion évalue les sorties des modèles via un pipeline de notation automatisé qui agrège plusieurs signaux de métriques en un score composite. Les règles de notation sont appliquées par programmation sans examen manuel à ce stade. Les données d'audit humain public ou d'accord inter-évaluateurs pour cette méthode n'ont pas encore été publiées ; les résultats rapportés reflètent uniquement une évaluation automatisée, en attendant une vérification indépendante.

Disponibilité des données

Le hachage du manifeste, les lignes de coûts, les fichiers de résultats bruts, l'instantané de la source unique de vérité des modèles et la carte source sous-jacents à cette étude sont conservés dans l'archive de recherche interne de TokenLab. Ces matériaux sont à accès restreint et ne sont pas publiés avec ce document. Par conséquent, la reproductibilité publique est limitée jusqu'à ce qu'un échantillon expurgé ou un sous-ensemble public des données sous-jacentes soit publié.

4. Évolution de la recette : Plus de modèles n'est pas le levier

Une découverte précoce et importante est négative : ajouter plus de modèles au panel n'améliore pas de manière fiable la qualité, et on ne peut pas supposer que ce soit le cas. La recette a évolué par une séquence d'ablations contrôlées plutôt qu'en augmentant la taille du panel.

Cœur rapide comme groupe témoin

Un panel de trois modèles à faible coût, diversifié et stable (gemini-3.1-flash-lite, deepseek-v4-flash, grok-4-1-fast-non-reasoning) sert de condition témoin pour le coût/latence par rapport à laquelle chaque ajout et chaque variante de validateur est mesuré.

Mix de modèles concrets à faible coût

TokenLab Fusion est une couche d'orchestration au moment de l'inférence, et non un modèle à poids fusionnés : il coordonne les appels vers plusieurs modèles existants et combine leurs sorties lors de l'exécution. Pour rendre cela concret, les modèles de référence gpt-5.5 et claude-opus-4-8 sont exclus de chaque rôle Fusion — panel, synthèse, juge, validateur, réviseur et propriétaire d'outils — afin que les gains rapportés ne puissent être attribués à ces références effectuant un travail caché au sein du pipeline.

La configuration par défaut est un panneau de contrôle rapide et peu coûteux composé de trois modèles exécutés en parallèle, avec un quatrième panéliste optionnel évalué en mode qualité, une ancre historique de preuve de plafond, et un candidat « canary » sans prime attendant encore des preuves appariées.

Rôle	Modèle(s)	Statut
Panneau de contrôle rapide à faible coût	gemini-3.1-flash-lite, deepseek-v4-flash, grok-4-1-fast-non-reasoning	Panneau à faible coût testé par défaut
Candidat d'ajout de qualité	kimi-k2.7-code	Évalué comme quatrième panéliste ; non promu — ajoute de la latence, régresse dans certains domaines avec le validateur
Ancre de preuve historique	gemini-3.1-pro-preview	Utilisé pour la synthèse/le juge/le validateur/la révision dans la recette de référence forte ; prouve un plafond, pas le chemin de coût produit visé
Candidat « canary » sans prime	deepseek-v4-pro (synthèse/validation/révision), glm-5.2 (juge indépendant)	Chemin de coût prévu ; en attente de preuves « canary » appariées

L'orchestration se déroule selon une séquence fixe plutôt que comme une libre concurrence d'appels de modèles :

1. Construire un pack de preuves partagé une seule fois, afin que chaque panéliste raisonne sur un contexte identique.
2. Exécuter les panélistes à faible coût en parallèle sur ce pack de preuves.
3. Normaliser les sorties du panel dans un format commun pour comparaison.
4. Exécuter l'analyse du panel pour faire ressortir les accords, les conflits et les preuves manquantes.
5. Synthétiser une réponse unique, puis exécuter un validateur sensible aux rubriques et réviser une fois si le validateur signale des problèmes.
6. Noter/juger la réponse finale, avec un seul propriétaire d'outil désigné — les panélistes n'exécutent jamais d'outils directement.

Le résultat de kimi-k2.7-code et le candidat « canary » deepseek-v4-pro/glm-5.2 en attente sont rapportés séparément des chiffres du panel par défaut afin d'éviter de confondre une configuration évaluée mais non adoptée avec la recette de coût produit visée.

Ajout de Kimi : un signal réel mais marginal

Un pilote de 20 tâches ajoutant un modèle de codage/diversité au cœur rapide a produit un score moyen de 34.36 contre 31.37 pour le cœur rapide (delta apparié +2.99, IC 95 % -0.04 à 6.10, victoire/défaite/nul 11/6/3, coût ~1.01x, latence ~1.57x). L'IC chevauchant zéro et une valeur p du test de signe de 0.3323 signifient que ce n'est pas assez fort pour justifier de faire de cet ajout une valeur par défaut sensible à la latence ; il a également régressé sur certaines tâches académiques, médicales et technologiques. La conclusion tirée est spécifique au rôle : cette classe de modèle est mieux traitée comme un spécialiste du codage/front-end/contexte long qu'un panéliste polyvalent toujours actif.

Les ajouts de GLM et DeepSeek Pro nécessitent des rôles, pas une inclusion globale

Un ajout de GLM n'a produit qu'environ +1.22 à un coût de 1.49x et une latence de 1.85x sur une petite tranche, une preuve utile pour un rôle de juge/synth/réviseur de code, mais pas une preuve suffisante pour une promotion par défaut dans le panel. L'évaluation de DeepSeek V4 Pro a changé matériellement après une correction de prix (entrée 0.435 $, sortie 0.87 $ par 1M de jetons), ce qui a invalidé un jugement antérieur de « trop cher » et l'a élevé au rang de candidat principal pour un rôle de synth/validateur dans une recette à moindre coût (Section 6). La correction de prix de DeepSeek V4 Pro découle de la SSOT interne des modèles observée le 07/07/2026 et constitue une hypothèse de coût de recherche plutôt qu'une citation d'un prix publié par un fournisseur externe.

Le validateur/réécriture est le plus grand levier unique trouvé

Dans une expansion de 20 tâches, l'ajout d'une étape de validateur/réécriture basée sur des rubriques au cœur rapide a produit un score moyen de 81.70 contre 29.88 pour le cœur rapide seul, un delta apparié de +51.81 (IC 95 % 42.64 à 61.23), victoire/défaite/nul 20/0/0, à un coût de 2.14x et une latence de 1.89x. Ce n'est pas une amélioration incrémentale ; c'est un changement structurel dans ce dont la recette est capable. Ce n'est pas non plus gratuit : le multiplicateur de coût a dépassé le seuil de maintien automatique de 2.0x lors d'un passage d'analyse, ce qui signifie que le même résultat qui vaut sans ambiguïté la peine pour un niveau de recherche approfondie est une contrainte réelle pour un niveau de produit rapide/bon marché. Des alternatives moins chères ont été testées et rejetées comme valeurs par défaut : une variante de révision légère/pile légère a perdu environ 28 points par rapport à la validation complète et a perdu chaque comparaison appariée ; une validation sélective basée sur des heuristiques de domaine faible n'a économisé qu'environ 11 % du coût tout en perdant -8.53 au score moyen, et une variante sélective à haut risque a perdu davantage. La validation sélective reste donc un problème de recherche de routage ouvert, et non une technique de réduction des coûts résolue.

5. Résultats des références solides : Ce qui a été prouvé

L'exécution de recherche avec références solides weighted-100 est l'artefact de preuve le plus fort du programme. Elle maintient gpt-5.5 et claude-opus-4-8 comme comparateurs de référence uniquement, exclus de chaque rôle Fusion.

Résumé uniquement Fusion sur les 100 tâches :

Métrique	Valeur
Score moyen	86.04
Coût total officiel	12.837461 $
Coût moyen officiel	0.128375 $
Coût total de la plateforme	6.568959 $
Score par dollar officiel	670.21
Appels échoués	0
Taux d'échec	0.0%
Latence moyenne d'appel	216.4s
Lignes de coûts	799
Tâches de repli agrégées	0

La valeur rapportée de 670.21 désigne le score moyen brut uniquement Fusion divisé par le coût moyen officiel uniquement Fusion, tandis que les chiffres 2.26x et 3.06x représentent des multiplicateurs de score par dollar relatifs aux références appariées calculés par rapport à des configurations de comparaison appariées.

Comparaison appariée par rapport aux deux références solides :

Référence	Score moyen de référence	Delta Fusion	IC 95 %	Victoire/Défaite/Nul	Multiple de coût Fusion	Ratio Score/$	Multiple de latence
gpt-5.5	53.43	+32.60	28.13 – 37.28	95/4/1	0.71x	2.26x	1.23x
claude-opus-4-8	40.41	+45.63	40.85 – 50.21	97/2/1	0.69x	3.06x	2.15x

La qualité et la qualité ajustée au coût sont des victoires sans ambiguïté pour Fusion sur ce manifeste. Le delta du taux d'échec de 0.0 points de pourcentage fait de la stabilité une égalité plutôt qu'un facteur de différenciation. La latence est une perte claire pour Fusion : 1.23x plus lent que gpt-5.5 et 2.15x plus lent que claude-opus-4-8. Le cadrage honnête du produit à partir de ces données est une recherche approfondie de haute qualité, efficace en termes de coûts et vérifiable, et non un chat interactif à faible latence.

La répartition par domaine montre des deltas positifs dans tous les domaines par rapport aux deux références, ce qui contredit l'idée que l'amélioration serait un artefact d'un seul domaine. Valeurs sélectionnées : contre gpt-5.5, Finance +37.13, Shopping +38.20, Recherche d'aiguille dans une botte de foin +62.56, Technologie +33.49 ; contre claude-opus-4-8, Shopping +55.96, Recherche d'aiguille dans une botte de foin +69.38, Technologie +52.43, Design UX +52.77. La finance est également le domaine qui comporte le risque non résolu le plus clair : huit avertissements de preuves de haute gravité, tous en finance, signalant finance:needs_more_sources, citant des lacunes dans les termes des métriques, les termes des périodes et l'approvisionnement de la période actuelle. Ce ne sont pas des échecs d'appel ; ce sont des avertissements de suffisance des sources, indiquant que le routage des preuves spécifiques à la finance n'est pas encore entièrement résolu, même là où le delta de score est important.

6. État de préparation : Prouvé vs. Encore bloqué

Il est important de séparer deux niveaux de statut. Il s'agit d'un résultat de preuve de recette, et non d'un résultat de système expédié, et le suivi de préparation utilisé dans tout le programme reflète explicitement cette distinction.

Passé : manifeste fixe pondéré de 100 tâches, politique de panel, secouage du routeur de preuves, preuve d'ablation du panel, preuve d'ablation du validateur/synth, la configuration de référence solide elle-même, la preuve de porte de source faible, les artefacts de recette et la preuve appariée de référence solide décrite dans la Section 5.

Pas encore passé : l'exécution finale utilisant uniquement Fusion.

L'exécution finale n'est pas une seconde comparaison par rapport aux références solides ; son objectif est différent et plus étroit : confirmer que la recette gagnante gelée se reproduit sur le même manifeste de 100 tâches sans coût de référence dans l'exécution, que la configuration d'exécution correspond à la définition de la recette, que les lignes de coûts sont complètes et qu'il n'y a pas de contamination de référence dans le chemin uniquement Fusion. Au dernier passage étagé, la couverture est de 20 tâches sur 100 notées, 20 sur 20 compatibles avec l'exécution, coût officiel uniquement Fusion de 2.619654 $, coût de référence 0 $, les 80 tâches restantes devant être exécutées dans d'autres étapes décalées.

Cette distinction est importante pour la façon dont les chiffres de l'exécution de recherche weighted-100 doivent être lus : le delta de référence solide est réel et apparié, mais il a été mesuré avec une recette qui n'a pas encore été reproduite indépendamment de bout en bout sans coût de référence dans la boucle, et il a utilisé une ancre de synthèse/validateur/juge que le chemin de coût du produit essaie délibérément de retirer.

Sur l'ancre Gemini Pro spécifiquement, la recette gelée qui a produit ces chiffres a utilisé gemini-3.1-pro-preview, un modèle Gemini Pro premium historique, comme ancre de synthèse/juge/validateur. Cette configuration établit le plafond de ce que la structure de recette et la validation basée sur des rubriques peuvent atteindre, mais ce n'est pas la configuration que le chemin de coût du produit a l'intention d'expédier. Parce que la tarification de Gemini Pro premium ne correspond pas au profil de coût cible, le prochain artefact de preuve requis est un test « canary » sans Gemini premium : une réexécution appariée à plus petite échelle substituant deepseek-v4-pro pour la synthèse/validation et glm-5.2 pour le jugement, exécutée contre les mêmes identifiants de tâches avant que toute revendication ne soit faite selon laquelle la recette efficace en termes de coûts correspond au plafond de qualité prouvé.

7. Protocole et compatibilité : Pourquoi un seul point de terminaison de chat ne suffit pas

Une recette qui ne fonctionne que contre un seul point de terminaison de chat compatible OpenAI ne survivra pas au contact avec de vrais clients d'agents de codage. Chat Completions est suffisant pour une utilisation conversationnelle simple mais abandonne la sémantique dont dépendent les clients d'agents : éléments de sortie typés, appariement appel de fonction/résultat d'outil, événements d'élément en streaming, historique avec état versus sans état et garanties de commande spécifiques au fournisseur.

Les surfaces qui comptent, et la sémantique que chacune porte, diffèrent suffisamment pour qu'elles ne puissent pas être réduites à une seule forme sans perte :

Surface	Sémantique clé qui doit être préservée
Réponses OpenAI	éléments de sortie typés, hiérarchie des instructions développeur/système, appels de fonction et sorties d'appel de fonction, previous_response_id, store, événements d'élément en streaming, comptabilité d'utilisation
Chat OpenAI	messages/outils hérités ; utilisable comme façade dégradée, mais les pertes de compatibilité doivent être enregistrées
Messages Anthropic	champ système de haut niveau, blocs de contenu, tool_use/tool_result, requêtes d'historique complet sans état, stop_reason, erreurs de flux post-200
Profil client style Codex	Réponses d'abord, store, previous_response_id, arguments d'outil en streaming, relecture des résultats d'outil, commande stricte des événements
Profil client style Claude Code	Messages Anthropic, commande immédiate tool_result, lots d'outils parallèles, disable_parallel_tool_use, listes d'autorisation de découverte de modèles

La réponse architecturale est une représentation intermédiaire canonique (IR). Les protocoles externes sont mappés dans une représentation interne de requête/réponse/flux/outil/utilisation/erreur/trace, et l'exécution de la recette et les adaptateurs de fournisseur fonctionnent contre cette IR plutôt que contre un protocole filaire unique. L'IR doit porter, au minimum : les identifiants de conversation et de tour plus les pointeurs d'état du fournisseur (previous_response_id) ; le protocole client et l'identifiant de recette publique ; la provenance et la préséance des instructions système/développeur/passerelle/recette ; les messages, blocs de contenu, images et texte dérivé ; les outils, résultats d'outils, choix d'outils et politique d'outils parallèles ; les modalités et paramètres de génération ; un enregistrement des pertes de compatibilité ; les lignes d'utilisation et les lignes de coûts séparées par rôle ; et une trace couvrant l'activité des preuves, de la recherche, des outils, des coûts et des rôles de modèles.

La justification pratique est concrète : le tool_result d'Anthropic doit immédiatement suivre son tool_use correspondant ; les sorties d'appel de fonction des Réponses OpenAI doivent être rejouées par call_id ; une façade de Chat ne peut pas préserver entièrement la priorité des messages développeur ; Claude Code envoie l'historique complet sans état à chaque tour, tandis que les clients basés sur les Réponses s'appuient sur un pointeur d'état côté fournisseur. Sans une IR et une suite de compatibilité qui exerce ces cas directement, un système peut réussir un benchmark et échouer à l'intérieur d'un vrai client d'agent parce que la boucle d'outils ne se termine jamais correctement.

L'état actuel de l'implémentation doit être énoncé précisément plutôt qu'optimistement : la couche de compatibilité existe en tant que documentation de protocole, définitions d'IR d'adaptateur, fixations de contrat de passerelle, planificateur de tour, écrivain de flux, fixations d'outils/preuves et suite de tests de compatibilité agrégés. C'est un squelette de compatibilité hors ligne, suffisant pour contraindre les formes de protocole, les lacunes de surface et empêcher la dérive précoce de la conception, mais ce n'est pas encore une passerelle de production en direct. Il n'inclut pas encore l'exécution réelle du fournisseur à grande échelle, une surface de produit de streaming orientée client, l'exécution d'outils en direct, l'authentification/tenance de production ou un backend de trace persistant. La découverte de modèles publics est conçue pour exposer uniquement des identifiants de recettes publiques nommés ; toute requête d'identifiant de modèle non public ou non nommé doit échouer (par exemple, model_not_public) plutôt que de permettre à un client de contourner les limites de recette, de coût ou de trace.

8. Modèle de contrôle de l'utilisation des outils

L'appel d'outils multi-modèle est la partie opérationnellement la plus dangereuse de toute extension d'agent de codage de ce système. Si plusieurs modèles peuvent émettre indépendamment des appels d'outils au cours du même tour, le résultat peut être des modifications de fichiers en double, des appels d'API externes en double, des frais en double, des écritures simultanées, des commandes shell conflictuelles ou l'exposition d'informations d'identification. Le modèle de contrôle adopté est délibérément restrictif :

• Un tour a, par défaut, exactement un propriétaire d'outil actif.
• D'autres modèles peuvent agir en tant que réviseur ou critique et peuvent proposer des modifications, mais ne peuvent pas exécuter d'outils.
• Le texte en forme d'outil dans la sortie d'un modèle n'est pas, en soi, une autorité d'exécution.
• Chaque appel d'outil est normalisé en une IR ToolCall canonique avant que toute décision d'exécution ne soit prise.
• Un planificateur classe chaque appel comme executable, advice_only, blocked ou requires_approval.
• Les appels en lecture seule, lecture réseau et calcul uniquement peuvent s'exécuter simultanément dans un groupe parallèle dans des conditions sûres.
• Les appels d'écriture, d'écriture shell, de paiement, d'informations d'identification et de classe destructive sont sérialisés et soumis à approbation par défaut.
• Les résultats des outils sont rejoués de manière déterministe dans la forme attendue du protocole cible.
• Le JSON partiel n'est jamais exécuté ; même un JSON bien formé doit encore passer les vérifications de schéma, d'effet secondaire, d'approbation et de propriétaire.

Il s'agit d'un écart significatif par rapport aux démonstrations multi-agents typiques, où plusieurs agents peuvent tous tenter de « résoudre » un problème simultanément. Une recette de codage orientée production nécessite une discipline de rôle sur la sécurité de l'exécution : un réviseur peut signaler qu'un correctif proposé cassera une suite de tests, mais ne peut pas lui-même exécuter une commande shell destructive. Un propriétaire d'outil peut initier une modification de fichier ou une commande shell, mais sa sortie est toujours vérifiée par la passerelle avant l'exécution.

Cela contraint également la façon dont les étiquettes de capacité d'outil de la bibliothèque de modèles doivent être lues : une étiquette « tool-use » signifie qu'un modèle peut plausiblement exprimer un appel d'outil, pas qu'il est autorisé à être un propriétaire d'outil de production. La promotion au statut de propriétaire nécessite de réussir une suite de compatibilité couvrant les arguments d'outils en streaming, la stabilité de l'identifiant d'outil, la réparation de JSON mal formé, la relecture des résultats d'outils, la politique d'outils parallèles, la comptabilité d'utilisation et la forme d'erreur. Un cas limite connexe est le « sauvetage » d'outil en ligne : certains fournisseurs émettent des appels d'outils sous forme de texte assistant (blocs XML/JSON, balises de fonction privées, arguments objet ou doublement encodés). La couche d'adaptateur peut détecter et réparer ces dialectes, mais la réparation ne produit qu'une IR ToolCall candidate ; elle n'accorde pas l'autorité d'exécution, elle est limitée au texte de réponse du propriétaire actuel uniquement (jamais au texte utilisateur, aux résultats d'outils, aux notes du réviseur ou à la réponse fusionnée finale), et un appel réparé doit encore franchir les portes de propriétaire, schéma, effet secondaire, approbation, parallélisme et idempotence. Un JSON mal formé répété devrait échouer au contrôle de compatibilité de ce propriétaire pour le tour plutôt que d'être exécuté silencieusement.

9. Vision et recherche Web : Équité vs. Expérience produit

Les chemins d'évaluation et de produit divergent intentionnellement ici. La preuve de benchmark utilise des preuves partagées et reproductibles ; les requêtes de production peuvent utiliser la recherche native ou la vision, mais seulement lorsqu'elles sont traçables.

La recherche est traitée via trois chemins distincts : shared_evidence (un pack de recherche/récupération/lecture externe appartenant à Fusion, reproductible, obligatoire pour les exécutions de preuve de la suite de recherche weighted-100, les comparaisons avec des références solides, les tests « canary » de mise à niveau de modèles et les exécutions finales), native_search (la propre capacité de recherche/navigation/ancrage Web d'un modèle ou d'un fournisseur), et external_search (outils externes traçables tels que la récupération, la lecture par navigateur ou l'extraction de documents). La recherche native n'est pas interdite ; elle peut améliorer l'expérience produit, mais elle ne peut pas soutenir une revendication de benchmark équitable, car si le comportement de recherche, les sources récupérées et la piste de citation d'un modèle sont opaques, la comparaison cesse d'être une comparaison sur la même tâche.

La vision suit la même logique. La vision native et le texte OCR/légende dérivé ne sont pas des entrées équivalentes, et une comparaison entre des modèles avec une visibilité différente sur une image n'est pas une comparaison de vision équitable. La trace enregistre explicitement la visibilité de chaque modèle comme native_image, derived_text ou none. Le modèle de production recommandé est un hybride : les modèles primaires peuvent utiliser la vision native tandis que les réviseurs à moindre coût travaillent à partir de texte dérivé ; les tâches de faits actuels utilisent par défaut la recherche/récupération externe, et la recherche native n'est autorisée qu'une fois qu'un itinéraire a réussi une sonde de capacité et produit une trace complète. L'évaluation, cependant, utilise toujours par défaut des preuves partagées et un bundle de preuves haché.

10. Bibliothèque de modèles comme schéma de sélection conscient des rôles

Le catalogue de modèles sous-jacent à TokenLab Fusion est passé d'une table de capacités plate à un schéma de sélection en couches avec des champs pour le niveau de coût, les rôles Fusion, les étiquettes de capacité, les métriques de sélection, le profil de routage et la piste d'évaluation recommandée. Cela reflète une réalité produit qu'un seul classement « à quel point ce modèle est fort » ne capture pas : un modèle peut être un excellent réviseur de codage et un piètre panéliste de recherche à faible latence ; un modèle peut être peu coûteux mais avoir des identifiants d'appel d'outils instables ; un modèle peut porter une étiquette de capacité de vision native sans avoir encore de preuves de trace suffisantes pour une évaluation soumise à l'équité.

Couche	Rôle représentatif	Signification produit
Bon marché toujours actif	candidats panel/réviseur/juge à faible coût	Composition du panel par défaut, promu uniquement via des preuves « canary » appariées
Mise à niveau de raisonnement solide	escalade de tâches difficiles	Rôle de synth/validateur/juge pour les tâches difficiles
Spécialiste codage/agent	boucle d'outils, échelle de dépôt, révision front-end	Candidats propriétaire d'outil et réviseur d'agent de codage
Spécialiste vision/recherche	flux de travail produit lourds en image/recherche	Nécessite une sonde de trace avant utilisation soumise à l'équité
Retenu contexte ultra-long	diagnostics de dépôt/bundle de preuves énorme	Pas un membre du panel par défaut
Comparateur boîte noire	systèmes multi-agents côté fournisseur	Point de référence uniquement ; l'attribution Fusion interne ne peut pas en être dérivée

Le jugement actuel sur l'ancre premium retirée mérite une déclaration explicite : le modèle Gemini Pro premium historique qui a ancré la preuve weighted-100 a été retiré de la planification de recette de coût de produit active, et un modèle de niveau Gemini flash à prix réduit a également été supprimé du plan par défaut en raison d'une tarification de sortie qui ne correspond pas au profil de coût de recette cible. Cela ne révise pas le résultat de l'exécution de recherche weighted-100, cette preuve tient telle qu'enregistrée, mais cela signifie que la preuve et la recette d'expédition prévue ne sont pas actuellement le même système, ce qui est précisément la raison pour laquelle le test « canary » sans Gemini premium est la prochaine étape de preuve requise, et non une étape optionnelle.

11. Portes de mise à niveau de la bibliothèque de modèles

Une préoccupation opérationnelle récurrente est de savoir si chaque changement de modèle nécessite une réexécution complète de 100 tâches. La réponse adoptée par le programme est un gating en couches, proportionnel au risque, plutôt que l'un ou l'autre extrême (réexécutions complètes aveugles à chaque changement, ou substitution aveugle de la même famille sans preuve) :

1. Fumée de contrat : confirmer l'itinéraire, la tarification, le streaming, la fenêtre de contexte, les limites de sortie, la modalité et les étiquettes outil/recherche/vision.
2. Suite de compatibilité : exercer Chat OpenAI, Réponses OpenAI, Messages Anthropic, appel d'outil, résultat d'outil, outil parallèle, utilisation, erreur et gestion de flux.
3. Évaluation sentinelle : exécuter un petit ensemble spécifique au domaine correspondant au rôle revendiqué du modèle (par exemple, suffisance des sources financières, boucle d'outils de codage, révision visuelle front-end).
4. Canary apparié : comparer par rapport à la recette actuelle sur des identifiants de tâches identiques pour la qualité, le coût, la latence et le taux d'échec.
5. Exécution complète de 100 tâches : réservée aux candidats qui pourraient changer la recette par défaut ou une revendication de référence solide.

Même une mise à niveau apparemment mineure de la même famille nécessite de passer par cet entonnoir : la tarification, le comportement des appels d'outils, le streaming et la qualité appariée nécessitent tous une confirmation indépendante plutôt que d'être déduits d'un nom de famille de modèle partagé. C'est aussi pourquoi le manifeste de 100 tâches n'est pas exécuté en continu ; il est réservé à la confirmation finale, tandis que les changements de modèles au jour le jour sont régis par les portes moins chères et plus rapides ci-dessus.

12. Travaux connexes et ce qui est (et n'est pas) réutilisé

Le programme s'appuie sur plusieurs directions de recherche publique et d'outillage sans adopter leurs objectifs en gros. Mixture-of-Agents motive l'idée que les sorties de modèles plus faibles peuvent encore utilement conditionner un synthétiseur plus fort, mais les conclusions sur le gonflement du panel dans la Section 4 mettent en garde contre la superposition sans ablation. LLM-Blender contribue à la structure de génération de candidats, classement par paires, fusion générative que les étapes panel/juge/synthèse ressemblent, bien qu'aucun classeur entraîné dédié ne remplace actuellement le juge basé sur des rubriques. FrugalGPT et RouteLLM motivent le cascading et le routage conscients des coûts, mais le problème de routage ici est multi-rôle (panel, synthèse, juge, validateur, stratégie de recherche, propriétaire d'outil peuvent chacun router indépendamment), pas un choix de modèle binaire unique. L'outillage de harnais d'évaluation tel que Inspect AI, OpenAI Evals, Promptfoo et Ragas informent le modèle d'ingénierie d'une boucle d'évaluation systématique et conviviale pour l'IC, mais aucun d'entre eux ne se substitue au manifeste pondéré fixe, aux vérifications de suffisance des sources, aux lignes de coûts séparées par rôle ou à la structure de preuve appariée pondérée par domaine utilisée ici.

13. Limitations

Limitation	État actuel	Pourquoi c'est important
Dépendance à l'ancre premium	La preuve weighted-100 a utilisé un modèle Gemini Pro premium historique comme synth/juge/validateur	Prouve le plafond de la recette, pas la recette de coût de produit prévue
Réexécution finale incomplète	Réexécution uniquement Fusion à 20/100 tâches, 20/20 compatible avec l'exécution	La reproductibilité sans coût de référence n'est pas encore entièrement confirmée
Pas de données d'audit humain ou d'accord inter-évaluateurs public	Les résultats d'audit humain et d'accord inter-évaluateurs n'ont pas encore été publiés ou rendus publiquement disponibles pour ce pipeline d'évaluation	La fiabilité et la cohérence des scores automatisés par rapport au jugement humain restent invérifiées, limitant la confiance dans l'interprétation absolue des scores
Désavantage de latence	1.23x vs. gpt-5.5, 2.15x vs. claude-opus-4-8	Peut être acceptable pour la recherche approfondie, probablement inacceptable pour les agents de codage interactifs
Validateur conscient des rubriques	Le validateur voit la rubrique/liste de contrôle de notation	Les comparaisons doivent divulguer cela ; non directement comparable aux systèmes aveugles aux rubriques
Avertissements de sources financières	8 avertissements de haute gravité finance:needs_more_sources	La suffisance des sources en finance est non résolue malgré des deltas de score importants
Inférence de capacité native	Les étiquettes de capacité de recherche/vision ne sont pas une preuve de support de trace de qualité production	Nécessite un sondage par itinéraire avant toute utilisation d'évaluation soumise à l'équité
Maturité de la couche de compatibilité	Squelette hors ligne (IR, fixations, contrat de routeur, planificateur, écrivain de flux)	Pas encore une passerelle de production en direct avec exécution réelle du fournisseur, auth/tenance ou stockage de trace persistant
Volatilité des prix/itinéraires	La correction de prix de DeepSeek V4 Pro a déjà changé une décision stratégique	Le niveau de la bibliothèque de modèles doit être revérifié à mesure que les prix et le comportement des itinéraires changent

14. FAQ

Le résultat de 100 tâches signifie-t-il que TokenLab Fusion bat GPT-5.5 et Claude Opus 4.8 en général ?

Le résultat apparié tient spécifiquement sur le manifeste de recherche fixe weighted-100, en utilisant des preuves partagées et une comptabilité des coûts séparée par rôle, avec gpt-5.5 et claude-opus-4-8 tenus à l'écart du panel Fusion. C'est une preuve solide et large en termes de domaine dans ce cadre, et non une revendication générale indépendante du type de tâche, des conditions de preuve ou de la composition du manifeste.

Pourquoi l'ancre Gemini Pro compte-t-elle si le delta de score est déjà important ?

Le delta a été produit par une recette utilisant un modèle Gemini Pro premium historique pour la synthèse, le jugement et la validation. Cette configuration établit ce que la structure de recette peut atteindre, mais ce n'est pas le profil de coût que le chemin de produit a l'intention d'expédier. Jusqu'à ce qu'une configuration sans Gemini premium soit exécutée comme un test « canary » apparié contre les mêmes identifiants de tâches, la qualité atteinte et le coût d'expédition prévu sont prouvés séparément, et non ensemble.

Un coût par appel plus bas est-il la même chose qu'un coût plus bas par unité de qualité ?

Non, et les deux sont rapportés séparément pour cette raison. Les multiplicateurs de coût 0.71x et 0.69x décrivent le coût brut par rapport aux deux références ; les ratios score par dollar 2.26x et 3.06x décrivent la qualité ajustée au coût. Les deux sont nécessaires, car un système peut être moins cher par appel et quand même obtenir un moins bon score, ou plus cher par appel et quand même être plus efficace en termes de coûts par unité de qualité ; cette évaluation rapporte les deux explicitement plutôt que de les effondrer.

Pourquoi l'ablation du validateur compte-t-elle pour ce résultat ?

L'étape de validateur/réécriture basée sur des rubriques a produit le plus grand changement de qualité mesuré dans ce programme (delta apparié +51.81 sur une expansion de 20 tâches), à environ 2.14x le coût et 1.89x la latence par rapport au témoin cœur rapide. Toute comparaison entre des recettes, ou entre Fusion et une référence, doit divulguer si l'étape de validation est active, car elle change à la fois le profil de coût et le cadrage de l'équité (le validateur a une visibilité sur les rubriques de notation).

TokenLab Fusion est-il prêt à fonctionner à l'intérieur d'un vrai client d'agent de codage aujourd'hui ?

Non. L'architecture de contrôle du protocole et de l'utilisation des outils (IR canonique, suite de compatibilité, modèle de propriétaire d'outil) existe en tant que squelette de compatibilité hors ligne avec des mappages de protocole et des fixations documentés, mais elle n'inclut pas encore une passerelle de production en direct, une exécution réelle du fournisseur à grande échelle, une authentification/tenance ou un stockage de trace persistant. La preuve Deep Research et la gamme Coding Agent sont évaluées sur des chronologies différentes, et la gamme de codage n'a pas encore terminé sa première phase de validation sur petit échantillon.

15. Clôture de la recherche

Ce qui est prouvé

Sur un manifeste multi-domaines fixe, haché et pondéré de 100 tâches, en utilisant des preuves partagées et une comptabilité des coûts séparée par rôle, une recette multi-modèle équipée d'un validateur a atteint un delta de score moyen apparié de +32.60 par rapport à gpt-5.5 et +45.63 par rapport à claude-opus-4-8, à 0.71x et 0.69x le coût respectivement, avec zéro échec d'appel sur 799 lignes de coûts. La validation basée sur des rubriques est confirmée comme le plus grand levier de qualité unique testé, avec un delta apparié de +51.81 par rapport à un témoin cœur rapide. Les deltas positifs tiennent dans tous les domaines du manifeste par rapport aux deux références, indiquant que le gain n'est pas concentré dans un seul type de tâche.

Ce qui reste bloqué

La réexécution finale uniquement Fusion de la recette gagnante gelée est incomplète (20 tâches sur 100 au dernier contrôle) et doit atteindre une couverture complète avec un audit de préparation propre avant que la preuve puisse être appelée reproductible de bout en bout. La recette qui a produit la preuve dépend d'une ancre Gemini Pro premium historique que le chemin de coût du produit a l'intention de retirer ; aucune preuve appariée n'existe encore pour la substitution sans Gemini premium prévue. La latence reste un compromis produit non résolu, particulièrement pour toute application d'agent de codage. La suffisance des sources financières comporte huit avertissements de haute gravité non résolus malgré un avantage de score important dans ce domaine. La couche de compatibilité de protocole est définie architecturalement mais n'est pas encore une passerelle de production en cours d'exécution.

Quelles preuves devraient être collectées ensuite

Terminer la réexécution finale uniquement Fusion sur les 80 tâches restantes et réexécuter l'audit de préparation pour confirmer la reproductibilité sans coût de référence dans la boucle. Exécuter un test « canary » apparié, avec le même identifiant de tâche, substituant deepseek-v4-pro pour la synthèse/validation et glm-5.2 pour le jugement à la place de l'ancre Gemini Pro premium, en commençant à petite échelle avant toute revendication sur manifeste complet. Fermer les huit avertissements de suffisance des preuves financières en suspens avec un travail de porte de source spécifique au domaine avant de traiter le résultat du domaine financier comme entièrement résolu. Étendre la suite de compatibilité d'un squelette hors ligne vers l'exécution réelle du fournisseur, et exécuter une phase de validation d'agent de codage sur petit échantillon (de l'ordre de cinq tâches) pour tester si l'architecture propriétaire d'outil/réviseur produit un avantage mesurable de panel par rapport au modèle unique avant d'investir davantage dans l'infrastructure d'agent de codage. Chacune de ces étapes est une expérience suivante spécifique et falsifiable, et non un élément de feuille de route général.