Jeff-Code place un modèle de 0,8B dans la boucle pour accélérer de 47% un codeur de 27B

Le 5 octobre, la page GitHub du projet a été mise en ligne avec une revendication précise. Jeff-Code fait tourner un modèle de décision de 0,8B, nommé Jeff, dans la boucle de l'agent Pi, l'agent de codage de Mario Zechner et de ses contributeurs. Jeff prend deux décisions rapides autour de chaque tour de Qwen, environ 0,2 seconde chacune. Faut-il exécuter l'étape suivante soi-même, et Qwen doit-il réfléchir longuement sur ce tour.

Sur 1 242 tâches appariées, le taux de réussite atteint 62,4% pour Jeff-Code contre 62,8% pour Qwen 3.8-27B seul. L'écart apparié est de moins 0,2 point, avec un intervalle à 95% de moins 2,6 à plus 2,1. Le temps moyen par tâche tombe à 0,68 fois, intervalle de 0,64 à 0,72, et la médiane à 0,70 fois. C'est de là que vient le chiffre de 47% : 32% de temps en moins, en moyenne.

Voilà la forme de l'IA embarquée qui arrive réellement sur le marché en 2 026. Le petit modèle n'écrit pas le code, et personne ne prétend le contraire. Il décide ce qu'on peut sauter.

Le même schéma apparaît chez d1 de Liquid AI, un modèle de décision qui renvoie des probabilités au lieu de générer des tokens, et chez Reika, une interface en ligne de commande pour agents de codage construite autour de modèles de 8 000 000 000 à 35 000 000 000 de paramètres en Q2 à Q4 sur une fenêtre de 32 000 à 32 000 tokens. Pour les utilisateurs, la question pratique n'est plus de savoir si un petit modèle est assez intelligent, mais s'il est assez bon marché pour rester allumé. Ni Jeff-Code ni Liquid n'ont dit comment ces systèmes se comportent sur du matériel plus lent qu'un GPU de station de travail.

Ce que le harnais peut corriger et ce qu'il ne peut pas

La documentation de Reika défend sa cause par des mesures plutôt que par des adjectifs. Le projet rapporte qu'une réécriture de contexte en milieu de session a retraité 8 453 tokens de prompt, ce qui a coûté 7,9 minutes de préremplissage, là où un ajout dans la même session coûtait 25 tokens et 3,5 secondes. Il constate aussi que la formulation du prompt est le levier le plus faible dont il dispose. Sur une tâche vague en Q2, un modèle converge ou part en vrille à peu près une fois sur deux, et le harnais ne peut pas changer ce taux. Il peut seulement changer ce que coûte la moitié qui échoue.

Les résultats de test sont peu flatteurs, et c'est voulu. La page indique que les modèles de 14 000 000 000 à 35 000 000 000 de paramètres traitent le plus fiablement les tâches multi-fichiers, que ceux de 8 000 000 000 à 9 000 000 000 de paramètres s'en sortent sur des tâches simples et bien délimitées, et que tout ce qui descend sous 7 000 000 000 de paramètres va rarement loin. La démo principale fait tourner Qwen3.6 35 000 000 000 de paramètres en Unsloth UD-IQ2_M via llama.cpp, accéléré trois fois, et le premier test du modèle échoue avant qu'il ne le corrige à partir de l'erreur. Reika est en pré-1.0, donc les commandes et le comportement peuvent encore changer d'une version à l'autre.

Les chiffres de Jeff-Code montrent la même honnêteté sur l'endroit où les gains s'arrêtent. Le temps total écoulé pour l'ensemble des tâches baisse moins que le temps par tâche, à 0,86 fois avec un intervalle de 0,80 à 0,93, parce que sur environ 5% des tâches Jeff-Code tourne plus de 30 minutes de plus que Qwen seul. La répartition par benchmark est inégale elle aussi : 0,63 fois sur SWE-bench Verified et 0,64 fois sur Terminal-Bench Pro, mais aucune accélération nette sur Terminal-Bench 2.0 à 0,96 fois ni sur SkillsBench à 0,91 fois.

Puis la partie qui compte pour quiconque serait tenté de copier l'astuce. Tourner avec la réflexion désactivée à chaque tour est encore plus rapide, et coûte 7,6 points, intervalle de moins 10,6 à moins 4,5, avec une chute de 13,5 points sur Terminal-Bench 2.0. Un Jeff moins prudent, avec son seuil relevé de 0,6 à 0,7, perd 4,5 points. Dans l'évaluation telle qu'elle a été menée, environ trois quarts des tours de Qwen se sont faits sans réflexion. Le petit modèle n'ajoute pas d'intelligence. Il décide quand l'intelligence est nécessaire.

Les modèles de décision passent du texte aux images

Liquid AI a poussé la même idée dans une autre direction le 5 octobre, en annonçant d1, qu'elle présente comme son premier modèle de décision et le premier à traiter les images comme le texte. Un appel à d1 lit son entrée en une seule passe avant et renvoie des probabilités par réponse sans générer de tokens ; une décision sur du texte prend 200 à 300 millisecondes. L'entreprise affirme que d1 égale ou dépasse GPT-6.1 Sol sur quatre des six applications de test et coûte 19 à 200 fois moins cher que ce modèle comme que Claude Opus 5.5, et répond plus vite sur chaque tâche.

Le plus intéressant, c'est que le modèle n'a jamais été entraîné pour cela. Grâce à son excellente capacité de généralisation, il comprend la tâche à partir d'une courte description.

Cette phrase vient du propre billet de Liquid, à propos d'une démo d'inspection visuelle construite sur le jeu de données public VisA de cartes de circuits imprimés, bougies, noix de cajou et chewing-gums, où d1 trie les pièces bonnes et défectueuses avec une précision de 85% à 97%. La formulation de l'entreprise est le point intéressant : un petit modèle spécialisé qui généralise à une tâche qu'il n'a jamais vue, à partir d'une phrase de description, au lieu d'un prompt et d'une fenêtre de contexte.

Une des démos de Liquid tombe directement sur le problème des agents de codage. Appelée Context Compaction, elle charge d1 de lire chaque sortie d'outil dans une session d'agent et de la garder, la rogner ou la supprimer, retirant 52% des tokens tout en conservant chaque sortie dont la tâche a besoin. Liquid dit avoir adapté quatre des six applications textuelles à partir de projets open source. Le tableau de benchmarks est celui de l'entreprise, et le rival de d1, Jev, n'y apparaît que comme un nom : Liquid affirme qu'une version expérimentale publiée une semaine plus tôt a fait de d1 le premier modèle à rivaliser avec Jev sur les décisions textuelles, mais ne donne aucun chiffre sur Jev.

Le billet de Sean Goedecke du 5 octobre explique pourquoi un modèle comme Jev ou d1 est facile à remplacer une fois qu'il fonctionne. Comme on l'interroge pour une tâche précise, on peut journaliser ses entrées et ses sorties et entraîner son propre classifieur dessus. Le modèle fabriqué à la main sera moins cher et plus rapide, puisqu'il ne porte aucune connaissance de tâches sans rapport. Goedecke ne dit pas que les petits modèles de décision sont faibles. Il dit qu'ils sont un marchepied, et un marchepied bon marché pour valider une fonctionnalité avant d'embaucher la moindre expertise en apprentissage automatique.

La pile des petits modèles se remplit autour d'eux

D'autres sorties dans les mêmes 24 heures montrent à quel point l'outillage autour des petits modèles locaux a progressé. Interfaze 1.1 Lite, publié sur Hugging Face le 5 octobre, est un modèle à mélange d'architectures qui tourne sur un seul GPU de 80 Go sans service externe. Un cœur vision-langage route le travail vers des spécialistes pour les documents, la parole, la détection d'objets et les contrôles de sécurité, et il tient un contexte de 131 000 tokens. Son propre tableau le place à 73,2 sur MMMU-Pro contre 71,1 pour Interfaze et 40,4 pour GPT-5.4-Mini, et à 83,8 sur olmOCR-Bench contre 85,7 pour Interfaze : le petit modèle perd face à son propre prédécesseur plus grand sur un benchmark de documents et gagne sur le raisonnement multimodal.

Metagente, publié sur GitHub le 5 octobre, prend le pari inverse : un seul binaire Rust et un court fichier d'agent déclaratif au lieu d'un framework Python. Il parle nativement MCP et A2A, et son argument est que chaque agent déclare quels dossiers, variables d'environnement et autres agents il peut utiliser. Ce modèle de permissions est la partie à surveiller pour qui fait tourner des agents sur sa propre machine, où le mode de défaillance n'est pas une mauvaise réponse mais une mauvaise opération sur les fichiers.

Le côté académique n'est pas tranché non plus. Une étude de l'UC Riverside, publiée le 23 septembre, a trouvé que la confiance et l'exactitude dans les grands modèles de langage proviennent de caractéristiques internes différentes. L'équipe a étudié Llama-3.1-8B de Meta et Gemma-2-9B de Google avec des autoencodeurs parcimonieux et a constaté que supprimer les caractéristiques liées uniquement à l'incertitude réduisait fortement la précision, tandis que supprimer la plupart des caractéristiques liées aux réponses incorrectes n'y changeait rien.

Het Patel, doctorant en informatique à l'UCR et premier auteur, a formulé cette découverte contre l'hypothèse par défaut du domaine : « L'hypothèse principale du domaine est que, lorsque le modèle est confiant, il est probablement correct, et que, lorsqu'il est incertain, il est plus probablement incorrect. » Le point utile est que les chercheurs ont modifié le comportement en baissant des caractéristiques internes plutôt qu'en réentraînant, ce qui est exactement l'économie que recherchent Jeff-Code et d1.

Ce que les chiffres ne tranchent pas

L'argument en faveur des petits modèles embarqués repose sur trois affirmations que les sorties du 5 octobre étayent inégalement. Sur le coût, l'écart de 19 à 200 fois de Liquid et le temps par tâche de 0,68 fois de Jeff-Code sont tous deux auto-déclarés, mesurés contre des références choisies par les entreprises. Sur la capacité, Reika dit explicitement que son harnais rend un petit modèle moins frustrant plutôt que plus intelligent, et le taux de réussite de Jeff-Code est stable, pas meilleur. Sur la confiance, les travaux de l'UCR indiquent que la confiance d'un modèle est un mauvais guide, ce qui compte davantage quand le modèle décide quoi sauter que quand une personne lit sa réponse.

Beam de Reflection, annoncé le 5 octobre, montre le contrepoids. Son modèle parcimonieux de 501 000 000 000 de paramètres, avec 23 000 000 000 de paramètres actifs, atteint 80,1 sur Terminal Bench v2.1, où Kimi K3 marque 88,3 et DeepSeek V4.1 Flash 90,6. Reflection affirme que Beam égale GLM-5.2 sur le raisonnement avancé tout en utilisant 3 à 4 fois moins de calcul d'inférence. Les poids, le rapport technique et la fiche du modèle sont attendus plus tard ce mois-ci, et le modèle est encore en test d'intrusion.

La frontière ne reste donc pas immobile, et l'histoire des petits modèles n'est pas une course qu'ils gagnent. C'est un pari différent : que l'essentiel du travail d'agent consiste à router, lire et décider, et qu'un modèle de 800 000 000 de paramètres qui prend ces décisions pendant qu'un plus grand réfléchit vaut plus qu'un plus grand qui fait tout. L'évaluation derrière Jeff-Code soutient ce pari sur la vitesse et le laisse non prouvé sur la qualité. Rien n'y montre que l'association bat Qwen seul. Elle montre qu'elle tient le rythme en dépensant moins.

Ce que personne n'a publié, c'est le chiffre que les acheteurs voudraient le plus : le coût de faire tourner la paire sur le matériel qu'une équipe normale possède. Jeff-Code a tourné sur le même serveur Qwen en blocs appariés. Liquid cite un coût par décision face à deux modèles hébergés. Les chiffres de Reika sont des temps de préremplissage sur une installation llama.cpp locale, ce qui a au moins le mérite de montrer la surcharge du harnais. Tant que ces nombres ne sont pas comparables, le résumé honnête du 5 octobre est que les petits modèles sont devenus assez bon marché pour tenir dans la boucle, et que les débats sur leur place dans cette boucle ne font que commencer.