Le mode Ultracode : quand et comment l'utiliser

"Ultracode", "ultrathink", "xhigh", "max" — tout le monde mélange tout depuis le lancement d'Opus 4.8. Or ces termes désignent des choses très différentes, et les confondre te coûtera des tokens. Cet article démêle le sujet et te donne les clés pour utiliser le mode Ultracode à bon escient.

Ce qu'Ultracode est (et n'est pas)

Ultracode n'est pas un niveau d'effort. C'est un mode de Claude Code qui combine deux choses :

1. Le niveau de raisonnement xhigh envoyé au modèle à chaque message
2. L'orchestration automatique de Dynamic Workflows pour chaque tâche substantielle

La distinction est capitale. Quand tu actives ultracode, Claude ne se contente pas de réfléchir plus fort — il décide de lui-même si une tâche mérite un workflow complet avec des dizaines d'agents parallèles, et il l'orchestre sans que tu aies besoin de le demander.

Une seule requête peut devenir trois workflows enchaînés : un pour comprendre le code, un pour appliquer la modification, un pour vérifier le résultat. Le tout sans intervention de ta part.

Le tableau des niveaux d'effort

Avant d'aller plus loin, clarifions la hiérarchie complète :

Point important : high est le défaut sur Opus 4.8, pas xhigh (c'était le défaut sur 4.7). Et ultracode ne persiste pas entre sessions — il se réinitialise quand tu en ouvres une nouvelle.

Et ultrathink dans tout ça ?

ultrathink est encore autre chose. C'est un mot-clé one-shot : place-le n'importe où dans un prompt et Claude raisonne plus profondément pour cette réponse uniquement, sans changer les réglages de session et sans déclencher de workflow.

Détail amusant : "think", "think hard" et "think more" ne font rien du tout. Seul ultrathink est reconnu comme mot-clé. Le reste est traité comme du texte ordinaire.

Résumé mental : /effort high pour le quotidien. ultrathink pour un coup de boost ponctuel. ultracode quand tu veux le mode pleine puissance sur toute la session.

Comment l'activer

/effort ultracode

C'est tout. À partir de là, Claude décide automatiquement quand orchestrer un workflow pour chaque tâche de la session. Pour revenir à la normale :

/effort high

Prérequis

• Opus 4.8 — ultracode nécessite xhigh, qui n'est disponible que sur Opus 4.7+. Sonnet 4.6 ne le supporte pas. Lance /model opus si tu es sur un autre modèle.
• Claude Code v2.1.154+ — mets à jour avec claude update
• Sur Pro : active d'abord les Dynamic Workflows dans /config, puis passe sur Opus 4.8 avec /model opus
• Sur Enterprise : un admin doit activer les workflows au niveau de l'organisation

Via l'API et le SDK

Ultracode n'est pas un niveau d'effort standard — tu ne peux pas le passer via --effort ou CLAUDE_CODE_EFFORT_LEVEL. Il se configure via --settings ou une requête de contrôle Agent SDK avec "ultracode": true.

Ce qui se passe quand tu l'actives

Avec ultracode, voici le flux pour chaque tâche :

1. Tu poses ta question normalement — pas besoin du mot-clé workflow
2. Claude évalue si la tâche justifie un workflow
3. Si oui : Claude écrit un script JavaScript d'orchestration, le runtime le lance, des agents parallèles travaillent en arrière-plan
4. Si non : Claude répond directement avec le raisonnement xhigh
5. Plusieurs workflows peuvent s'enchaîner pour une seule demande

La différence clé avec un workflow manuel : tu n'as rien à demander. Claude juge lui-même de l'ampleur nécessaire.

En pratique : quand l'utiliser

Les bons cas

Refactoring massif d'une codebase :

Migrate all callbacks in app/models/ to async/await pattern.
Ensure all existing tests still pass.

Claude va orchestrer : analyse de tous les modèles, migration par lots en parallèle, puis vérification croisée.

Audit de sécurité complet :

Audit this Rails app for the OWASP Top 10.
Check every controller, model, and view.
Report findings by severity with file paths.

Des agents inspectent chaque couche en parallèle, d'autres agents tentent de réfuter les findings avant le rapport final.

Exploration + modification d'une codebase inconnue :

Understand the authentication flow in this app,
then replace Devise with a custom authentication system using has_secure_password.
Keep all existing tests green.

Premier workflow : cartographie. Deuxième workflow : migration. Troisième workflow : vérification.

Investigation de bug complexe :

Users report intermittent 500 errors on /api/orders.
Find the root cause by analyzing logs, code paths, and race conditions.

Les mauvais cas

• Un fix d'une ligne — l'overhead d'orchestration ne t'apporte rien
• Une question rapide — "comment fonctionne has_many :through ?" n'a pas besoin de 16 agents
• Du travail de routine — commits quotidiens, petits ajustements CSS, corrections de typos
• Un prompt vague — "améliore cette app" envoie des agents dans toutes les directions et brûle des tokens pour rien

La règle : si tu confierais la tâche à un seul développeur pour une après-midi, n'invoque pas un essaim.

Le piège des tokens

C'est le sujet qui revient de la première semaine d'utilisation. Les chiffres sont brutaux :

• Un développeur sur le plan Max ($200/mois) a consumé 20% de sa limite hebdomadaire en un seul jour
• Un utilisateur Pro ($20/mois) a atteint son plafond en dix minutes
• Un prompt anodin en ultracode peut lancer des centaines d'agents qui lisent, écrivent et vérifient — chacun consommant des tokens

Anthropic ne cache pas le problème : les Dynamic Workflows "peuvent consommer substantiellement plus de tokens qu'une session Claude Code typique".

Comment maîtriser la facture

• Scope serré — donne un chemin (sous app/controllers/ uniquement), un format de sortie attendu, et une politique d'édition
• Route les phases simples vers un modèle moins cher — dis à Claude "utilise un modèle plus petit pour les étapes qui ne nécessitent pas Opus"
• Surveille en temps réel — /usage montre ta consommation, /workflows te permet de stopper un run sans perdre le travail fait
• Coupe ultracode dès que c'est fini — /effort high pour repasser en mode normal
• Ne laisse jamais ultracode actif pour du travail courant

Le piège des conflits de merge

Quand plusieurs agents éditent le même fichier en parallèle, tu récupères des conflits de merge — créés par une IA, à démêler par toi. C'est le problème que les articles enthousiastes oublient de mentionner.

La solution documentée : les git worktrees. Chaque session parallèle travaille dans son propre checkout isolé, les agents ne se marchent pas dessus, et le merge final est propre.

Autre piège : un agent qui échoue silencieusement peut insérer des données factices derrière un try/catch et continuer comme si de rien n'était. En mode parallèle, ça se propage vite. La parade : une règle dans ton CLAUDE.md :

Error handling: fail loud, never fake.
- Never suppress an error to look like it worked.
- Expose the failure; do not substitute placeholder data.
- A fallback is okay only if it's transparent.

Configurer les permissions avant de lancer

La phrase la plus partagée au lancement d'Opus 4.8 : "New model day is not prompt day. It is permission-design day." Avant de lâcher un essaim sur un vrai repo :

1. Pré-charge ton allowlist (/permissions) avec les commandes dont les agents auront besoin — c'est ce qui évite que le run se bloque sur un outil non approuvé
2. Travaille dans une branche jetable ou un worktree — jamais sur main au premier essai
3. Commence en lecture seule — un premier workflow pour mapper et confirmer les problèmes, un second pour appliquer les corrections
4. Scope le prompt avec un chemin, un contrat de sortie, et une politique d'édition

Ultracode vs les alternatives

L'avantage réel d'ultracode : le plan est un script que tu peux lire, sauvegarder et réexécuter, et la boucle de vérification-réfutation fait que des agents indépendants tentent de casser le résultat avant que tu le voies.

En résumé

Ultracode est le mode "full throttle" de Claude Code. Il combine le raisonnement le plus profond (xhigh) avec l'orchestration automatique de workflows parallèles. C'est puissant sur les tâches à l'échelle d'une codebase — migrations, audits, refactorings massifs — où la parallélisation et la vérification croisée font une vraie différence.

Mais c'est un outil de précision, pas un mode par défaut. La consommation de tokens peut exploser si le scope n'est pas cadré, et les conflits de merge entre agents parallèles restent un problème réel. La bonne approche : activer ultracode pour la grosse tâche, cadrer le périmètre, surveiller le run, puis revenir immédiatement à /effort high pour le reste de la journée.

Le créateur de Bun a utilisé les Dynamic Workflows (avec ultracode) pour porter 750 000 lignes de Zig vers Rust en onze jours, avec 99,8% de la suite de tests toujours verte. Ça donne une idée du potentiel — et de l'échelle à laquelle ça devient rentable.