> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/fr/2026/w30-model-harness-an-intelligent-routing-vision.md).

# W30-Modèle × Harness : une idée de routage intelligent

J'ai récemment lu [l'évaluation des agents de programmation sur les millions de lignes de code de Databricks](https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase).

L'article construit des tâches à partir de PR internes déjà fusionnées, puis compare modèles et harness d'agents sur ce véritable dépôt. Sa conclusion la plus frappante est que le harness change fortement les résultats ; le classement des modèles importe moins.

Databricks exécute les tâches avec un même modèle et un même effort de raisonnement, à travers Claude Code, Codex, Pi et d'autres harness. Dans certaines comparaisons, la qualité reste presque identique, mais les coûts varient de plus du simple au double. Pi envoie environ trois fois moins de contexte par tour et termine avec un ensemble de travail plus petit et moins de tours.

Cela montre que nous posons souvent la mauvaise question.

Nous demandons quel modèle code le mieux. L'unité réelle d'exécution est désormais une configuration :

> model × harness × thinking effort × tools × policy

Le harness est l'environnement qui porte la boucle de l'agent. Le modèle fixe le plafond des capacités ; le harness détermine comment il comprend le dépôt, gère le contexte, appelle les outils, vérifie et s'arrête. Le résultat vient de toute la configuration.

### Un service de routage des configurations

Cette lecture m'a donné l'idée d'un service qui :

1. évalue continuellement les nouvelles combinaisons modèle × harness ;
2. reconnaît le type, la complexité et le risque des tâches entrantes ;
3. les dirige automatiquement vers une configuration optimale au sens de Pareto, sous contraintes de qualité, coût, latence et risque.

Il entretient une carte conditionnelle des performances qui évolue dans le temps, plutôt qu'un classement fixe :

> Pour ce type de tâche, dans ce dépôt et avec ces contraintes, quelle configuration convient le mieux ?

A peut être idéale pour modifier un feature flag, B pour une refonte entre modules, C n'améliorer le succès que de quelques points en coûtant cinq fois plus. Il n'existe pas de champion global, seulement des optimums locaux selon les distributions de tâches.

À l'arrivée, le routeur extrait des caractéristiques : langages et dossiers concernés, ampleur estimée, existence de tests explicites, quantité de recherche de code, réversibilité et risque des permissions. Il choisit ensuite sur la frontière de Pareto actuelle. Après exécution, tests, reprises humaines, tokens, durée et traces d'outils retournent dans le système d'évaluation.

La boucle devient :

> Tâches privées → évaluation des combinaisons → reconnaissance de la tâche → routage de configuration → résultats réels → mise à jour de l'évaluation

### Trois pièces existent déjà

D'autres s'approchent de cette direction, mais les produits actuels s'arrêtent à des couches différentes.

La première catégorie est celle des routeurs de modèles.

[Not Diamond](https://docs.notdiamond.ai/docs/key-concepts) analyse l'entrée et optimise entre modèles selon qualité, coût ou latence. [OpenRouter Auto Router](https://openrouter.ai/docs/guides/routing/routers/auto-router) choisit aussi selon le type et la complexité. Not Diamond permet d'entraîner un routeur avec ses propres évaluations et a annoncé Code Router pour les agents de programmation.

Leur objet natif reste surtout le modèle. Not Diamond peut envelopper un modèle personnalisé ou un workflow agentique comme point d'accès candidat. Un routage de combinaisons est donc techniquement possible, mais le harness n'est pas encore une dimension autonome, observable et continuellement évaluée.

OpenRouter dépasse également la passerelle ordinaire. Pareto Code Router actualise ses niveaux de qualité selon des benchmarks externes de programmation. Auto Exacto ajuste l'ordre des fournisseurs selon le débit réel, le succès des appels d'outils et les évaluations internes. Ils montrent que les évaluations et signaux de production peuvent guider le routage, mais ne connaissent pas encore le dépôt et le harness propres au client.

La deuxième catégorie est celle des plateformes d'évaluation et d'observabilité.

[Braintrust](https://www.braintrust.dev/articles/best-llm-routers-2026) réunit publiquement passerelle, expériences, notation en ligne, traces de production et routage dans un même workflow. Une équipe compare les modèles sur le trafic réel, puis ajuste sa politique selon exactitude, coût et latence.

C'est proche d'un routage guidé par l'évaluation continue. Mais son récit produit reste centré sur les modèles et leurs points d'accès. Faire influencer une décision par les évaluations ne signifie pas encore actualiser automatiquement une politique dans l'espace modèle × harness.

La troisième catégorie est la couche de contrôle des harness.

[Omnigent](https://omnigent.ai/docs/build/harnesses) propose une couche commune à Claude Code, Codex, Cursor, Pi et d'autres. À modèle, outils et politique identiques, une ligne de configuration suffit à changer de harness. Modèle et harness peuvent aussi être remplacés séparément à l'exécution. Des hooks limitent déjà l'usage des modèles coûteux selon la complexité ; la v0.5.0 de juillet 2026 ajoute un juge de routage qui choisit le modèle par tâche.

Omnigent est donc le plus proche de cette idée. Il rend les harness interchangeables, composables et gouvernables. Databricks possède en parallèle les tâches tirées de PR et les appels réels collectés par Unity AI Gateway. La fin de l'article annonce d'ailleurs une présentation ultérieure du routage intelligent dans Unity AI Gateway et Omnigent.

Cependant, l'implémentation publique d'Omnigent choisit encore le modèle à l'intérieur d'un harness déjà fixé. Aucun document public ne montre un choix automatique par tâche entre Claude Code, Codex et Pi, encore moins son actualisation continue par des benchmarks de PR. Nous avons évaluation de combinaisons, abstraction des harness, reconnaissance de complexité, routage de modèles et passerelle. Je n'ai pas encore vu de service indépendant ouvert au public qui transforme directement l'évaluation continue des tâches privées d'une entreprise en routage automatique du modèle et du harness.

Il reste de la place, mais moins qu'il n'y paraissait au début.

### La vraie difficulté est l'évaluation

L'algorithme de routage n'est pas nécessairement la barrière centrale. Il faut surtout obtenir continuellement des comparaisons fiables.

#### 1. L'évaluation doit appartenir au dépôt concret

Un benchmark public fournit un a priori, pas la décision finale de l'entreprise.

Databricks n'a pas utilisé directement SWE-bench. Les problèmes publics peuvent avoir été vus pendant l'entraînement et ne représentent pas son dépôt mêlant Scala, Go, Rust, Java, Python, Bazel et Protobuf. L'équipe extrait des tâches de PR humaines récentes, cache l'implémentation d'origine et vérifie les résultats avec les tests existants.

Un routeur utile ne peut donc vendre uniquement un classement sectoriel. Il doit produire une carte privée sur le code, les tests, les conventions et les tâches de chaque entreprise.

#### 2. L'espace des combinaisons explose vite

Dix modèles, cinq harness et trois efforts de raisonnement donnent déjà cent cinquante configurations. Avec les outils, politiques de contexte et permissions, l'exhaustivité devient vite impossible.

Il faut évaluer par étapes : éliminer les options nettement dominées sur un petit échantillon, puis investir près de la frontière de Pareto. Un nouveau modèle ou harness est sondé sur quelques tâches pour estimer son niveau. Cela ressemble davantage au plan d'expériences et aux bandits contextuels qu'à un classement.

#### 3. La complexité n'est pas une étiquette du prompt

Une modification apparemment simple peut devenir risquée à cause de la propriété du code, des dépendances ou de l'absence de tests. La complexité change aussi pendant le travail : un fichier semblait suffire, puis il faut revoir un protocole et migrer des données.

Classer une seule fois à l'entrée ne suffit pas. Le routeur doit lire les métadonnées du dépôt et permettre une montée en capacité pendant l'exécution. Un modèle peu coûteux explore, puis passe à un modèle plus fort quand les effets traversent les modules. Un harness léger localise, puis laisse la longue modification à un harness qui gère mieux le contexte.

Une nouvelle question apparaît : comment conserver l'état utile pendant ce passage sans emporter le bruit de contexte de l'ancien harness ?

#### 4. La meilleure stratégie paie un coût d'exploration

Envoyer toutes les tâches au champion actuel prive vite le système de comparaisons. Les conclusions vieillissent après une nouvelle version, un changement de prix ou de harness.

Le routage continu doit donc garder une petite part d'exploration, avec tâches pilotes ou rejeu hors ligne. Il doit distinguer les causes d'échec : modèle insuffisant, mauvaise gestion du contexte, outil indisponible ou tests instables. Les fondre dans une note globale ne suffit pas.

Relancer périodiquement les benchmarks n'est qu'une partie du travail. Il faut garder les données fraîches, attribuer les échecs et maîtriser le risque d'exploration.

### Où se trouve l'avantage défensif ?

Passerelles et API communes se banalisent facilement. Trois types de données offrent davantage de valeur durable.

D'abord, la distribution propre des tâches : fréquence, coût, pertes réelles en cas d'échec.

Ensuite, les traces des combinaisons : comment un même modèle lit le contexte, appelle les outils, consomme les tokens et corrige ses erreurs avec différents harness.

Enfin, le résultat : tests réussis, PR acceptée, reprises humaines, éventuel retour arrière en production.

Les relier permet de comprendre ce que signifient réellement bon marché et efficace. On optimise le coût total d'une tâche jusqu'à son acceptation. Le tarif d'un appel d'API n'en est qu'un élément.

Cela crée un cercle d'apprentissage. Plus le système est utilisé, mieux il comprend le dépôt et les habitudes. Plus le routage est précis, plus l'équipe lui confie de tâches. Les résultats supplémentaires améliorent encore le routage. Modèles et harness restent remplaçables ; les évaluations et l'historique des décisions demeurent dans la couche de contrôle.

### Un point de départ plus réaliste

La première version ne devrait pas absorber tout le trafic des agents. Une voie plus prudente commence par une aide à la décision hors ligne :

1. connecter dépôt et PR récemment fusionnées ;
2. générer automatiquement un ensemble privé de tâches vérifiables ;
3. rejouer régulièrement quelques combinaisons ;
4. produire une frontière coût-qualité par type de tâche ;
5. recommander d'abord, puis automatiser les tâches peu risquées ;
6. calibrer le classificateur et les évaluations avec les résultats réels.

On prouve ainsi deux choses : des différences stables existent entre combinaisons, et les économies dépassent le coût d'évaluation.

Sinon, le routage ajoute seulement de la complexité. Si elles se vérifient, l'outil de recommandation peut progressivement devenir un plan de contrôle.

### Mon jugement

Le besoin est réel. Les modèles se multiplient, les différences de harness affectent directement coût et qualité, mais les entreprises fixent encore souvent un modèle et un agent par défaut pour tout. Cette configuration statique gaspille probablement du calcul et place certaines tâches au mauvais niveau de capacité.

Databricks est aujourd'hui le plus proche de la boucle complète : Omnigent abstrait les harness, Unity AI Gateway unifie l'entrée et collecte les appels, les PR internes fournissent les évaluations privées. La prochaine étape annoncée pourrait précisément relier évaluation et routage.

L'occasion pour une entreprise indépendante n'est pas de produire vite un classement plus grand. Elle est de créer une couche de contrôle neutre vis-à-vis des fournisseurs, qui évalue continuellement les tâches de chaque entreprise, route aussi les harness et explique ses arbitrages entre qualité, coût, latence et risque.

La fenêtre existe, mais ne restera pas vide. Not Diamond peut s'étendre aux workflows agentiques, Braintrust automatiser davantage le lien entre évaluation et passerelle, Databricks commercialiser ses outils internes. Un nouvel acteur doit vite prouver une chose précise :

> Sur de vrais dépôts d'entreprise, router les configurations coûte moins cher qu'utiliser systématiquement le modèle le plus puissant avec le harness par défaut, sans réduire la qualité finale de livraison.

Si cela est démontré durablement, l'unité de concurrence des agents remontera encore. Modèle et harness resteront importants, mais davantage de valeur ira au système qui choisit continuellement leur meilleure combinaison.

### Références

* [Évaluation des agents sur le dépôt de plusieurs millions de lignes de Databricks](https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase)
* [Omnigent : harness](https://omnigent.ai/docs/build/harnesses)
* [Omnigent : politiques intégrées](https://omnigent.ai/docs/policies/builtin)
* [Omnigent v0.5.0](https://omnigent.ai/releases/0.5.0)
* [Databricks : Unity AI Gateway](https://docs.databricks.com/aws/en/ai-gateway)
* [Not Diamond : concepts clés](https://docs.notdiamond.ai/docs/key-concepts)
* [Not Diamond : entraîner un routeur personnalisé](https://docs.notdiamond.ai/docs/router-training-quickstart)
* [OpenRouter : Auto Router](https://openrouter.ai/docs/guides/routing/routers/auto-router)
* [OpenRouter : Pareto Router](https://openrouter.ai/docs/guides/routing/routers/pareto-router)
* [OpenRouter : Auto Exacto](https://openrouter.ai/docs/guides/routing/auto-exacto)
* [Braintrust : meilleurs routeurs LLM et plateformes de routage en 2026](https://www.braintrust.dev/articles/best-llm-routers-2026)