Les modèles locaux battus par Opus et Codex : 0,21 sur MacBook contre 1,00 pour Codex

Peut-on faire tourner un « système agentique de fin du monde », qui fonctionne sans abonnement et sans les règles d'autrui ? L'auteur d'une étude publiée sur Habr, développeur du projet open-daimon, a testé la question en pratique. Il a confié la même tâche à des modèles cloud, à un MacBook Pro sous Apple M5, à un portable gamer avec RTX 5080 et à un NVIDIA DGX Spark.

Le cloud garde une large avance : Codex obtient 1,00, Opus 5.5 0,96, et le meilleur résultat sur MacBook s'élève à 0,21. Une réserve importante : dans la partie publiée, le texte s'interrompt à la description du dernier run du modèle dense sur Spark, si bien que nous n'avons pas les conclusions finales de l'auteur.

Pourquoi des modèles locaux, et comment la tâche est construite

L'auteur expose ses motivations sans détour. Dans ses conditions grand public pour les résidents de l'EEE et de la Suisse, Anthropic interdit l'usage commercial de Claude.ai, Pro et Max ; travailler dans Claude Code avec un abonnement Max enfreint donc formellement les règles. Il cite aussi des cas où Claude a refusé d'aider à obtenir les droits root sur un téléviseur LG personnel, et celui d'un chercheur dont le compte a été bloqué après une analyse de firmware via ChatGPT (ce dernier point repose uniquement sur ses dires ; OpenAI ne l'a pas commenté). S'y ajoutent la disparition de poids « décensurés » sur Hugging Face et la vérification de passeport via Persona depuis avril.

Le test repose sur le dépôt minibank : environ 700 lignes de Python, un registre comptable multidevise et un fichier DECISIONS.md consignant les décisions de l'équipe. La requête est formulée comme par un manager : le relevé ne correspond pas au solde, trouve pourquoi, corrige, vérifie, et regarde si la même panne existe ailleurs. Il y a sept pièges : un convertisseur-leurre dont la docstring dit « à utiliser partout », un taux corrigé rétroactivement, une limite de mois en UTC, une commission sur une ligne séparée, un export CSV avec horodatage ISO, un ancien convertisseur dont la modification est interdite, et un test qui fige des chiffres erronés.

Le score est calculé à l'insu de l'agent : 20 tests cachés en représentent la moitié, sept conditions « fines » 15 %, neuf corrections manifestement fausses, que les propres tests de l'agent doivent détecter, un quart, et le respect des règles 10 %. L'échelle est recalculée de sorte que 0 signifie « rien n'a changé » et qu'un score négatif signifie « a cassé plus qu'il n'a réparé ». La limite est de 20 minutes.

Ce que montrent le cloud, les portables et le DGX Spark

Référence cloud : Codex (GPT-6.1 Sol, medium) termine en 101 secondes pour ≈$0,14 par run, Opus 5.5 en 91 secondes pour $0,30, Claude Fable 5.1 en 288 secondes pour $1,79. Tous trois ont lu DECISIONS.md, évité le leurre et mis à jour le test-traître. La différence tient uniquement à leurs propres tests : Codex a repéré 9 corrections erronées sur 9, Opus et Fable 8 chacun. Des runs répétés ont montré qu'il s'agit de bruit : Opus et Fable ont parfois aussi obtenu 0,92.

MacBook Pro M5 avec 32 Go : Qwen3 Coder 30B A3B (MoE, 4 bits) produit 52 tok/s avec un prefill de 743 tok/s, mais il a remplacé le convertisseur et a continué à recalculer le virement — score de 0. Qwen3.8 27B (5,4 tok/s) a lu DECISIONS.md, mais n'a effectué aucune modification en 20 minutes. Le meilleur est Gemma 4 12B : 0,21 en 575 secondes. Elle a repris le montant comptabilisé au lieu de le recalculer, mais a manqué l'UTC, l'horodatage ISO et la commission. Ce résultat n'est apparu que dans trois runs sur dix ; dans un autre, le score était de −0,17. Les réglages d'échantillonnage n'ont pas réduit la dispersion.

Portable gamer avec RTX 5080 (16 Go de VRAM) et Qwen3.6-35B-A3B : avec un contexte de 42 000 tokens, la vitesse est passée de 9,5 à 94 tok/s après un réglage manuel de la répartition dans LM Studio. Les 40 couches sont sur le GPU, les poids des experts sont sur le CPU pour 40 % des couches, et le KV-cache est en q8_0.

L'auteur attribue la chute initiale au fait que LM Studio déportait sur le processeur des couches entières, attention comprise. Mais la vitesse n'a pas amélioré la qualité : le harness léger pi a donné 0,31 en 285 secondes, OpenCode 0,14, sans tenir dans la limite. OpenCode envoie environ 15 000 tokens à la première étape contre 2 200 pour pi, et son modèle a produit 55 000 tokens de raisonnement contre 11 000.

Sur le DGX Spark (puce GB10, 128 Go de mémoire partagée, vLLM, NVFP4 — format 4 bits avec prise en charge matérielle dans la puce), Qwen3.6-35B-A3B, distillée à partir d'Opus, obtient 0,25 : 12 tests cachés sur 20 et 3 conditions fines sur 7. Ce modèle a manqué les mois en UTC, l'horodatage ISO et la commission dans les cinq runs, sur deux machines, deux serveurs et deux harness. Le modèle dense ThinkingCap-Qwen3.8-27B, avec une limite de 10 minutes, a laissé un diff vide, alors qu'il avait correctement identifié l'erreur principale dans son raisonnement ; sans limite, il a consommé 987 secondes et obtenu 0,92.

Conclusion pratique

L'auteur précise que la tâche est unique, en Python, et qu'il n'y a généralement eu qu'un ou deux runs ; ce test ne permet donc pas de départager des modèles locaux proches. Mais l'écart entre le cloud et les modèles locaux rapides ne s'explique pas par le bruit. Deux enseignements pratiques se dégagent. Un harness léger et un réglage manuel de l'offload accélèrent l'agent local de plusieurs fois, mais la taille du modèle détermine la qualité. Et le seul résultat local au niveau du cloud — le modèle dense 27B sur Spark — a exigé près de 16,5 minutes au lieu d'une minute et demie.