Claude Code Ultraplan — Planning wandert in die Cloud

Planning war schon immer der Moment mit dem höchsten Hebel im agentischen Coding. Stimmt der Plan, ist die Ausführung weitgehend mechanisch. Stimmt er nicht, verbringt man die nächsten zwei Stunden damit, einem Agent zuzusehen, wie er sich selbstbewusst in eine Sackgasse manövriert.

Anthropic hat gerade ein leise bedeutendes Claude Code Feature veröffentlicht, das genau diese Erkenntnis konsequent zu Ende denkt: Ultraplan. Statt den Plan-Modus lokal laufen zu lassen, wird die Session an eine in der Cloud gehostete Opus 4.6 Instanz ausgelagert, in der mehrere Agents parallel die Codebase erkunden und einen tieferen, strukturierteren Plan liefern, als das Terminal je könnte — meist in einem Bruchteil der Zeit.

Ich teste es seit ein paar Tagen. Es ist nicht nur schnelleres Planen. Es macht auch die Ausführungsphase spürbar schneller, weil der resultierende Plan so eindeutig ist, dass der lokale Agent gar nicht mehr nachdenken muss — er baut einfach.

Was Ultraplan tatsächlich ist

Ultraplan lagert die Planning-Session in Anthropics Cloud-Container-Runtime aus, wo ein kleiner Schwarm an Agents hochgefahren wird:

Drei parallele Exploration-Agents, die durch die Codebase laufen, vorhandene Skills und Skripte lesen und Lösungsansätze vorschlagen
Ein Critique-Agent, der die Vorschläge auf Herz und Nieren prüft
Opus 4.6 als zugrundeliegendes Modell, unabhängig davon, was die lokale Session verwendet

Das Ergebnis ist ein strukturierter, dokumentartiger Plan — Kontext, was bereits existiert, der neue Ansatz, zu erstellende Dateien, zu ändernde Dateien und ein abschließender Verifikationsabschnitt. Manchmal sind Diagramme dabei. Und entscheidend: Er lebt auf einer Web-Review-Oberfläche, auf der man Kommentare und Emoji-Reaktionen an einzelnen Abschnitten hinterlassen kann — nicht nur Text in den Terminal-Scrollback kippen.

Wenn man zufrieden ist, klickt man auf Approve Plan und der Plan teleportiert sich zurück in die Terminal-Session, bereit zur lokalen Ausführung. Oder man führt ihn remote in der Cloud aus und reviewt die Ergebnisse später.

So löst man es aus

Zwei Wege:

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

# Oder einfach das Schlüsselwort einbauen
ultraplan refactor the auth service to use the new Redis cache

Das Schlüsselwort leuchtet auf die gleiche Weise auf wie ultrathink — Claude Code erkennt es und fragt, ob die Planning-Session in die Cloud gesendet werden soll. Sagt man ja, bekommt man einen Link, um den Fortschritt in Claude Code on the web zu beobachten.

Man kann auch mit einem bestehenden lokalen Plan starten und ihn nachträglich zu Ultraplan promoten, wenn man unterwegs entscheidet, dass man die schwerere Variante haben will.

Eine wichtige Einschränkung: Das funktioniert ausschließlich in der CLI. Die Desktop-App und die VS Code Extension lösen Ultraplan nicht aus — sie fallen still auf nichts zurück. Wer Ultraplan will, muss im Terminal sein.

Der Side-by-Side-Test

Die eindrucksvollste Demo ist es, denselben Prompt zweimal laufen zu lassen — einmal im lokalen Plan-Modus, einmal mit Ultraplan — und zuzusehen, was passiert.

Ich habe beiden Sessions dieselbe Dashboard-Spezifikation gegeben: Stats Cards (MRR, ARR, Churn Rate), Revenue Tabs nach Tier, Customer Breakdowns, Support Analytics, Light/Dark Mode, Mock-Daten, ausgeliefert auf localhost.

	Local Plan	Ultraplan
Zeit zum Planen	~12 Minuten	~1 Minute
Zeit zur Ausführung	~30 Minuten	~10 Minuten
Gesamte Wall-Clock-Zeit	~45 Minuten	~11 Minuten
Lokal verbrauchte Tokens	131k	82k
Plan-Format	Terminal-Scrollback	Strukturiertes Doc + Diagramme
Review-Oberfläche	Text-Dialog	Kommentare, Reaktionen, Abschnitte

Beide produzierten visuell ähnliche Dashboards. Aber Ultraplan war end-to-end ungefähr 4x schneller, verbrauchte weniger lokale Tokens und lieferte einen Plan, dessen Review tatsächlich angenehm war.

Die Token-Mathematik ist interessant. Ja, Ultraplan hat Cloud-Tokens verbraucht, die in /cost nicht auftauchen — meine beste Schätzung sind etwa 50k zusätzliche Planning-Tokens auf der Cloud-Seite. Aber weil der Plan so viel schärfer ist, hat die lokale Ausführungsphase weniger Tokens verbraucht als die Local-Plan-Variante. Unter dem Strich ist es plausibel günstiger pro fertigem Feature, nicht nur schneller.

Warum die Ausführung schneller wird

Dieser Teil hat mich überrascht. Besseres Planen hatte ich erwartet. Dass die Ausführung dramatisch schneller wird, nicht.

Meine Arbeitstheorie: Wenn ein lokaler Agent einen vagen Plan bekommt, verbringt er viele Zyklen damit, die Intention neu herzuleiten — das Briefing erneut zu lesen, die Struktur in Frage zu stellen, mitten im Bauen die Codebase zu erkunden. Wenn der Plan eindeutig und strukturiert ist (“erstelle Datei X mit diesen Exports, ändere Datei Y an dieser Funktion, füge Migration Z hinzu”), hört der Agent auf zu denken und führt einfach aus. Weniger Denken bedeutet weniger Tool Calls, weniger Reads, weniger erneut hinterfragte Diffs.

Es ist dieselbe Dynamik wie bei einem Senior Engineer, der einem Junior eine perfekte Spezifikation übergibt, statt einer vagen. Die eigentliche Arbeit braucht dieselbe Anzahl an Tastenanschlägen, aber das Umherirren verschwindet.

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

“Gebt mir sechs Stunden, um einen Baum zu fällen, und ich verbringe die ersten vier damit, die Axt zu schärfen.”

Ultraplan ist eine schärfere Axt.

Was unter der Haube passiert

Dimension	Local Plan	Ultraplan
Runtime	Eigenes Terminal	Anthropic Cloud Container
Modell	Was die Session gerade nutzt	Immer Opus 4.6
Ansatz	Single Agent, lineares Denken	Multi-Agent: 3 Explorer + 1 Critic
Compute-Limit	Limits der eigenen Session	30-Minuten Hard Cap
Terminal blockiert?	Ja, der Plan-Modus sperrt die Session	Nein — das Terminal ist frei, während die Cloud plant
Review-Oberfläche	Text	Doc mit Kommentaren und Reaktionen

Das Multi-Agent-Stück ist die architektonisch interessanteste Entscheidung. Drei Exploration-Agents, die parallel arbeiten — vermutlich mit unterschiedlichen Prompts oder unterschiedlichen Startpunkten — gefolgt von einem Critique-Pass. Das ist eine echte agentische Plan-then-Critique-Schleife, nicht nur eine längere Single-Agent Chain of Thought. Dasselbe Muster, das Parallel-then-Merge in Research-Workflows so wirksam macht, angewendet auf Code-Planning.

Die Terminal-Session bleibt zudem unblockiert, während die Cloud plant — man kann also weiterarbeiten. In der Praxis starte ich allerdings lieber eine frische Session und halte die Kontexte sauber für die spätere Übergabe.

Voraussetzungen und Stolperfallen

Man braucht ein Git Remote. Ultraplan funktioniert nur bei Projekten, die auf einen Git Host (in der Regel GitHub) gepusht sind — der Cloud-Planner muss das Repo klonen, um es zu erkunden. Versucht man, ein rein lokales Projekt mit Ultraplan zu bearbeiten, fordert Claude Code einen auf, erst zu initialisieren und zu pushen. Das ist ein einmaliges Setup, aber harte Voraussetzung.

Man braucht ein Pro oder Max Abo. Ultraplan ist nicht über API-Billing verfügbar. Ich habe es probiert. Die Cloud-Planning-Oberfläche ist auf Subscription-Accounts beschränkt — vermutlich, weil sie gegen denselben Compute-Pool wie Claude Code on the web abgerechnet wird.

Skills werden nicht immer automatisch aufgerufen. Das hat mich bei einer echten Aufgabe kalt erwischt — ich hatte Ultraplan gebeten, ein Research-Doc mit eigenen Diagrammen zu bauen, in der Erwartung, dass es meinen Visualization-Skill verwendet. Stattdessen produzierte es generische Mermaid-Diagramme. Ich musste einen Kommentar im Plan hinterlassen: “use my visualization skill”, und selbst dann fragte es mich, den Skill explizit beim Namen zu nennen. Lehre: Im Ultraplan-Prompt explizit angeben, welche Skills verwendet werden sollen, auch wenn diese im Repo technisch sichtbar sind.

Die Token-Sichtbarkeit ist schlecht. /cost spiegelt die Cloud-Planning-Tokens nicht wider. Mein Max-Plan-Verbrauch ist in den Experimenten pro Ultraplan-Session um etwa 1% gestiegen, aber es gibt noch keine Aufschlüsselung pro Session. Ich würde mir hier Verbesserungen wünschen — die Cloud-seitigen Kosten zu kennen, ist wichtig, um zu entscheiden, wann man danach greift.

Authentication kann zickig sein. Ich bin beim Testen auf ein paar transiente Auth-Fehler gestoßen. Erneutes Ausführen hat es jedes Mal gelöst, aber es ist klar erkennbar noch im Research Preview.

Wann man es einsetzt

Ultraplan ist nicht das richtige Werkzeug für jeden Prompt. Es braucht länger zum Starten (Git Push nötig, Kontextwechsel auf einen Web-Tab) und verbraucht mehr Tokens als ein schneller lokaler Plan. Der Break-even liegt irgendwo bei Aufgaben, deren lokales Planning 10+ Minuten gebraucht hätte.

Meine aktuelle Heuristik:

Ultraplan einsetzen für: neue Features, die mehrere Dateien berühren; Refactorings, die sich über mehrere Schichten ziehen; Dashboards oder ganze Seiten, die von Grund auf gebaut werden; alles, wo man ein strukturiertes Doc haben will, das man mit einem Teammitglied teilen oder später wieder aufgreifen kann.
Ultraplan überspringen für: Single-File-Bugfixes, schnelle Edits, explorative Spikes, alles, wo man noch herausfindet, was man eigentlich will.

Kombiniert mit ultrathink brennt man eine Session schnell durch — aber für die richtige Aufgabe sind das die günstigsten 11 Minuten der ganzen Woche.

Was das bedeutet

An der Oberfläche ist Ultraplan ein kleines Feature — ein Slash Command, ein Web-Tab, ein Teleport zurück. Darunter ist es jedoch ein bedeutsames architektonisches Statement von Anthropic: Planning ist eine eigene Runtime, ein eigenes Modell und eine eigene Multi-Agent-Topologie wert. Ausführung und Planning haben unterschiedliche Kostenprofile, unterschiedliche Latenztoleranzen und unterschiedliche Reasoning-Muster. Sie auf zwei Runtimes aufzuteilen — Cloud fürs Planen, lokal für die Ausführung — ist genau die Art von Trennung, die im Rückblick offensichtlich wirkt.

Ich erwarte, dass sich dieses Muster ausbreitet. Die nächsten logischen Schritte:

Cloud-seitige Ausführung als First-Class-Option, wobei das lokale Terminal zum Thin Client für Review und Approval wird
Persistente Plan-Dokumente, die neben dem Repo leben — versionskontrolliert, kommentierbar, wie ADRs, aber von Agents generiert und gepflegt
Multi-Agent-Topologien jenseits von Plan/Critique — parallele Implementierungs-Agents, parallele Review-Agents, alle koordiniert über dieselbe Web-Review-Oberfläche
Bessere Kosten-Telemetrie, damit man Cloud-vs-Local-Tradeoffs abwägen kann, ohne raten zu müssen

Im Moment ist Ultraplan das interessanteste Claude Code Feature dieses Quartals. Wer heute irgendetwas Nicht-Triviales im Terminal macht, sollte sein Repo pushen, ultraplan tippen und beobachten, was passiert. Beim ersten Mal, wenn ein strukturierter 30-Sektionen-Plan in 90 Sekunden zurück in die Session teleportiert wird, versteht man, warum das wichtig ist.