team-solve : cinq agents Qwen3.8-27B qui résolvent du code

team-solve est un workflow multi-agents pour Memdoor, qui fait travailler en équipe cinq rôles tenus par un même modèle, Qwen3.8-27B, sur des problèmes de programmation. Sur dix problèmes LiveCodeBench Hard, il obtient une moyenne de 9,8 sur 10 en cinq passes, contre 8,0 pour Fable 5 seul. L’échantillon est petit et une contamination n’est pas exclue : le détail compte autant que le score.

En bref

• Cinq rôles et un worker de réparation, chacun avec un contexte neuf, échangent uniquement par des fichiers.
• Un script shell qui lance les exemples décide du succès, pas un modèle.
• Moyenne de 9,8 sur 10 sur dix problèmes, contre 8,0 pour Fable 5 seul.
• Dix problèmes seulement, et la contamination du modèle par l’entraînement ne peut pas être exclue.
• Il fonctionne aussi avec un modèle local, via Ollama, llama.cpp, vLLM ou LM Studio.

Ce qu’est team-solve

team-solve est un harnais multi-agents pour problèmes de programmation, écrit sous forme de workflow Memdoor. Il reprend la méthode de GVS5H (Lee, 2026), dont l’article affirme que cinq modèles Qwen3.8-27B égalent Fable 5 sur LiveCodeBench Hard.

Selon le projet, les fichiers du workflow ont été écrits par le coder de Memdoor lui-même, à partir d’une description de la méthode (2026-10-25). Personne ne les a rédigés à la main.

Comment fonctionne team-solve

Cinq rôles interviennent : un planner, deux ideators, un solver et un manager, auxquels s’ajoute un worker de réparation. Chacun démarre avec un contexte neuf et ne communique avec les autres que par des fichiers sur disque. Chaque prompt d’agent dit de lire les fichiers et de ne pas se fier à la conversation.

Le projet rappelle que l’article de référence attribue le gain à cette discipline du registre de notes, un fichier notes.md où chaque ideator a son emplacement. Il n’y a qu’une ronde de réparation et aucune validation humaine.

• plan : lit task.md, écrit plan.md et le registre notes.md
• ideate-a et ideate-b, en parallèle : A propose l’algorithme le plus direct et démontrable, B une technique d’une autre famille
• solve : tranche dans notes.md et écrit solution.py
• test : lance les exemples, sans jamais faire échouer le run
• review : lit la sortie réelle des tests, pas l’affirmation d’un modèle
• repair : corrige solution.py, ou ne fait rien si les exemples passent
• verify : relance les exemples ; un code de sortie non nul fait échouer le run

Un script shell comme juge

Le verdict ne revient pas à un modèle. L’étape finale, de type commande, exécute un script qui compare la sortie de solution.py aux fichiers d’exemples avec diff. Si le script renvoie un code non nul, le run échoue.

Le programme lit son entrée standard et exige Python 3 et bash. La boucle ne voit que les exemples publics ; le score, lui, est mesuré sur les tests cachés.

Les résultats face à Fable 5

Reconstruit avec les prompts exacts des auteurs sur Qwen3.8-27B, le workflow a obtenu une moyenne de 9,8 sur 10 en cinq passes sur les dix premiers problèmes LiveCodeBench Hard. Le harnais des auteurs fait 9,6 et Fable 5 seul 8,0. Par passe, le workflow a fait 10, 10, 10, 10 puis 9.

Au total, 49 runs sur 50 ont réussi. Les 50 runs ont coûté 35,79 dollars (15,3 millions de jetons de sortie), 38,77 dollars avec les 16 tentatives interrompues. Un run a pris en médiane 40 minutes de temps de modèle (4 heures au plus) et 0,39 dollar.

Limites de la comparaison

Le projet pose lui-même des réserves. Il s’agit de dix problèmes, cinq passes chacun, et non des cent des auteurs. Les concours datent du 29 mars au 6 avril 2025 et le modèle a pu les voir à l’entraînement : la contamination ne peut pas être exclue. La colonne de Fable 5 est un appel unique par problème, tiré des fichiers des auteurs, et n’a pas été lancée dans ce harnais.

Autre différence : les auteurs utilisaient leur propre vLLM en FP8, alors que les runs sont passés par OpenRouter, sur plusieurs hébergeurs (Modal, CoreWeave, Wafer). Modal ne publie pas sa précision numérique. Côté fidélité, un test (lib/test_parity.py) compare chaque requête des deux boucles avec un modèle scripté : les quatre cas sont identiques.

Où team-solve a échoué

Un échec sur la passe 5 : pour abc399_e, le premier programme était juste, mais le manager a inventé un contre-exemple avec une mauvaise réponse attendue. L’équipe a réécrit le code, et le nouveau programme passe les exemples, qui ne couvrent pas ce cas.

Sur la passe 4, arc196_c et arc196_d ont vu un programme correct écrasé par une ronde suivante, faute que le manager déclare avoir fini. Les deux ont retrouvé un programme juste avant la fin, pour 3,44 et 4,24 dollars, les deux runs les plus chers. Le projet juge ces défauts corrigeables sans changer la méthode : vérifier un contre-exemple par force brute sur de petites entrées, et garder le dernier programme qui passe les exemples. Aucune de ces corrections n’entre dans les chiffres.

Installer et lancer team-solve

Après l’installation de Memdoor et la connexion à un fournisseur, il suffit de copier le dossier du workflow dans ~/.memdoor/workflows, puis de lancer le run dans un dossier contenant task.md et des paires tests/N.in et tests/N.out. Les étapes ne nomment aucun modèle : celui épinglé avec /model répond, y compris un modèle local.

Pour un problème personnel, il faut remplacer task.md et fournir ses propres fichiers de tests. Le projet ne donne pas de configuration matérielle minimale pour un modèle local.

curl -fsSL https://memdoor.ai/install.sh | bash
memdoor connect openrouter                 # or anthropic, openai, gemini, chatgpt
# or no key at all: memdoor connect local   # Ollama, llama.cpp, vLLM, LM Studio on this machine
git clone --depth 1 https://github.com/guregodevo/memdoor
mkdir -p ~/.memdoor/workflows
cp -r memdoor/examples/workflows/team-solve ~/.memdoor/workflows/   # the library: any project sees it
mkdir my-problem && cd my-problem
cp -r ../memdoor/examples/workflows/team-solve/sample/* .          # task.md + tests/1.in … 5.out

Quelques repères

• Contamination : Situation où un modèle a déjà croisé pendant son entraînement les problèmes sur lesquels on le teste. Son score peut alors être meilleur que sur des problèmes réellement inédits.

Questions fréquentes

team-solve bat-il vraiment Fable 5 ?

Sur dix problèmes LiveCodeBench Hard, oui : 9,8 sur 10 en moyenne contre 8,0 pour Fable 5 seul. Le projet précise toutefois que l’échantillon est petit et que la contamination ne peut pas être exclue.

Peut-on utiliser team-solve avec un modèle local ?

Oui. Les étapes ne nomment aucun modèle, et memdoor connect local permet d’utiliser Ollama, llama.cpp, vLLM ou LM Studio sur sa machine. Les résultats publiés viennent toutefois d’OpenRouter, pas d’une machine locale.

Combien coûte un run de team-solve ?

Un run a coûté 0,39 dollar en médiane, pour 40 minutes de temps de modèle. Les 50 runs de la comparaison ont coûté 35,79 dollars.

Qui décide que la solution de team-solve est correcte ?

Un script shell, pas un modèle. Il exécute solution.py sur les exemples et compare les sorties avec diff.

À retenir

team-solve montre qu’un workflow où des agents au contexte neuf échangent par fichiers, jugés par un script, atteint 9,8 sur 10 avec Qwen3.8-27B sur dix problèmes LiveCodeBench Hard. Le résultat reste limité par la taille de l’échantillon, une possible contamination et un hébergement différent de celui des auteurs.