Ich habe den Ultra Plan von Claude Code getestet — Hier ist die Wahrheit
Ich war mitten in einer Dependency-Migration — tRPC v10 gegen v11 in einem Monorepo mit 47 Route-Definitionen austauschen — als ein Freund eine Nachricht in unserem Discord hinterliess: "Hast du /ultraplan schon ausprobiert?"
Meine ehrliche erste Reaktion? Skepsis. Ich hatte den lokalen Planmodus von Claude Code seit Monaten religios genutzt. Shift+Tab, den Plan ueberpruefen, in den Bearbeitungsmodus wechseln, ausfuehren. Der Rhythmus war mir in Fleisch und Blut uebergegangen. Warum sollte ich diesen Prozess an eine cloudbasierte Planungssitzung abgeben, wenn mein Terminal-Workflow bereits schnell war?
Dann fuehrte ich /ultraplan migrate all tRPC v10 routes to v11 with backward-compatible type exports aus und beobachtete etwas, das ich nicht erwartet hatte. Innerhalb von Sekunden lieferte mir mein Terminal eine URL. Ich oeffnete sie im Browser. Und dort sass ein strukturierter Implementierungsplan, der nicht nur die Dateien auflistete, die geaendert werden mussten — er kartierte die Dependency-Ketten zwischen Routes, markierte drei brechende Type-Signatures, die ich nicht bedacht hatte, und generierte ein Mermaid-Diagramm, das die Migrationsreihenfolge zeigte, die Testfehler auf dem Weg minimieren wuerde.
Mein lokaler Planmodus hatte das nie getan. Kein einziges Mal.
Das war vor zwei Wochen. Seitdem habe ich Ultra Plan bei zehn verschiedenen Prompts eingesetzt — einfache Modellwechsel, komplexe Refactors, Greenfield Scaffolding, Sicherheitsaudits — und es bei jedem einzelnen gegen den lokalen Planmodus getestet. Was ich herausfand, war nuancierter als "Ultra Plan ist besser." Die Wahrheit umfasst drei versteckte Planungsmodi, ein AB testing-System, von dem die meisten Benutzer nicht wissen, dass es existiert, und eine sehr spezifische Reihe von Szenarien, in denen Ultra Plan wirklich transformativ ist, gegenueber Faellen, in denen es nur eine huebschere Oberflaeche fuer die gleiche Ausgabe ist.
Hier ist alles, was ich gelernt habe.
Was Ultra Plan tatsaechlich ist (und warum es existiert)
Bevor ich zu den Testergebnissen komme, braucht ihr das richtige mentale Modell. Denn Ultra Plan ist nicht einfach "Planmodus, aber in der Cloud." Die Architektur ist grundlegend anders, und diesen Unterschied zu verstehen, veraendert, wie man es nutzt.
Wenn ihr den lokalen Planmodus mit Shift+Tab in Claude Code ausfuehrt, findet die Planung innerhalb eurer Terminalsitzung statt. Gleiches Kontextfenster. Gleiche Modellinstanz. Gleiche Einschraenkungen. Die KI liest eure Codebase, denkt ueber die Aenderungen nach und praesentiert einen Plan — alles innerhalb der Grenzen eurer aktuellen Konversation.
Ultra Plan bricht dieses Modell vollstaendig auf. Wenn ihr /ultraplan gefolgt von eurem Prompt eingebt, startet Claude Code eine dedizierte Planungssitzung in Anthropic's Cloud Container Runtime — was sie CCR nennen. Diese Remote-Sitzung erhaelt Opus 4.6, bis zu 30 Minuten dedizierte Rechenzeit und Zugriff auf euer Repository ueber einen cloud-synchronisierten Snapshot. Die Planung findet ausserhalb eures Rechners statt, in einer Umgebung, die speziell fuer tiefgehende Analyse gebaut wurde.
Der praktische Unterschied? Euer Terminal bleibt frei. Waehrend Ultra Plan eure Migrationsstrategie in der Cloud durchrechnet, koennt ihr weiter coden, Tests ausfuehren oder eine andere Ultra Plan-Sitzung fuer eine voellig andere Aufgabe starten. Ich hatte drei Ultra Plan-Sitzungen gleichzeitig laufen, waehrend ich lokal ein CSS-Problem debuggte. Versucht das mal mit dem lokalen Planmodus.
Sobald der Plan fertig ist, erhaltet ihr eine Sitzungs-URL, die sich im Browser oeffnet. Und hier weicht die Erfahrung deutlich von allem ab, was im Terminal moeglich ist.
Die Web-UI, die veraendert, wie ihr Plaene prueft
Ich sage es direkt: Die Weboberflaeche ist die groesste Verbesserung der Lebensqualitaet, die Ultra Plan mitbringt. Und das sage ich als jemand, der im Terminal lebt.
Wenn ein Plan in eurem Browser erscheint, schaut ihr auf ein reichhaltiges Dokument — keine Wand aus Markdown, die durch euer Terminal scrollt. Ueberschriften. Einklappbare Abschnitte. Inline-Codebloeche mit Syntaxhervorhebung. Und entscheidend: zwei Funktionen, die kollaborative Planung tatsaechlich funktionieren lassen: Inline-Kommentare zu bestimmten Teilen des Plans und Emoji-Reaktionen fuer schnelle Signalisierung.
Das klingt trivial. Ist es nicht.
Hier ist der Grund. Wenn ich einen Plan im Terminal ueberpreufe, sieht meine Feedback-Schleife so aus: den Plan lesen, zurueck zu der Stelle scrollen, mit der ich nicht einverstanden bin, tippen "eigentlich, fuer Schritt 3 wuerde ich lieber das Repository Pattern statt direkter Queries verwenden", warten, bis die KI den gesamten Plan neu generiert, das ganze Ding erneut lesen. Mit der Web-UI klicke ich auf Schritt 3, tippe meinen Kommentar inline und bitte um eine gezielte Ueberarbeitung. Die KI aktualisiert diesen Abschnitt, ohne den Rest zu beruehren. Die Iterationsgeschwindigkeit ist dramatisch schneller.
Die Mermaid-Diagramme sind inkonsistent — manchmal erscheinen sie, manchmal nicht (mehr dazu gleich). Aber wenn sie auftauchen, sind sie wirklich nuetzlich. Fuer die tRPC-Migration generierte Ultra Plan ein Dependency-Flussdiagramm, das zeigte, welche Routes von gemeinsamen Type-Definitionen abhaengig waren, was bedeutete, dass ich auf einen Blick sehen konnte, dass die Migration von userRouter vor authRouter drei Downstream-Consumer beschaedigen wuerde. Diese Visualisierung haette mich zwanzig Minuten manueller Arbeit gekostet.
Nachdem ihr einen Plan genehmigt — mit oder ohne Ueberarbeitungen — erhaltet ihr drei Optionen:
- In der Cloud ausfuehren — der Plan laeuft remote und kann direkt einen PR oeffnen
- Hier implementieren — den Plan zurueck in eure aktuelle Terminalsitzung teleportieren
- Neue Sitzung starten — eure aktuelle Konversation loeschen und mit dem Plan als Kontext neu beginnen
Ich nutze Option 2 in etwa 80% der Faelle. Der Plan kommt als strukturierter Kontext in meinem Terminal an, und ich fahre lokal mit der Ausfuehrung fort, wo ich volle Kontrolle ueber Dateioperationen, Testlaeufe und den Git-Workflow habe. Option 1 ist verlockend fuer unkomplizierte Aufgaben, aber ich habe festgestellt, dass die Ausfuehrung immer noch von lokaler Aufsicht profitiert — besonders wenn der Plan Dateien betrifft, die sich seit der Erstellung des Cloud-Snapshots geaendert haben.
Trotzdem ist der Cloud-Ausfuehrungspfad die Richtung, in die Ultra Plan geht. Und fuer Teams, die eine Planning-to-PR-Pipeline mit minimalem menschlichem Eingriff wollen, ist es bereits fast soweit.
Zehn Prompts, zwei Modi, ein ehrlicher Vergleich
Ueber Features zu reden ist einfach. Was zaehlt, ist die Leistung. Also habe ich die gleichen zehn Prompts sowohl durch Ultra Plan als auch durch den lokalen Planmodus geschickt und die Ausgabe in vier Dimensionen verglichen: Geschwindigkeit, Planqualitaet, Risikoerkennung und Umsetzbarkeit.
Hier ist, was ich getestet habe:
Einfache Aufgaben:
- Qwen 3.5 durch Gemma 4 als lokales Inferenzmodell ersetzen
- Einen Dark-Mode-Toggle zu einer bestehenden React-Komponente hinzufuegen
- Eine Datenbankspalte mit Migration umbenennen
Mittlere Komplexitaet: 4. Authentifizierungs-Middleware von sitzungsbasiert auf JWT refactoren 5. Rate Limiting zu allen API-Endpunkten mit konfigurierbaren Schwellenwerten hinzufuegen 6. Ein Prisma-Schema von PostgreSQL zu MySQL migrieren
Hohe Komplexitaet: 7. tRPC v10 auf v11 in einem Monorepo upgraden 8. Eine Multi-Tenant-Datenisolationsschicht implementieren 9. End-to-End-Verschluesselung fuer Benutzernachrichten hinzufuegen 10. Eine Codebase auf OWASP Top 10-Schwachstellen auditieren
Die Ergebnisse teilten sich sauber entlang der Komplexitaetslinien — aber nicht so, wie ich es erwartet hatte.
Wo Ultra Plan dem lokalen Planmodus entsprach (und nicht mehr)
Fuer Prompts 1 bis 3 — die einfachen Aufgaben — bot Ultra Plan null nennenswerten Vorteil gegenueber dem lokalen Planmodus. Die Plaene waren strukturell aehnlich. Die gleichen Dateien wurden identifiziert. Die gleichen Schritte wurden vorgeschlagen. Der einzige Unterschied war die Praesentation: Die Ausgabe von Ultra Plan sah im Browser huebscher aus.
Der Wechsel von Qwen 3.5 zu Gemma 4 generierte nahezu identische Plaene in beiden Modi. Lokaler Plan: Modellkonfiguration aendern, Inferenz-Endpunkt aktualisieren, Tokenizer-Einstellungen anpassen, testen. Ultra Plan: gleiche Schritte, etwas ausfuehrlichere Beschreibungen, ein Hinweis zur Kompatibilitaetspruefung — aber nichts, was ich nicht selbst bemerkt haette.
Fuer einfache Aufgaben fuegt der zusaetzliche Roundtrip zur Cloud Latenz hinzu, ohne Erkenntnisse hinzuzufuegen. Der lokale Planmodus erledigte diese in 15-30 Sekunden. Ultra Plan brauchte 45-90 Sekunden fuer das gleiche Ergebnis, weil die Cloud-Sitzung starten, den Repo-Snapshot synchronisieren und die Web-UI rendern muss.
Meine Empfehlung: Wenn ihr die Aenderung in einem Satz beschreiben koennt und bereits wisst, welche Dateien betroffen sind, bleibt beim lokalen Planmodus. Der Geschwindigkeitsvorteil ist real.
Wo Ultra Plan voraus war — und um wie viel
Prompts 4 bis 6 — mittlere Komplexitaet — zeigten die erste bedeutsame Luecke. Ultra Plan begann Dinge aufzufangen, die der lokale Planmodus uebersah.
Die JWT-Migration (Prompt 4) ist ein gutes Beispiel. Der lokale Planmodus gab mir einen vernuenftigen Plan: JWT-Utility erstellen, Auth-Middleware aktualisieren, Login-Endpunkt anpassen, um Tokens auszustellen, Token-Refresh-Logik hinzufuegen. Solide. Korrekt. Aber er uebersah das Session-Bereinigungs-Problem — bestehende Benutzer hatten aktive Sessions, die waehrend des Migrationsfensters invalidiert werden mussten. Er erwaehnte auch nicht die Notwendigkeit, die CORS-Konfiguration fuer das neue Authorization-Header-Muster zu aktualisieren.
Ultra Plan fing beides auf. Der Plan enthielt einen dedizierten Migrationsschritt fuer aktive Sessions, eine Rollback-Strategie, falls die JWT-Verifizierung fuer einen Schwellenwert an Benutzern fehlschlug, und einen CORS-Update-Abschnitt. Die Risikoerkennung war merklich tiefgruendiger.
Fuer die Prisma-Migration (Prompt 6) schlug der lokale Planmodus eine geradlinige Schema-Neufassung vor. Ultra Plan markierte vier MySQL-spezifische Stolperfallen: den @db.Text-Typunterschied, das Fehlen nativer Array-Unterstuetzung, die eine Join-Tabelle erfordert, den Unterschied bei der Gross-/Kleinschreibung bei Zeichenkettenvergleichen und eine Indexlaengenbeschraenkung, die einen meiner zusammengesetzten Indizes gebrochen haette. Drei dieser vier haetten Laufzeitfehler verursacht, fuer deren Debugging ich Stunden gebraucht haette.
Die Luecke vergroesserte sich bei hoher Komplexitaet weiter. Die tRPC v10-zu-v11-Migration (Prompt 7) war der Punkt, an dem Ultra Plan seinen Wert wirklich unter Beweis stellte. Der lokale Planmodus produzierte einen vernuenftigen Migrationsleitfaden. Ultra Plan produzierte etwas, das ich nur als Engineering-Dokument beschreiben kann — komplett mit Dependency-Reihenfolge, Typkompatibilitaetsanalyse, einer Liste veralteter APIs, die ich nutzte, mit ihren v11-Ersetzungen und einer phasenweisen Rollout-Strategie, die es mir ermoeglichte, Route fuer Route zu migrieren statt alles auf einmal.
Das Sicherheitsaudit (Prompt 10) zeigte den dramatischsten Unterschied. Der lokale Planmodus identifizierte oberflaechliche Probleme: fehlende Eingabevalidierung, ein paar SQL-Injection-Vektoren, hartcodierte Secrets. Ultra Plan fand diese plus drei tiefer liegende Probleme: eine unsichere direkte Objektreferenz im Benutzerprofil-Endpunkt, eine Race Condition im Passwort-Reset-Flow, die Token-Wiederverwendung ermoeglichen koennte, und ein fehlendes Rate Limit am Login-Endpunkt, das ihn anfaellig fuer Credential Stuffing machte. Der lokale Plan markierte 6 Probleme. Ultra Plan markierte 11.
Aber hier wird die Geschichte kompliziert.
Die drei versteckten Modi, ueber die niemand spricht
Nach der Durchfuehrung dieser Tests stoerte mich die Inkonsistenz. Warum generierte Ultra Plan Mermaid-Diagramme fuer manche Prompts, aber nicht fuer andere? Warum produzierte das Sicherheitsaudit eine Multi-Perspektiven-Analyse, waehrend der Modellwechsel im Grunde die gleiche Ausgabe lieferte wie der lokale Modus?
Ich grub im Claude Code-Quellcode — speziell den geleakten System-Prompts, die nach dem npm Source-Map-Vorfall im Maerz 2026 aufgetaucht waren — und fand etwas, das alles erklaert.
Ultra Plan fuehrt nicht einen Planungsmodus aus. Es fuehrt drei aus. Und Anthropic weist sie dynamisch zu, unsichtbar, basierend auf serverseitiger Konfiguration.
Simple Plan ist die Basislinie. Es ist strukturell aehnlich zum lokalen Planmodus — eine geradlinige Analyse, die Dateien identifiziert, Schritte vorschlaegt und einen sauberen Plan ausgibt. Keine Diagramme. Keine Multi-Perspektiven-Analyse. Wenn ihr einen Simple Plan erhaltet, bekommt ihr im Grunde den lokalen Planmodus mit einer huebscheren UI und Cloud-Ausfuehrung. Das war es, was ich fuer die einfachen Aufgaben erhielt.
Visual Plan fuegt Diagramme hinzu. Gleiche analytische Tiefe wie Simple Plan, aber mit Mermaid- und Asy-Diagrammgenerierung als zusaetzliche Schicht. Das Dependency-Flussdiagramm, das ich fuer die tRPC-Migration erhielt? Das war ein Visual Plan. Die Diagramme sind keine Dekoration — sie kodieren strukturelle Beziehungen, die reiner Text nur schwer vermitteln kann. Aber die Analyse selbst ist nicht tiefgruendiger als Simple Plan.
Deep Plan ist derjenige, der das Spiel veraendert. Und er ist derjenige, der meine Sicherheitsaudit-Ergebnisse erklaerte.
Deep Plan aktiviert ein Multi-Agenten-System. Nicht ein Modell, das ueber euer Problem nachdenkt — mehrere spezialisierte Sub-Agents, jeder auf eine andere Dimension fokussiert:
- Ein Agent analysiert Code und Architektur — untersucht die strukturellen Auswirkungen der Aenderung
- Ein Agent lokalisiert alle Dateien, die modifiziert werden muessen — nicht nur die offensichtlichen Ziele, sondern auch Downstream-Consumer und Testdateien
- Ein Agent identifiziert Risiken, Randfaelle und Dependency-Konflikte — der "Was koennte schiefgehen"-Spezialist
- Ein Agent ueberpreuft den gesamten Plan auf logische Konsistenz, fehlende Massnahmen und Ausfuehrungsreihenfolge
Diese Agents laufen parallel, tragen ihre Erkenntnisse zu einem gemeinsamen Kontext bei, und das System synthetisiert ihre Ausgaben zu einem einheitlichen Plan. Das Sicherheitsaudit, das 11 statt 6 Probleme fand? Das war Deep Plan. Der Risiko-Agent markierte speziell die Race Condition im Passwort-Reset-Flow — etwas, das eine Single-Pass-Analyse konsequent uebersieht, weil es das Nachdenken ueber gleichzeitige Zustaende erfordert.
Hier ist der Teil, der mich frustrierte: Ihr koennt nicht waehlen, welchen Modus ihr erhaltet.
Ihr seid Teil eines AB-Tests (und Anthropic weiss es)
Die Moduszuweisung ist nicht zufaellig im Muenzwurf-Sinne. Anthropic steuert sie ueber serverseitige Konfigurationen — im Grunde ein Feature-Flag-System, das bestimmt, welche Planungsvariante jeder Benutzer fuer jede Sitzung erhaelt. Der geleakte Quellcode bestaetigt, dass dies ein gezieltes AB testing-Framework ist.
Anthropic misst mehrere Dinge durch dieses System:
- Benutzerakzeptanzraten fuer jede Planungsvariante — genehmigen und fuehren Benutzer Simple Plans mit der gleichen Rate aus wie Deep Plans?
- Effektivitaet der Planungs-Prompts — welche System-Prompts produzieren Plaene, die Benutzer tatsaechlich umsetzen?
- Modellleistung — die Infrastruktur koennte genutzt werden, um kommende Modellversionen gegeneinander in Live-Planungsszenarien zu testen
Das erklaert, warum meine Erfahrung ueber verschiedene Laeufe hinweg inkonsistent war. Einige meiner Ultra Plan-Sitzungen trafen auf Simple Plan (nahezu identisch mit dem lokalen Modus), waehrend andere auf Deep Plan trafen (dramatisch besser). Ich verglich nicht "Ultra Plan vs lokalen Plan" auf kontrollierte Weise. Ich verglich "welche Variante Anthropic's AB-System mir zugewiesen hat" mit dem lokalen Plan.
Als ich das erkannte, ging ich zurueck und fuehrte die Prompts hoher Komplexitaet mehrfach erneut aus. Die tRPC-Migration produzierte merklich unterschiedliche Plaene ueber drei Laeufe — einen mit Diagrammen, einen ohne, einen mit der Multi-Agenten-Risikoanalyse. Gleicher Prompt. Gleicher Repo-Zustand. Verschiedene Planungsvarianten.
Fuer Benutzer, denen Konsistenz wichtig ist — und wenn ihr Produktionssoftware baut, sollte euch das wichtig sein — ist dies das Wichtigste, was ihr jetzt ueber Ultra Plan verstehen muesst. Die Qualitaetsobergrenze ist wirklich hoch. Die Qualitaetsuntergrenze ist im Grunde der lokale Planmodus mit zusaetzlicher Latenz. Und ihr habt keine Kontrolle darueber, welche ihr erhaltet.
Diese Unsicherheit ist der Grund, warum ich mich vorerst fuer einen bestimmten Workflow entschieden habe, der mir das Beste aus beiden Welten bietet. Aber bevor ich den teile, gibt es noch ein technisches Detail, das es wert ist, verstanden zu werden.
Wie Ultra Plan eure Codebase liest (und wo es Schwaechen hat)
Wenn ihr /ultraplan ausloest, laedt Claude Code nicht euer gesamtes Repository in Anthropic's Cloud hoch. Es erstellt einen Snapshot — eine Punkt-in-Zeit-Kopie, die in die CCR-Umgebung synchronisiert wird, in der die Planungssitzung laeuft. Der Planungsagent liest dann aus diesem Snapshot, als waere es eine lokale Codebase.
Das schafft eine subtile, aber wichtige Einschraenkung: Die Cloud-Sitzung sieht keine Aenderungen, die ihr nach dem Start von Ultra Plan vornehmt. Wenn ihr ein Ultra Plan fuer eine Datenbankmigration ausloest und dann das Schema lokal aendert, waehrend der Plan generiert wird, basiert der Plan auf dem alten Schema. Ich bin da einmal reingefallen — einen Plan genehmigt, der auf eine Spalte verwies, die ich waehrend des Planungsfensters bereits umbenannt hatte.
Das 30-Minuten-Rechenfenster ist fuer die meisten Aufgaben grosszuegig. Meine laengste Ultra Plan-Sitzung — das vollstaendige OWASP-Audit — war in etwa 8 Minuten abgeschlossen. Aber das Fenster ist relevant fuer extrem grosse Repositories, bei denen die initiale Codebase-Analyse erhebliche Zeit beansprucht. Anthropic hat keine Repo-Groessenlimits fuer CCR veroeffentlicht, aber in meinen Tests planten Repos unter 500 MB Quellcode (ohne node_modules und Build-Artefakte) problemlos.
Noch etwas zum Snapshot-Ansatz: Ultra Plan funktioniert am besten mit GitHub-gehosteten Repositories. Die Synchronisation verlaesst sich auf die Remote eures Repos, was bedeutet, dass rein lokale Repos oder Repos mit grossen uncommitteten Aenderungen Plaene auf Basis unvollstaendigen Kontexts produzieren koennen. Ich habe gelernt, immer zu committen und zu pushen, bevor ich /ultraplan fuer etwas Wichtiges ausfuehre.
Wenn ihr lieber jemanden hättet, der einen optimierten Claude Code-Workflow von Grund auf einrichtet — komplett mit Ultra Plan-Integration, benutzerdefinierten Skills und Agent-Orchestrierung — uebernehme ich solche Auftraege. Was ich gebaut habe, koennt ihr hier sehen: fiverr.com/s/EgxYmWD.
Mein tatsaechlicher Workflow — Wie ich Ultra Plan heute nutze
Nach zwei Wochen des Testens ist dies der Workflow, bei dem ich gelandet bin. Es ist nicht "immer Ultra Plan verwenden" oder "komplett ueberspringen." Es ist bedingt, und die Bedingungen sind spezifisch.
Fuer Aufgaben, die ich in einem Satz beschreiben kann und bei denen ich die betroffenen Dateien bereits kenne: Lokaler Planmodus. Kein Cloud-Roundtrip noetig. Shift+Tab, ueberpruefen, ausfuehren. Schnell.
Fuer Aufgaben mit mehr als 5 Dateien, Dependency-Ketten oder brechenden Aenderungen: Ultra Plan. Die Multi-Agenten-Analyse (wenn man Deep Plan erhaelt) faengt Risiken auf, die Single-Pass-Planung konsequent uebersieht. Die Web-UI macht Iteration schneller. Selbst wenn ich Simple Plan erhalte, ist die browserbasierte Ueberprüfung fuer komplexe Plaene komfortabler.
Fuer Sicherheitsaudits und Architektur-Reviews: Ultra Plan, immer. Die Deep Plan-Variante ist dramatisch besser darin, nicht offensichtliche Schwachstellen zu finden. Und da dies Bewertungen mit hohem Einsatz sind, bei denen das Uebersehen eines Randfalls reale Konsequenzen hat, nehme ich lieber die Latenz in Kauf fuer die Chance auf eine tiefgruendigere Analyse.
Fuer zeitkritische Aenderungen, bei denen jede Sekunde zaehlt: Lokaler Planmodus. Der Cloud-Roundtrip von Ultra Plan fuegt 30-90 Sekunden hinzu, bevor man den Plan ueberhaupt sieht. Wenn die Produktion ausgefallen ist und ich schnell einen Fix brauche, ist diese Latenz inakzeptabel.
Fuer Multitasking: Ultra Plan ist unschlagbar. Ich starte regelmaessig zwei oder drei Ultra Plan-Sitzungen fuer verschiedene Aufgaben und ueberprüefe und genehmige sie, sobald sie fertig sind. Dieser parallele Planungs-Workflow ist etwas, das der lokale Modus einfach nicht kann — jeder lokale Plan blockiert euer Terminal, bis er fertig ist.
Der Deep Plan Skill-Workaround
Hier ist der taktischste Punkt in diesem gesamten Beitrag.
Da Anthropic euch nicht waehlen laesst, welche Planungsvariante ihr erhaltet, und Deep Plan mit deutlichem Abstand die besten Ergebnisse liefert, habe ich die Deep Plan-System-Prompt-Struktur extrahiert und in einen benutzerdefinierten Claude Code-Skill umgewandelt.
Der Ansatz: Einen Skill erstellen, der Deep Plans Multi-Agenten-Analysemuster lokal nachahmt. Der Skill weist Claude Code an, den Prompt durch vier sequentielle Linsen zu analysieren — Architekturauswirkung, Dateiidentifikation, Risikobewertung und Planueberprüefung — bevor ein einheitlicher Plan synthetisiert wird. Es ist nicht identisch mit dem echten Deep Plan (der echte parallele Agents in CCR ausfuehrt), aber es naehert sich in meinen Tests 80% der Qualitaetsverbesserung an.
Hier ist das Grundgeruest:
---
name: deep-plan
description: >
Multi-perspective planning for complex code changes.
Trigger when user asks for a detailed plan, migration
strategy, or architecture review.
---
## Deep Plan — Multi-Agent Analysis Skill
### Phase 1: Architecture Analysis
Analyze the requested change from a structural perspective.
Identify affected modules, data flows, and integration points.
Map dependencies between components.
### Phase 2: File Discovery
Locate ALL files that need modification — not just the obvious
targets. Include test files, type definitions, configuration
files, and downstream consumers.
### Phase 3: Risk Assessment
For each proposed change, identify:
- Edge cases that could cause runtime failures
- Breaking changes for existing consumers
- Race conditions or state management issues
- Security implications
- Rollback complexity
### Phase 4: Plan Synthesis & Review
Combine findings from all phases into a unified implementation
plan. Order steps by dependency chain. Flag any phase where
findings conflict. Include rollback procedures for each step.
### Output Format
Use numbered steps with sub-items. Include file paths.
Generate a Mermaid dependency diagram if more than 5 files
are affected. End with a risk summary table.
Das gibt mir Deep Plan-Qualitaetsanalyse auf Abruf, ohne die AB testing-Lotterie. Der Kompromiss ist Geschwindigkeit — das lokale Ausfuehren dauert laenger als ein Single-Pass-Plan, weil es vier sequentielle Analysedurchlaeufe sind. Aber fuer komplexe Aufgaben sparen die zusaetzlichen zwei Minuten Planung Stunden an Debugging.
Ich verwende immer noch den eigentlichen /ultraplan-Befehl fuer Multitasking-Szenarien und wenn ich die Web-UI-Ueberprüefungserfahrung will. Aber fuer meine Planungen mit den hoechsten Einsaetzen — diejenigen, bei denen ich garantierte Tiefe brauche — gibt mir der benutzerdefinierte Skill Kontrolle, die Ultra Plan derzeit nicht bietet.
Was das ueber die Zukunft von Claude Code verraet
Tretet einen Moment von den taktischen Details zurueck und schaut, was Ultra Plan ueber Anthropic's Fahrplan verraet.
Die CCR-Infrastruktur ist nicht nur fuer Planung. Es ist eine universelle Cloud-Ausfuehrungsumgebung. Heute fuehrt sie Planungssitzungen aus. Morgen — und das ist Spekulation basierend auf der Architektur, kein Insiderwissen — koennte sie vollstaendige Implementierungssitzungen, Testsuiten oder sogar Continuous-Integration-Pipelines betreiben, die von Claude Code-Agents angetrieben werden.
Das AB testing-Framework ist ebenso aufschlussreich. Anthropic nutzt live Ultra Plan-Sitzungen, um Planungs-Prompts zu optimieren und zu messen, welche Ansaetze Plaene produzieren, die Benutzer tatsaechlich umsetzen. Das ist eine Live-Feedback-Schleife zur Verbesserung der Planungsfaehigkeit des Modells. Jedes Mal, wenn ihr einen Ultra Plan genehmigt oder ablehnt, tragt ihr Daten zu diesem Optimierungsprozess bei.
Die Multi-Agenten Deep Plan-Architektur ist das zukunftsweisendste Element. Heute betreibt sie drei bis vier spezialisierte Sub-Agents fuer die Planung. Das Muster laesst sich auf jede komplexe Aufgabe verallgemeinern: Implementierungs-Agents, Test-Agents, Dokumentations-Agents, Security-Review-Agents — jeder mit spezialisierten System-Prompts, parallel laufend, ihre Ausgaben synthetisierend. Claude Codes Agent-Teams-Feature macht einiges davon bereits lokal. Die Infrastruktur von Ultra Plan deutet darauf hin, dass Anthropic das Cloud-Rueckgrat baut, um es in grossem Massstab zu betreiben.
Ich erwarte drei Dinge in den naechsten sechs Monaten:
- Vom Benutzer waehlbare Planungsmodi — die AB testing-Phase wird enden, und wir werden explizit zwischen Simple, Visual oder Deep Plan waehlen koennen
- Verbesserungen bei der Cloud-Ausfuehrung — Plaene in CCR mit direkter PR-Erstellung ausfuehren wird der Standard-Pfad fuer Teams
- Persistente Planungssitzungen — die Moeglichkeit, Ultra Plan-Sitzungen zu bookmarken, zu teilen und teamuebergreifend darauf zurueckzukommen
Ob diese Vorhersagen eintreffen oder nicht, die Richtung ist klar: Claude Code wird zu einem Planning-First-Tool, bei dem die Ausfuehrung der einfache Teil ist.
Die ehrlichen Kompromisse, die ihr kennen solltet
Ultra Plan ist kein reines Upgrade. Hier sind die Einschraenkungen, auf die ich im realen Einsatz gestossen bin, und keines der Werbematerialien erwaehnt sie.
Die Snapshot-Verzoegerung ist real. Eure Cloud-Sitzung plant gegen eine eingefrorene Kopie eures Repos. Wenn ihr aktiv entwickelt, waehrend der Plan generiert wird, erhaltet ihr Empfehlungen basierend auf veraltetem Code. Committet und pusht immer, bevor ihr Ultra Plan fuer kritische Aufgaben startet.
Ihr koennt die Planungsvariante nicht waehlen. Das ist meine groesste Frustration. Deep Plan ist deutlich besser als Simple Plan, aber das System entscheidet, welchen ihr bekommt. Fuer ein Feature, das bei Planungen mit hohem Einsatz helfen soll, fuehlt sich die Zufaelligkeit wie ein Designfehler an — selbst wenn die AB testing-Begruendung aus Anthropic's Perspektive Sinn ergibt.
Die Web-UI erfordert Kontextwechsel. Vom Terminal zum Browser zu springen, um einen Plan zu ueberpruefen, bricht den Flow. Ich bin ein tastaturgetriebener Entwickler. Jedes Mal, wenn ich zur Maus greife, um auf einen Planabschnitt im Browser zu klicken, stirbt ein kleiner Teil von mir. Die Inline-Kommentare sind grossartig, sobald man dort ist, aber der Uebergang vom Terminal zum Browser ist abrupt.
Latenz ist wichtig fuer iterative Arbeit. Wenn ich in einem engen Build-Test-Debug-Zyklus bin, schlaegt die 15-Sekunden-Durchlaufzeit des lokalen Planmodus die 45-90 Sekunden von Ultra Plan jedes Mal. Ultra Plan ist ein Tiefdenk-Werkzeug, kein Schnellfeedback-Werkzeug.
Das 30-Minuten-Fenster ist groesstenteils theoretisch. Keine meiner Ultra Plan-Sitzungen ueberschritt 10 Minuten. Aber wenn ihr mit einer aussergewoehnlich grossen Codebase arbeitet oder eine Analyse anfordert, die Tausende von Dateien lesen muss, koennte das Fenster zur Einschraenkung werden. Ich habe es persoenlich nicht erreicht.
Erfordert Claude Code im Web. Ultra Plan benoetigt ein verbundenes Konto und ein GitHub-gehostetes Repository. Wenn ihr mit rein lokalen Repos, privaten GitLab-Instanzen oder in einer Air-Gapped-Umgebung arbeitet, ist Ultra Plan keine Option. Der lokale Planmodus ist dann euer einziger Weg.
Das sind keine Dealbreaker. Es sind die Art von Reibungspunkten, die zaehlen, wenn ihr entscheidet, ob ihr ein neues Tool fuer Produktionsarbeit einsetzt versus nur damit in Nebenprojekten herumspielt. Kennt sie im Voraus.
Solltet ihr Ultra Plan also wirklich nutzen?
Vor zwei Wochen haette ich eine einfache Antwort gegeben. Jetzt ist sie ehrlicher.
Wenn ihr komplexe Refactors, Dependency-Upgrades, Sicherheitsaudits oder Architekturanederungen durchfuehrt — und ihr die AB testing-Lotterie tolerieren koennt — ist Ultra Plan es wert, eurem Workflow hinzugefuegt zu werden. Die Qualitaetsobergrenze, wenn ihr Deep Plan trefft, ist bedeutend hoeher als alles, was der lokale Planmodus produziert. Die Web-UI macht Planueberprüefung und Iteration fuer nicht-triviale Aenderungen schneller. Und die parallele Planungsfaehigkeit ist wirklich einzigartig.
Wenn der Grossteil eurer Arbeit gezielte Aenderungen an bekannten Dateien umfasst, ist der lokale Planmodus immer noch schneller und vorhersagbarer. Fuegt keine Cloud-Latenz fuer Aufgaben hinzu, die keine Cloud-Scale-Analyse benoetigen.
Wenn ihr garantierte Deep Plan-Qualitaet ohne die Zufaelligkeit wollt, baut den benutzerdefinierten Skill, den ich oben beschrieben habe. Fuehrt ihn lokal aus. Akzeptiert den Geschwindigkeitskompromiss fuer die Tiefengarantie.
Und wenn ihr die Art von Entwickler seid, die das Verhalten ihrer Tools genau verfolgt — was, wenn ihr bis hierher gelesen habt, wahrscheinlich auf euch zutrifft — behaltet die AB testing-Muster im Auge. Fuehrt den gleichen Prompt mehrmals aus. Bemerkt, wann ihr Diagramme erhaltet versus wann nicht. Bemerkt, wann die Risikoanalyse oberflaechlich ist versus chirurgisch. Zu verstehen, welche Variante ihr erhaltet, hilft euch, euer Vertrauen in die Ausgabe zu kalibrieren.
Was niemand ueber Ultra Plan sagt, ist dies: Es ist kein fertiges Feature. Es ist eine Forschungsvorschau, die gleichzeitig als Live-Optimierungsplattform fuer Anthropic's Planungsfaehigkeiten dient. Ihr nutzt gleichzeitig ein Tool und trainiert es. Das ist keine Kritik — es ist die Realitaet des Arbeitens an der Grenze der KI-gestuetzten Entwicklung. Aber es bedeutet, dass das Ultra Plan, das ihr heute nutzt, nicht das Ultra Plan sein wird, das ihr in drei Monaten nutzt. Und diese zukuenftige Version, informiert durch Millionen realer Planungssitzungen, wird mit ziemlicher Sicherheit besser sein als alles, was einer von uns mit benutzerdefinierten Skills bauen kann.
Ich behalte /ultraplan in meiner taeglichen Routine. Ich behalte meinen Deep Plan-Skill als Backup. Und ich fuehre beide aus, vergleiche die Ausgaben und speichere jeden Unterschied als Datenpunkt.
Denn die Ingenieure, die ihre Tools tiefgruendig verstehen — nicht nur, was die Tools tun, sondern wie sie unter der Haube funktionieren — sind diejenigen, die das Meiste aus ihnen herausholen. Das galt seit dem ersten Compiler, und es gilt immer noch.
Haeufig gestellte Fragen
Wie starte ich Ultra Plan in Claude Code?
Tippt /ultraplan gefolgt von eurem Planungs-Prompt im Claude Code-Terminal. Die Sitzung startet in Anthropic's Cloud, und ihr erhaltet eine Browser-URL, um den generierten Plan zu ueberpruefen. Ihr benoetigt ein Claude Code on the web-Konto und ein GitHub-gehostetes Repository.
Ist Ultra Plan schneller als der lokale Planmodus?
Bei der Planungsberechnung laeuft Ultra Plan bis zu 2x schneller, weil es dedizierte Cloud-Ressourcen mit Opus 4.6 nutzt. Aber der gesamte Roundtrip — einschliesslich Cloud-Start und Browser-Ueberprüfung — fuegt 30-90 Sekunden hinzu, verglichen mit den 15-30 Sekunden Durchlaufzeit des lokalen Planmodus fuer einfache Aufgaben.
Kann ich zwischen Simple Plan, Visual Plan und Deep Plan waehlen?
Derzeit nicht. Anthropic weist Planungsvarianten ueber serverseitige Konfiguration als Teil ihres AB testing-Frameworks zu. Ihr koennt die Qualitaet von Deep Plan annaehernd erreichen, indem ihr einen benutzerdefinierten Skill erstellt, der das Multi-Agenten-Analysemuster lokal repliziert.
Funktioniert Ultra Plan mit privaten Repositories?
Ultra Plan erfordert ein GitHub-Repository, das ueber euer Claude Code on the web-Konto zugaenglich ist. Rein lokale Repos, GitLab-gehostete Repos und Air-Gapped-Umgebungen werden nicht unterstuetzt. Fuer diese Setups bleibt der lokale Planmodus die einzige Option.
Was passiert mit meinem Code waehrend Ultra Plan-Sitzungen?
Claude Code erstellt einen schreibgeschuetzten Snapshot eures Repositories, der in die Cloud synchronisiert wird. Der Planungsagent analysiert diesen Snapshot — er kann eure lokalen Dateien nicht veraendern. Aenderungen finden nur statt, nachdem ihr den Plan genehmigt und einen Ausfuehrungspfad gewaehlt habt (Cloud oder lokal).
Lass uns zusammenarbeiten
Ihr moechtet KI-Systeme bauen, Workflows automatisieren oder eure Tech-Infrastruktur skalieren? Ich helfe euch gerne.
- Fiverr (massgeschneiderte Builds & Integrationen): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (Enterprise-Loesungen): ramlit.com
- ColorPark (Design & Branding): colorpark.io
- xCyberSecurity (Sicherheitsdienste): xcybersecurity.io
