Manifest, l’entreprise derrière une passerelle LLM open source avec 7 000 utilisateurs cloud, a déprécié son routeur de modèles après quatre mois d’utilisation réelle. Le routeur classait chaque demande en quatre niveaux de complexité et l’acheminait vers le modèle le plus économique approprié. Les problèmes détectés : la complexité d’une tâche ne se déduit pas du prompt initial, elle émerge souvent seulement après les premiers appels aux outils ; le cache sur les tokens initiaux économise plus que le routage ; et changer de modèle en cours de session dégrade la qualité du travail.

Le même jour, le projet qm a récolté 538 points sur Hacker News. C’est un harness multi-agent où chaque collaborateur a un workspace isolé, les agents collaborent dans des canaux Slack, et le modèle, tu le choisis. Pi, OpenCode, Codex, Claude Code : tous pilotent le même core, et le passage entre l’un et l’autre est manuel.

Pour qui construit des agents, la question pratique change. Le débat sur quel modèle utiliser laisse place à comment orchestrer qui fait quoi. Comme nous l’expliquions le 20 juillet, l’architecture compte plus que le modèle seul : à présent, ceux qui avaient construit le routeur et l’ont démonté le confirment.

Si tu veux explorer, le repo de qm est public sur GitHub.

En détail

Ce qui existait avant.

Les routeurs LLM promettaient de résoudre un problème réel : les modèles puissants coûtent cher, et les utiliser pour des tâches simples c’est du gaspillage. L’idée était de classifier chaque demande par complexité et l’envoyer au modèle le plus économique capable de la gérer. Manifest a lancé son routeur en mars, en classant quatre niveaux : simple, standard, complex, reasoning. Après quatre mois sur 7 000 utilisateurs, ils l’ont déprécié en juin et le fermeront le 1er septembre.

Pourquoi le routage automatique ne tient pas.

Le premier problème c’est que le prompt initial ne contient pas l’information nécessaire. « Évalue les tests de ce repo et améliore-les » peut être une tâche de cinq minutes sur un site HTML ou une entreprise titanesque sur le kernel Linux. La complexité émerge pendant le travail, quand l’agent a déjà commencé à appeler des outils et faire des recherches. Un routeur qui décide avant de savoir ce que la tâche exige part avec une information insuffisante.

Le deuxième problème est économique, mais contre-intuitif. Le cache sur les tokens initiaux (system prompt, historique de conversation) coûte entre 75 % et 90 % moins cher qu’un input non mis en cache. Si un routeur change de modèle à chaque demande, il perd le bénéfice du cache. S’il le maintient fixe pour ne pas le perdre, il arrête de faire son travail. Manifest l’écrit explicitement : le routeur finit par ne pas router, ironiquement, pour économiser.

Le troisième point concerne la qualité du travail. Changer de modèle en cours de session casse la cohérence du comportement. Manifest soutient que les ingénieurs devraient connaître leurs modèles comme un menuisier connaît ses outils : choisir en fonction de l’intention, pas déléguer le choix à un classificateur.

Ce que qm fait différemment.

qm part d’une assomption opposée : l’orchestration est explicite. Chaque collaborateur a un workspace isolé avec sa mémoire, ses fichiers, ses permissions, ses crons. Les agents collaborent dans des canaux Slack partagés, mais chacun avec son scope. Le modèle et le harness (Pi, OpenCode, Codex, Claude Code) les choisit l’utilisateur ou l’administrateur, pas un routeur.

L’architecture a trois niveaux : un core headless avec API, identité et scheduler ; une boucle agent qui peut tourner sur des harnesses différents ; et une couche de présentation sur Slack et web. Les skills sont scope-owned et partageables, avec promotion validée par admin à toute l’organisation. Le projet est ouvert et a 3 000 stars sur GitHub.

Limites.

qm est un jeune projet : 40 commits, 10 issues ouvertes, 27 pull requests. La documentation est présente mais peu étendue, et il n’y a pas de cas d’usage documentés au-delà du README. Manifest parle pour 7 000 utilisateurs réels en quatre mois, qm parle pour un repo en ascension sur Hacker News. Le pattern est intéressant, mais la validation en production reste à démontrer.

Les deux signaux, pris ensemble, disent quelque chose de plus solide que les projets individuels. La question sur quel modèle utiliser a un horizon limité : les modèles changent, les prix baissent, les différences s’amenuisent. La question sur comment orchestrer s’enrichit chaque semaine, avec le pattern swarm de Cursor qui converge dans la même direction : planificateur puissant qui décide, exécuteur économique qui travaille, modèle choisi pour son rôle et non pour la demande.