Les petits modèles locaux passent au banc d'essai du harness : Reika, Jeff-Code et d1 visent les agents embarqués

Le 5 octobre, deux projets GitHub sont apparus avec un cadrage presque identique. Reika, un agent de codage en CLI du développeur alexwkleung, a été conçu d'abord pour les petits modèles locaux : de 8 à 35 milliards de paramètres, souvent en Q2 à Q4, sur une fenêtre de contexte de 16 à 32 000 tokens. Jeff-Code, un fork de l'agent Pi de Mario Zechner, place un modèle de décision de 0,8 milliard de paramètres à côté de Qwen 3.8-27 milliards. Il annonce des tâches de codage 47 % plus rapides à taux de réussite égal.

Cela compte pour quiconque fait tourner des agents sur son propre matériel. Si c'est la boucle de l'agent, et non le modèle, qui décide si une exécution locale aboutit ou part en vrille, les petits modèles deviennent utilisables pour un travail qui exige aujourd'hui une API hébergée. Aucun des deux projets ne revendique des résultats de pointe. Ce qui reste inconnu, c'est la performance de l'un ou l'autre harness en dehors des évaluations de leurs propres auteurs.

Le README de Reika publie les mesures qui justifient ses choix de conception, et elles sont précises. Une réécriture en milieu de contexte a retraité 8 453 tokens de prompt, ce que le projet chiffre à 7,9 minutes de prefill. Un ajout dans la même session a coûté 25 tokens et 3,5 secondes. Dans un test A/B, une branche a abandonné ses conclusions avant un repli de contexte. Cette branche a replié cinq fois, relu des fichiers déjà lus et n'a jamais répondu. La branche à qui l'on demandait d'abord ses conclusions a répondu à partir du digest. La formulation du prompt, dit le projet, est le levier le plus faible. Sur une tâche vague en Q2, un modèle converge ou part en vrille à peu près une fois sur deux, et le harness ne peut pas changer ce taux, seulement ce que coûte la moitié qui échoue. Reika indique aussi que les modèles de 14 à 35 milliards de paramètres ont géré les tâches multi-fichiers le plus fiablement lors des tests. Les modèles de 8 à 9 milliards de paramètres s'en sortaient sur des tâches simples et bien délimitées, et en dessous de 7 milliards, ils allaient rarement loin.

Les chiffres de Jeff-Code viennent avec des intervalles, ce qui est rare pour un README de projet. Sur 1 242 tâches appariées, le taux de réussite était de 62,4 % avec Jeff contre 62,8 % pour Qwen 3.8-27 milliards seul. Soit une différence appariée de moins 0,2 point, avec un intervalle à 95 % de moins 2,6 à plus 2,1. Le temps par tâche était en moyenne de 0,68x, avec une médiane de 0,70x. Le temps total sur l'ensemble des tâches a moins baissé, à 0,86x, parce que sur environ 5 % des tâches, Jeff-Code tourne plus de 30 minutes de plus que Qwen seul. Désactiver la réflexion à chaque tour était encore plus rapide mais coûtait 7,6 points. Un seuil moins prudent de 0,7 coûtait 4,5 points.

Les modèles de décision, l'autre voie

Liquid AI a pris une approche différente le même jour. Son modèle d1, annoncé le 5 octobre, répond à des questions sur une situation avec une probabilité par réponse possible. Il ne génère aucun token, et renvoie des résultats en 200 à 300 ms pour une décision textuelle. Liquid affirme que d1 égale ou dépasse GPT-6.1 Sol sur quatre des six applications réelles testées, du filtrage de tickets de support à l'inspection de cartes de circuits imprimés. Et cela à un coût de 19 à 200 fois inférieur, et plus vite sur chaque tâche. L'entreprise rapporte aussi une précision de 85 à 97 % pour trier les pièces bonnes et défectueuses sur le jeu de données public VisA, une tâche pour laquelle le modèle n'a jamais été entraîné.

La démo la plus pertinente pour les constructeurs d'agents, c'est la compaction du contexte. Liquid indique que d1 lit chaque sortie d'outil dans la session d'un agent de codage et la conserve, la tronque ou la supprime. Il retire 52 % des tokens tout en gardant chaque sortie dont la tâche a besoin. C'est le même problème que Reika attaque avec les replis de contexte, résolu par un modèle bien plus petit à qui l'on pose une question plus étroite. Liquid présente d1 comme son premier modèle de décision et comme le premier à étendre ces capacités aux images.

La thèse du harness apparaît aussi dans un billet de Sean Goedecke publié le 5 octobre. Goedecke soutient que des modèles comme Jev, qui ne produisent que des décisions, peuvent être distillés en classificateurs construits à la main une fois qu'un prompt a été validé. On collecte les entrées et les sorties, puis on entraîne quelque chose de plus petit et de plus rapide pour cette seule tâche. Il note que l'entraînement d'un classificateur sur mesure sort des compétences de la plupart des équipes d'ingénierie. C'est ce vide qu'un modèle de décision généraliste comble en premier.

Tous les petits modèles ne sont pas des modèles de décision. Interfaze 1.1 Lite, publié sur Hugging Face le 5 octobre, est un modèle à mélange d'architectures. Il tourne sur un seul GPU de 80 GB sans services externes. Il annonce 83,8 sur olmOCR-Bench, 85,9 sur GPQA Diamond et un taux d'erreur de mot de 3,01 sur VoxPopuli-Cleaned. Il transcrit un enregistrement de 95 minutes en environ 90 secondes. C'est une capacité embarquée pour le document et la parole, pas pour le code.

La frontière des poids ouverts a bougé dans l'autre sens le même jour. Reflection a annoncé Beam, un modèle à mélange d'experts clairsemé de 501 milliards de paramètres au total et 23 milliards actifs. Il a été préentraîné sur 23 800 milliards de tokens et entraîné avec plus de 100 millions de rollouts sur 10 500 GPU NVIDIA GB300 pendant quatre semaines. Reflection affirme que Beam est compétitif avec des modèles ouverts plus grands comme GLM 5.2 et approche Qwen 3.8-Max sur le codage et les tâches agentiques. L'entreprise indique que Kimi K3 reste devant en capacité brute. Les poids, le rapport technique et la fiche du modèle sont promis plus tard ce mois-ci, et le modèle est encore en red-teaming.

Pour l'instant, l'affirmation pratique du côté des petits modèles est plus étroite que le marketing qui l'entoure. Reika est en pré-1.0 et prévient que les commandes et le comportement peuvent changer d'une version à l'autre. Le gain de vitesse de Jeff-Code tient sur SWE-bench Verified à 0,63x et sur Terminal-Bench Pro à 0,64x. Il ne montre aucun gain net sur Terminal-Bench 2.0 à 0,96x ni sur SkillsBench à 0,91x. Le harness aide surtout là où la tâche est routinière, ce qui est aussi l'endroit où un modèle de décision trouve sa place.