AIDiveIntro : mêmes vérifications, deux fois le compteur, cinq plafonds
Ultracode est le mot-clé, ou le bouton, qui transforme une seule demande tapée dans Claude Code en toute une équipe d'agents. Sur un test apparié avec la même spécification, les deux runs ont passé les mêmes vérifications cachées, et le run ultracode a consommé plus de deux fois le compteur de session. La raison n'est pas un modèle plus intelligent : c'est une phrase que le harnais injecte et trois garde-fous qu'il désactive.
Cet article couvre quatre choses :
- le test apparié, lu sur le compteur du forfait ;
- le multiplicateur de tokens sur plusieurs autres paires ;
- le seul type de travail où une équipe a trouvé 66 bugs plantés, contre 14 pour un agent seul ;
- les cinq réglages qui plafonnent un run avant qu'il ne mange votre semaine, dont un qui l'arrête à la limite d'usage elle-même.
Ce qu'ultracode active : le mot-clé, le bouton, un workflow d'agents
Ultracode, ce sont deux interrupteurs. Taper ultracode dans un prompt exécute cette seule tâche comme un workflow, sans toucher au niveau d'effort de la session. Activer le bouton via la commande /effort fait planifier un workflow à Claude pour chaque tâche substantielle, si bien qu'une seule demande peut devenir plusieurs workflows à la suite.
Un workflow est un script que Claude écrit pour lui-même ; ce script fait tourner une équipe d'agents par phases. Sur un minuscule bac à sable (deux fichiers avec une gestion approximative des promesses, revue en lecture seule demandée), Claude a repéré les fichiers, lancé un workflow qu'il a nommé « unhandled promise audit », et une ligne de tâche est apparue sous la zone de saisie, avec une barre de progression, le nombre d'agents, le temps écoulé et un total de tokens qui s'incrémente. La commande /workflows liste une ligne par agent avec son propre nombre de tokens, plus des touches pour mettre en pause, arrêter ou relancer.
Sur ce run, chaque agent de recherche avait lu environ 45 000 tokens avant même que les vérificateurs ne démarrent, pour une poignée de lignes de code.
Chaque session porte aussi une consigne de taille, le nombre d'agents que Claude est invité à ne pas dépasser :
| Consigne de taille | Agents conseillés |
|---|---|
| small (par défaut sur Pro) | moins de 5 |
| medium | moins de 10 |
Chaque agent envoie ses propres requêtes en plus de votre conversation. Un workflow n'est jamais une seule facture : c'est une facture par agent, et le compteur les compte toutes.
Le test apparié : les mêmes 136 vérifications, 8 pour cent contre 18, et il ne s'arrête jamais
Un développeur a mesuré le coût sur le forfait d'abonnement le plus élevé, dans une configuration propre : la même spécification pour un petit tableur, le même modèle au même niveau d'effort, un run classique et un run ultracode. Les deux ont été notés par des vérifications cachées, des tests que le modèle ne voit jamais. Les deux ont passé les 136.
| Run | Fin | Limite de session utilisée | Vérifications passées |
|---|---|---|---|
| Classique | de lui-même, 25 min | 8 % | 136 / 136 |
| Ultracode | coupé par l'horloge à 76 min, toujours en train de vérifier | 18 % | 136 / 136 |
Dans le run ultracode, Claude a écrit un script dont le seul rôle était de faire tourner une équipe : 12 agents comptés, des testeurs, quelques juges, puis des « briseurs » chargés de casser la page. L'un d'eux a bien trouvé un vrai bug dans la barre de formule, qui continuait d'afficher l'ancien texte après un clic sur une autre cellule.
Par minute, le run ultracode a consommé la limite à peu près aussi vite que le run classique, en moyenne un peu moins vite. Il n'a pas brûlé plus vite ; il ne s'est simplement pas arrêté. Ultracode ne rend pas Claude plus intelligent, il lui fait vérifier, et vous payez chaque vérification. C'est une seule paire sur une petite spécification, et le second run a été coupé par une horloge, mais la forme est claire : même réponse, plus de deux fois la fenêtre de session, et le temps en plus n'a été que de la vérification.
Pourquoi ça coûte : une phrase et trois garde-fous désactivés
Le modèle est le même. Ce qui change, c'est le texte que le harnais lui remet ; le harnais, c'est Claude Code lui-même, ses outils et les instructions autour du modèle.
Quand ultracode est actif, Claude Code charge une référence avant d'écrire le moindre workflow. Ce texte dit au modèle d'exécuter un workflow pour chaque tâche substantielle par défaut, et il contient la phrase qui explique la facture : « The goal is the most exhaustive, correct answer you can produce, and token cost is not a constraint. » C'est le texte propre du harnais, et une issue GitHub publique cite les mêmes lignes.
Trois garde-fous tombent en même temps :
- L'avertissement de gros workflow, qui se déclenche normalement quand un run planifie trop d'agents, n'apparaît pas.
- La limite de la session sur le nombre d'agents simultanés n'est pas appliquée aux agents que Claude lance.
- En mode auto, le premier lancement n'est jamais soumis à approbation.
La consigne de taille est un conseil, pas un plafond : réglée sur small (moins de 5 agents) sur le bac à sable, le run ultracode en a quand même lancé 9. Pour être juste, la phrase est une valeur par défaut que le modèle peut encore peser, et les garde-fous sont retirés exprès pour les très gros travaux. La réponse tient en une ligne : ultracode ne change pas le modèle, il change les instructions en « une équipe pour tout, et le coût n'est pas une contrainte ».
Le multiplicateur : trois paires, l'échelle d'effort, la paire à 30x
Un second développeur a fait tourner plusieurs paires agent seul contre workflow sur le forfait Pro, des scripts de type revue, en lisant le compteur d'usage avant et après chacun.
| Mesure | Agent seul | Workflow |
|---|---|---|
| Tokens sur un script de revue | environ 115 000 | 972 000 |
| Multiplicateur de tokens sur les paires | 1x | jusqu'à 18x, pour à peu près les mêmes résultats |
| Mouvement du compteur | 1x | jusqu'à 3x |
| Temps réel | presque identique | presque identique |
Le workflow n'a pas fini plus vite ; il a dépensé plus pendant que vous attendiez autant. Le seul endroit où le parallèle a payé est un lot de recherches indépendantes, où les agents ont fini plus vite, toujours pour plus de deux fois les tokens.
Un troisième test a construit quelques petites applications à chaque niveau d'effort, aux prix de l'API. Chaque marche de l'échelle a à peu près doublé la facture, et ultracode a atterri à plusieurs fois le coût de max sans jamais arriver en tête. L'essentiel de ces tokens étaient des lectures de cache, les moins chères ; la minuscule part de tokens de sortie représentait presque la moitié du coût.
Une dernière paire, une scène de ville : un agent seul a pris environ une heure pour quelques dollars au prix de l'API. Le run ultracode a pris presque une journée, des dizaines de sous-agents, et environ 30 fois le coût.
Ce sont des lectures de compteur en nombres entiers, des applications partant de zéro à prix API et une scène de ville, donc aucune n'est un classement à elle seule. Ensemble, le schéma est le même à chaque fois : le fan-out achète de la vérification et de la couverture, pas une meilleure réponse, sauf si le travail se découpe en morceaux indépendants.
Où le fan-out paie : une suite de tests comme juge, et la règle en une ligne
Certains travaux ont vraiment cette forme : une migration, un audit, un balayage de toute une base de code.
Bun a été réécrit de Zig vers Rust avec environ 50 workflows dynamiques dans Claude Code, tournant en continu pendant 11 jours. Cela représente plus d'un demi-million de lignes de Zig, du départ jusqu'à toute la suite de tests qui passe sur toutes les plateformes, dans ces mêmes jours. Ce qui a fonctionné n'est pas le nombre d'agents mais le juge : une énorme suite de tests existante disait réussi ou échoué sans l'avis de personne.
La chasse aux bugs d'Anthropic montre la même chose. Soixante-dix bugs ont été plantés dans une grande base de code et un agent seul a tourné plusieurs fois.
| Agent | Bugs trouvés sur 70 |
|---|---|
| Agent seul (3 runs) | 14, 15, 27 |
| Workflow (3 runs) | 66 à chaque run |
Une réserve : ce test a tourné sur Claude Managed Agents, le produit API, pas sur Claude Code, et aucun coût n'a été donné.
Le fil de lancement ajoute les autres gains rapportés, et ils se ressemblent tous : revue face à un fichier de règles, traduction d'une base de code entière, nettoyage d'un tas de pages scannées. Le blog de lancement le dit clairement : la plupart des tâches de code traditionnelles n'ont pas besoin d'un panel de cinq relecteurs.
La règle : ne faites du fan-out que lorsqu'une suite de tests ou un jeu de règles juge la sortie, et que le travail se découpe en morceaux indépendants. Tout le reste tourne en classique, à high. Le testeur de la paire l'a dit avec ses propres mots : gardez-le pour les travaux où la vérification est le travail, comme une migration sur des centaines de fichiers.
Cinq réglages qui plafonnent un run
Chaque plafond se trouve à un endroit que vous connaissez déjà.
| # | Réglage | Où | Effet |
|---|---|---|---|
| 1 | workflowSizeGuideline: "small" |
/config sous Dynamic workflow size, ou settings.json |
conseil (moins de 5 agents), abaisse aussi le seuil de l'avertissement de gros workflow |
| 2 | CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS |
variable d'environnement, exportée avant le lancement | par défaut jusqu'à 16 agents à la fois ; réglée à 4, les autres font la queue, ce qui ralentit la consommation sans tuer le run |
| 3 | CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL |
variable d'environnement | fait tourner chaque agent de workflow sur un seul modèle de votre choix pendant que les autres sous-agents gardent le leur ; un modèle moins cher rend la vérification moins chère |
| 4 | le mot-clé ultracode, jamais le bouton |
dans le prompt ; jamais la clé ultracode dans les réglages |
le mot-clé exécute une tâche comme workflow et s'arrête ; le bouton le rend permanent jusqu'à ce qu'on l'éteigne |
| 5 | autoContinueAtUsageLimit |
réglages | activé : un run qui atteint la limite se met en pause, attend la réinitialisation et continue, plusieurs fois ; désactivé : les agents échouent au mur et le run s'arrête là |
Trois habitudes vont avec. Le blog de lancement dit qu'un budget écrit dans le prompt, comme « use 10k tokens », fixe le plafond. Après tout run, /usage montre quelle part de l'usage récent est allée aux sous-agents et aux workflows, avec un avertissement quand ils dominent. Si un run semble anormal en cours de route, le panneau /workflows et la touche x l'arrêtent, et le travail déjà fait est en général conservé.
Rien de tout cela ne rend un agent moins cher. Cela plafonne le nombre d'agents qu'un run peut dépenser, et combien de temps il peut continuer à dépenser.
Le run incontrôlé, les limites et le verdict
Un rapport public montre comment une semaine disparaît. Un script écrit par le modèle sur le plus gros forfait a démarré 221 agents en moins d'une heure. Après la première erreur de limite de session, le script a continué à envoyer, et 189 agents de plus ont démarré dans les minutes suivantes. Le tableau de l'auteur du rapport compte des dizaines de millions de tokens sur les phases avant le mur.
| Phase | Tokens, cache inclus |
|---|---|
| Ground | 11 063 801 |
| Find | 35 885 272 |
| Merge | 516 226 |
| Total | 47 465 299 |
Le coupable était une ligne du script généré, un repli qui disait : si l'agent n'a rien renvoyé, utiliser la liste brute et continuer. La fusion a échoué et le run a continué. Cette version précède la pause à la limite d'usage, et l'auteur précise que ces tokens ne venaient pas des agents en échec. Un plafond de concurrence aurait éclairci ce run, et l'auto-continue désactivé l'aurait terminé au mur.
Le verdict : sur la même tâche, avec les mêmes vérifications passées, ultracode a pris plus de deux fois le compteur d'un run classique. Pas parce qu'il est plus intelligent, mais à cause de la phrase injectée et des garde-fous qu'il retire. Il paie quand une suite de tests ou un jeu de règles juge la sortie et que les morceaux ne s'attendent pas les uns les autres. Partout ailleurs, vous le tapez et vous payez de la vérification. Cinq réglages plafonnent ce qu'un run peut dépenser : la consigne de taille, le plafond de concurrence, le modèle du workflow, le mot-clé plutôt que le bouton, et l'arrêt à la limite.
