Claude Code Ultraplan — La planification passe dans le cloud

La planification a toujours ete le moment a plus fort effet de levier dans le coding agentique. Si on construit le bon plan, l’execution n’est plus qu’une formalite. Si on se trompe, on passe les deux heures suivantes a regarder un agent s’enfoncer avec assurance dans une impasse.

Anthropic vient de livrer une fonctionnalite Claude Code discretement majeure, qui pousse cette intuition plus loin : Ultraplan. Au lieu de faire tourner le mode plan en local, votre session est deportee vers une instance Opus 4.6 hebergee dans le cloud, ou plusieurs agents explorent votre codebase en parallele et produisent un plan plus profond et plus structure que tout ce que le terminal peut livrer — generalement en une fraction du temps.

Je le teste depuis quelques jours. Ce n’est pas seulement une planification plus rapide. La phase d’execution devient elle aussi nettement plus rapide, parce que le plan resultant est tellement clair que l’agent local n’a plus besoin de reflechir — il se contente de construire.

Ce qu’est vraiment Ultraplan

Ultraplan deporte votre session de planification vers le runtime de conteneurs cloud d’Anthropic, ou il lance un petit essaim d’agents :

Trois agents d’exploration paralleles qui parcourent votre codebase, lisent les skills et scripts existants, et proposent des approches
Un agent critique qui met les propositions sous pression
Opus 4.6 comme modele sous-jacent, quel que soit le modele utilise par votre session locale

Le resultat est un plan structure, en format document — contexte, ce qui existe deja, la nouvelle approche, les fichiers a creer, les fichiers a modifier, et une section finale de verification. Il inclut parfois des diagrammes. Et surtout, il vit sur une surface de revue web ou l’on peut laisser des commentaires et des reactions emoji sur des sections individuelles, plutot que de deverser du texte dans le scrollback du terminal.

Quand le plan vous convient, vous cliquez sur Approve Plan et il se teleporte dans votre session de terminal, pret pour une execution locale. Vous pouvez aussi l’executer a distance dans le cloud et reviewer les resultats plus tard.

Comment le declencher

Deux maniere de proceder :

# Slash command explicite
/ultraplan build me a customer dashboard with MRR, churn, and cohort retention

# Ou simplement inclure le mot-cle
ultraplan refactor the auth service to use the new Redis cache

Le mot-cle s’allume comme ultrathink — Claude Code le reconnait et vous demande si vous voulez envoyer la session de planification dans le cloud. Repondez oui et vous obtenez un lien pour suivre la progression dans Claude Code sur le web.

Vous pouvez aussi partir d’un plan local existant et le promouvoir en Ultraplan si, en cours de route, vous decidez qu’il merite un traitement plus lourd.

Une contrainte importante : ca ne fonctionne que dans le CLI. L’app desktop et l’extension VS Code ne declenchent pas Ultraplan — elles retombent silencieusement sur rien. Si vous voulez Ultraplan, vous devez etre dans votre terminal.

Le test cote a cote

La demo la plus frappante consiste a lancer le meme prompt deux fois — une fois en mode plan local, une fois avec Ultraplan — et a observer ce qui se passe.

J’ai donne aux deux sessions la meme spec de dashboard : cartes de stats (MRR, ARR, taux de churn), onglets de revenu par tier, ventilation des clients, analytics de support, mode clair/sombre, donnees mockees, servies sur localhost.

	Plan local	Ultraplan
Temps de planification	~12 minutes	~1 minute
Temps d’execution	~30 minutes	~10 minutes
Total horloge	~45 minutes	~11 minutes
Tokens locaux consommes	131k	82k
Format du plan	Scrollback du terminal	Document structure + diagrammes
Surface de revue	Dialogue texte	Commentaires, reactions, sections

Les deux ont produit des dashboards visuellement similaires. Mais Ultraplan a livre environ 4x plus rapidement de bout en bout, a consomme moins de tokens locaux, et a produit un plan reellement agreable a reviewer.

Le calcul des tokens est interessant. Oui, Ultraplan a consomme des tokens cloud qui n’apparaissent pas dans /cost — ma meilleure estimation est d’environ 50k de tokens de planification supplementaires cote cloud. Mais comme le plan est tellement plus precis, la phase d’execution locale a consomme moins de tokens que la version avec plan local. Au net, c’est plausiblement moins cher par feature livree, pas seulement plus rapide.

Pourquoi l’execution est plus rapide

Cette partie m’a surpris. Je m’attendais a une meilleure planification. Je ne m’attendais pas a ce que l’execution soit, elle aussi, drastiquement plus rapide.

Ma theorie de travail : quand un agent local recoit un plan vague, il passe beaucoup de cycles a re-deriver l’intention — relire le brief, remettre en question la structure, explorer la codebase en plein build. Quand le plan est sans ambiguite et structure (“creer le fichier X avec ces exports, modifier le fichier Y a cette fonction, ajouter la migration Z”), l’agent arrete de reflechir et execute. Moins de reflexion, c’est moins d’appels d’outils, moins de lectures, moins de diffs reconsideres.

C’est la meme dynamique que celle d’un ingenieur senior qui transmet a un junior une spec parfaite plutot qu’une spec floue. Le travail lui-meme prend le meme nombre de frappes au clavier, mais l’errance disparait.

“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” — Lincoln

(« Donnez-moi six heures pour abattre un arbre et je passerai les quatre premieres a affuter la hache. »)

Ultraplan, c’est une hache plus affutee.

Ce qui se passe sous le capot

Dimension	Plan local	Ultraplan
Runtime	Votre terminal	Conteneur cloud Anthropic
Modele	Celui de votre session	Toujours Opus 4.6
Approche	Agent unique, pensee lineaire	Multi-agents : 3 explorateurs + 1 critique
Plafond de compute	Limites de votre session	Plafond dur de 30 minutes
Terminal bloque ?	Oui, le mode plan verrouille la session	Non — le terminal est libre pendant que le cloud planifie
Surface de revue	Texte	Document avec commentaires et reactions

La piece multi-agents est le choix architectural le plus interessant. Trois agents d’exploration travaillent en parallele — vraisemblablement avec des prompts ou des points de depart differents — suivis d’une passe de critique. C’est une vraie boucle agentique plan-puis-critique, pas juste une chaine de pensee mono-agent plus longue. C’est le meme pattern qui rend le parallel-then-merge si efficace dans les workflows de recherche, applique a la planification de code.

Votre session de terminal reste aussi debloquee pendant que le cloud planifie, ce qui veut dire que vous pouvez continuer a travailler — meme si en pratique je prefere ouvrir une nouvelle session et garder les contextes propres pour le hand-off final.

Prerequis et ecueils

Il vous faut un remote Git. Ultraplan ne fonctionne que sur les projets pousses sur un host Git (typiquement GitHub) — le planificateur cloud doit cloner votre repo pour l’explorer. Si vous essayez d’Ultraplaner un projet purement local, Claude Code vous dira d’initialiser et de pousser d’abord. C’est une configuration unique, mais c’est une exigence stricte.

Il vous faut un abonnement Pro ou Max. Ultraplan n’est pas disponible avec la facturation API. J’ai essaye. La surface de planification cloud est reservee aux comptes par abonnement — probablement parce qu’elle est facturee sur le meme pool de compute que Claude Code sur le web.

Les skills ne sont pas toujours invoquees automatiquement. Ca m’a piege sur une vraie tache — j’ai demande a Ultraplan de construire un document de recherche avec des diagrammes personnalises, en m’attendant a ce qu’il utilise ma skill de visualisation. A la place, il a produit des diagrammes Mermaid generiques. J’ai du laisser un commentaire sur le plan disant « utilise ma skill de visualisation » et meme la, il m’a demande de nommer la skill explicitement. Lecon : soyez explicite dans votre prompt Ultraplan sur les skills que vous voulez le voir utiliser, meme s’il peut techniquement les voir dans le repo.

La visibilite sur les tokens est mauvaise. /cost ne reflete pas les tokens de planification cloud. Ma consommation sur le plan max a augmente d’environ 1 % par session Ultraplan dans mes experiences, mais il n’y a pas encore de ventilation par session. J’aimerais voir cela s’ameliorer — connaitre le cout cote cloud est important pour decider quand y avoir recours.

L’authentification peut etre instable. J’ai croise quelques erreurs d’auth transitoires pendant les tests. Relancer a chaque fois suffisait, mais c’est clairement encore en research preview.

Quand l’utiliser

Ultraplan n’est pas le bon outil pour chaque prompt. Il est plus lent a demarrer (il faut un push Git, il faut basculer sur un onglet web), et il consomme plus de tokens qu’un plan local rapide. Le point d’equilibre se situe quelque part autour des taches qui auraient pris plus de 10 minutes a planifier en local.

Mon heuristique actuelle :

Utiliser Ultraplan pour : des nouvelles features qui touchent plusieurs fichiers, des refactors qui traversent les couches, des dashboards ou des pages completes construits a partir de zero, tout ce ou vous voulez un document structure que vous pourrez partager avec un coequipier ou retrouver plus tard.
Eviter Ultraplan pour : des bugfixes mono-fichier, des edits rapides, des spikes exploratoires, tout ce ou vous etes encore en train de figurer ce que vous voulez.

Combinez-le avec ultrathink et vous brulerez une session rapidement — mais pour la bonne tache, ce sont les 11 minutes les moins cheres que vous passerez de la semaine.

Ce que ca veut dire

Ultraplan est une petite feature en surface — un slash command, un onglet web, une teleportation retour. Mais en dessous, c’est une declaration architecturale forte de la part d’Anthropic : la planification merite son propre runtime, son propre modele dedie et sa propre topologie multi-agents. L’execution et la planification ont des profils de cout differents, des tolerances de latence differentes et des patterns de raisonnement differents. Les separer sur deux runtimes — cloud pour la planification, local pour l’execution — est exactement le genre de separation qui devient evidente avec le recul.

Je m’attends a ce que ce pattern se generalise. Les prochaines etapes logiques :

L’execution cote cloud comme option de premier rang, le terminal local devenant un client leger pour la revue et l’approbation
Des documents de plan persistants qui vivent a cote du repo, versionnes, commentables, comme des ADR mais generes et maintenus par des agents
Des topologies multi-agents au-dela du plan/critique — agents d’implementation paralleles, agents de revue paralleles, tous coordonnes via la meme surface de revue web
Une meilleure telemetrie de cout pour qu’on puisse raisonner sur les arbitrages cloud-vs-local sans deviner

Pour l’instant, Ultraplan est la fonctionnalite Claude Code la plus interessante livree ce trimestre. Si vous faites quoi que ce soit de non trivial dans votre terminal aujourd’hui, poussez votre repo, tapez ultraplan et regardez ce qui se passe. La premiere fois qu’il teleporte un plan structure de 30 sections dans votre session en 90 secondes, vous comprendrez pourquoi ca compte.