Deux threads sur Hacker News racontent la même histoire sous deux angles. Le premier, avec 204 points, documente comment GPT-5.6 Sol a fermé un problème ouvert depuis environ 30 ans en optimisation convexe, utilisant un prompt et des sous-agents en parallèle. Six jours avant, le 12 juillet, nous avions rapporté la démonstration de la Cycle Double Cover Conjecture : même modèle, même schéma.

Le deuxième thread, avec 121 points, est le test de Charles Azam. Il a mis Fable 5 et GPT-5.6 Sol sur le même problème NP-difficile, la conception d’un réseau en fibre optique avec un espace de recherche estimé autour de 10^1223 solutions, avec 30 minutes de budget chacun. Le résultat est instructif pour qui orchestre des agents.

Pourquoi ça te concerne. Fable 5 a battu Sol en configuration standard (moyenne 32.386 contre 34.261) avec une variance bien plus étroite : 319 points d’écart contre 1.958. Le modèle le plus puissant sur papier a perdu. Azam montre aussi que la commande /goal, présente dans Claude Code et Codex, restructure la boucle de contrôle au lieu de l’intensifier. Dans Claude Code, elle délègue à un modèle évaluateur séparé qui lit la conversation et dit oui ou non. Dans Codex, elle devient un état persistant en SQLite, avec des outils dédiés. Deux architectures différentes sous la même commande.

L’orchestration prime sur le modèle. Si tu délègues des tâches difficiles à un agent, c’est dans la boucle de contrôle que tu gagnes ou que tu perds.

En détail

Le thread Reddit ne donne pas le texte complet de la démonstration, mais le titre et la discussion sur Hacker News (204 points, 106 commentaires) indiquent que GPT-5.6 Sol a produit une preuve fermée pour un problème d’optimisation convexe resté ouvert environ 30 ans. La structure est la même que le résultat du 12 juillet sur la Cycle Double Cover Conjecture : le modèle orchestre des sous-agents en parallèle, chacun avec un fragment du problème, et combine les résultats en une démonstration vérifiée par un mathématicien.

Le test d’Azam descend dans le pratique. Le problème KIRO est réel : concevoir un réseau en fibre optique pour Grenoble, Nice et Paris, où chaque tour n’apparaît qu’une fois, les boucles doivent rester sous 30 terminaux et l’objectif est de minimiser la longueur du câble. Azam l’avait résolu en C++ en 2018, donc il a une baseline humaine. L’espace de recherche, même dans une version simplifiée (19 boucles de 28 terminaux, sans branches), est de l’ordre de 10^1223.

Les chiffres disent deux choses. Premièrement, Fable 5 a été plus cohérent : en trois runs sans /goal, les résultats se situent dans une plage de 319 points (de 32.197 à 32.516). Sol dans le même exercice s’étend sur 1.958 points (de 33.581 à 35.539). Deuxièmement, /goal a gagné 4 runs sur 6 mais a dégradé la moyenne pour les deux modèles. Parfois il trouve un meilleur bassin, parfois il donne du temps à une mauvaise idée pour mûrir.

Le détail le plus utile est sous le capot. /goal dans Claude Code est un Stop hook au niveau session : après chaque tour du modèle principal, un petit modèle (Haiku) lit la conversation et décide si l’objectif est atteint. Il ne peut pas utiliser d’outils ou inspecter les fichiers : il juge uniquement le transcript. Dans Codex (version 0.144.4, open source), /goal est persistant : le TUI sauvegarde l’objectif en SQLite avec état et budget, et le modèle reçoit des outils dédiés (create_goal, get_goal, update_goal). Quand le thread devient idle avec un goal actif, Codex injecte un tour de continuation avec un audit d’achèvement. Deux philosophies : Claude délègue à un autre modèle, Codex met l’état dans le système.

Les limites sont déclarées. Azam a testé un seul problème, avec six runs pour les deux meilleurs modèles et 30 minutes de budget arbitraire. L’implémentation de Claude Code est propriétaire, donc elle repose sur ce qu’Anthropic documente. Pour qui construit des agents, la conséquence pratique est claire : avant de chercher le modèle le plus fort, évalue comment ta boucle de contrôle gère l’objectif. Le cours sur comment orchestrer plusieurs agents et le playbook pour déléguer une tâche multi-étape construisent exactement cette compétence.