Reika et Jeff-Code : pour les petits modèles locaux, le harnais compte plus que le modèle
Deux agents de codage sortis le 5 octobre disent la même chose : avec les petits modèles locaux, c'est l'échafaudage autour du modèle qui bloque, pas le modèle. Les deux projets publient des chiffres concrets.

Reika est un outil en ligne de commande pour agents de codage, destiné aux modèles locaux comme aux modèles hébergés. Il a été publié sur GitHub le 5 octobre. Il est pensé d'abord pour les petits modèles : de 8 000 000 000 à 35 000 000 000 de paramètres, souvent exécutés en Q2 à Q4 sur une fenêtre de contexte de 16 à 32 000. L'auteur, Alex Leung, dit que l'objectif n'est pas de rendre un petit modèle plus intelligent, mais de rendre le travail avec lui moins pénible.
Ce cadrage compte pour quiconque fait tourner un assistant de codage sur un portable ou un seul GPU. Si c'est le harnais, et non le modèle, qui pèse le plus dans le coût des échecs, alors l'amélioration la moins chère est une meilleure boucle. Le projet est en pré-1.0 : les commandes et les réglages peuvent encore changer.
La partie la plus utile de la sortie de Reika est un relevé de mesures publié. Une réécriture en milieu de contexte a retraité 8 453 tokens de prompt, soit 7,9 minutes de préremplissage. Un ajout dans la même session a coûté 25 tokens et 3,5 secondes. Dans un test A/B, une des branches a abandonné ses conclusions avant un repli. Elle s'est repliée cinq fois, a relu des fichiers déjà lus et n'a jamais répondu. La branche à qui on demandait d'abord ses conclusions a répondu à partir du résumé. Le compte rendu de Reika dit lui-même qu'un grep renvoyant « 0 correspondance » pour un appel qu'il ne pouvait pas servir a poussé un modèle à reformuler un motif correct pendant cinq tours.
Reika signale un partage des comportements selon la taille. Dans ses tests, les modèles de 14 000 000 000 à 35 000 000 000 de paramètres traitaient le plus sûrement les tâches multi-fichiers. Les modèles de 8 000 000 000 à 9 000 000 000 de paramètres venaient à bout des tâches simples et bien délimitées, et ceux sous 7 000 000 000 de paramètres allaient rarement loin.
La formulation du prompt change peu. Sur une tâche vague en Q2, un modèle converge ou part en vrille à peu près une fois sur deux. Le harnais ne peut pas changer ce taux, seulement ce que coûte la moitié qui échoue.
Un second harnais, une autre astuce
Jeff-Code est également sorti le 5 octobre. Il dérive de Pi, l'agent de codage de Mario Zechner et de ses contributeurs, et place un modèle de décision de 800 000 000 de paramètres appelé Jeff dans la boucle, aux côtés de Qwen 3.8-27B. Autour de chaque tour de Qwen, Jeff prend deux décisions d'environ 200 ms chacune. La première : peut-il faire lui-même l'étape suivante (lire un fichier, lister un dossier, chercher dans le code, lancer des tests). La seconde : Qwen a-t-il besoin de réfléchir à fond sur ce tour. L'écriture et la modification de fichiers restent toujours du ressort de Qwen.
Les résultats sont étroits mais honnêtes. Sur 1 242 tâches appariées, le taux de réussite est de 62,4 % avec Jeff-Code contre 62,8 % pour Qwen 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 moyen par tâche tombe à 0,68x, pour une médiane de 0,70x. Le temps total sur l'ensemble des tâches est de 0,86x, parce que sur environ 5 % des tâches Jeff-Code a tourné plus de 30 minutes de plus que Qwen seul.
Certains benchmarks ne montrent aucun gain net : Terminal-Bench 2.0 à 0,96x et SkillsBench à 0,91x. Couper la réflexion à chaque tour est encore plus rapide, mais coûte 7,6 points. Un Jeff moins prudent, avec un seuil à 0,7, coûte 4,5 points. C'est l'arbitrage que la sortie rend explicite : la vitesse vient du fait de sauter la réflexion, pas de la supprimer.
La même semaine a apporté un modèle de décision visant le même problème. Liquid AI a présenté d1 le 5 octobre, son premier modèle de décision, désormais doté de la vision. Il renvoie des probabilités sans générer de tokens, à 200 à 300 ms par décision textuelle. Liquid affirme que d1 égale ou dépasse GPT-6.1 Sol sur quatre des six applications testées et coûte 19x à 200x moins cher. Dans une démonstration, il compacte le contexte d'un agent de codage en retirant 52 % des tokens tout en gardant chaque sortie dont la tâche a besoin. Ce sont des chiffres de l'éditeur, non vérifiés indépendamment.
Ailleurs, l'argument de l'embarqué s'appuie sur d'autres chiffres. Interfaze 1.1 Lite a été publié sur Hugging Face le 5 octobre. Il tourne sur un seul GPU de 80 GB sans service externe et transcrit un enregistrement de 95 minutes en environ 90 secondes. Son tableau de benchmarks place MMMU-Pro à 73,2 contre 71,1 pour Interfaze et 40,4 pour GPT-5.4-Mini. Il est en retrait sur GPQA Diamond, à 85,9 contre 92,4.
La question ouverte est de savoir quelle part de tout cela survit au contact de vrais dépôts. Ni Reika ni Jeff-Code ne publient de résultats sur un benchmark de codage frontière standard à pleine configuration. Les deux projets sont jeunes. Ce qu'ils montrent, c'est que la gestion du contexte, et non le nombre brut de paramètres, est là où les petits modèles locaux perdent du temps.
Sources
8- 01Reika – A coding agent CLI designed around small local models firstEN
- 02Jeff-Code: a 0.8B model makes Qwen 3.8-27B coding 47% faster, same pass rateEN
- 03d1: The most capable decision model, now with visionEN
- 04Interfaze-1-lite: the first open-weight model for deterministic taskEN
- 05Beam: Reflection's 501B open-weight modelEN
- 06System One models like Jev can train their own replacementsEN
- 07Study: Path discovered to make AI models red-flag their doubtful answersEN
- 08Rust for CPython (Python Language Summit 2026)EN
Tous les chiffres et citations de ce texte proviennent des sources citées ci-dessous.
Les contenus ont été préparés par l'équipe de rédaction, assistée par l'IA.
Commentaires
0- Aucun commentaire — soyez le premier.