Ultra Plan is two products wearing one command. For cross-cutting work — refactors that touch a dozen files with dependency chains between them — it's the best planning experience Claude Code has ever shipped. For everything else, it's local plan mode with extra latency and a prettier font. Anthropic calls it a research preview, and after running it against real tasks in my own Laravel codebase, I'd add: it's also a live experiment you're enrolled in without being asked, and knowing that changes how much you should trust any single plan it hands you.
Here's what /ultraplan actually does, where it beat my local plan-mode habit, and where it didn't.
What Ultra Plan actually is
Local plan mode — Shift+Tab in the terminal — plans inside your current session. Same context window, same model instance, same constraints. Ultra Plan breaks that model. Type /ultraplan followed by a prompt and Claude Code clones your GitHub-hosted repository into a temporary cloud container, where Opus 4.6 gets up to 30 minutes of dedicated compute to produce a plan. Your terminal stays free the whole time — you can keep debugging locally or fire off a second planning session in parallel, which local mode simply cannot do.
The requirements matter before you get excited: Claude Code v2.1.101 or later, a repository hosted on GitHub, and a Pro or Max subscription. Local-only repos, GitLab, and air-gapped setups are out — plan mode remains your only option there.
When the plan is ready you get a URL. In the browser it's a structured document with an outline sidebar, syntax-highlighted code blocks, inline comments on specific sections, and emoji reactions for quick signaling. The inline comments are the sleeper feature: in the terminal, disagreeing with step 3 of a plan means typing a paragraph and re-reading the whole regenerated plan. In the web UI you comment on step 3, request a targeted revision, and the rest stays put. Iteration is genuinely faster.
After approval you pick one of three paths: execute in the cloud (it can open a PR directly), teleport the plan back into your terminal session, or start a fresh session with the plan as context. I teleport back almost every time — execution still benefits from local oversight, especially when files have moved since the snapshot.
What I tested it on
My daily driver is this site's codebase — a Laravel monorepo with a blog, a course platform, a shop, six locales, and enough middleware and observers to make any cross-cutting change interesting. I put Ultra Plan against local plan mode on the kind of work I actually do here, at three sizes:
Small: add a query scope. My blog listings used to run hand-rolled published-post predicates that disagreed with each other — one used whereDate, another where — and consolidating them into a single Post::published() scope is a two-file change. Ultra Plan produced essentially the same plan local mode did, 60 seconds slower, because the cloud session has to spin up and clone before it thinks. For anything you can describe in one sentence and already know the files for, the round-trip buys you nothing.
Medium: locale canonicalization. This site serves six locales, and English-only pages needed their locale URLs canonicalized back to the EN original — a change that touches route definitions, a middleware, blade heads, and the sitemap generator, with SEO consequences if you miss a surface. This is where the cloud plan earned its latency: it enumerated affected surfaces more completely than my local plan pass, including template-level consumers I would have found only at test time.
Large: the token-driven blog redesign. Rebuilding every blog surface on a CSS custom-property ramp meant coordinated changes across index, category, tag, search, single-post templates, and shared partials — including a pagination partial that also serves the forum shell, which was the landmine of the whole refactor. Planning work like this is exactly what a 30-minute dedicated compute window is for. The useful output wasn't the step list; it was the dependency ordering — which templates could convert independently and which shared components had to go first.
The honest summary: complexity is the switch. Below roughly five files, Ultra Plan is presentation. Above it, the analysis gets materially better — sometimes. Which brings me to the part nobody tells you.
The three variants you don't get to choose
My results were inconsistent in a way that bothered me — some sessions produced Mermaid diagrams and multi-angle risk analysis, others produced a plan indistinguishable from local mode. The explanation surfaced when people in the community dug through the Claude Code client's source: Ultra Plan runs three distinct planning variants, assigned server-side, and you don't pick which one you get.
Simple Plan is the baseline — structurally similar to local plan mode. File identification, clean steps, nothing more. When you draw this variant, you're getting local mode with a nicer UI and cloud execution.
Visual Plan adds an instruction to include Mermaid or ASCII diagrams for structural changes — dependency order, data flow, the shape of the migration. The diagrams aren't decoration; they encode relationships prose struggles with. But the underlying analysis isn't deeper.
Deep Plan is the one worth having. It runs subagents for separate concerns — architecture impact, exhaustive file discovery, risk and edge-case hunting, and a final consistency review — then synthesizes their findings. When my sessions produced noticeably better plans, this is what I was hitting.
Run the same prompt twice and you can draw different variants on the same repo state. That's the A/B test: Anthropic is measuring which planning approaches users actually approve and execute. It's a reasonable thing for a research preview to do, and it's also the single most important caveat for production use — the quality ceiling is high, the quality floor is local plan mode plus latency, and the lottery decides which you get.
The snapshot will bite you exactly once
The cloud session plans against a point-in-time clone of your repository. It does not see anything you do after launch. I got bitten the obvious way: kept working locally while a plan generated, renamed something mid-window, and approved a plan referencing the old name.
The rule that fixed it: commit and push before any /ultraplan you intend to act on, and treat the plan as stale on arrival — skim it against git status before executing. Uncommitted local changes are invisible to the cloud, so a dirty working tree guarantees a plan built on incomplete context.
Forcing Deep Plan quality with a local skill
Since the variant assignment isn't controllable, I built the control myself: a custom skill that mimics Deep Plan's multi-perspective pattern locally. It's not true parallel subagents in a cloud container, but four sequential lenses recover most of the depth:
# Deep Plan — multi-perspective planning skill
## Phase 1: Architecture analysis
Structural implications, affected modules, integration points.
## Phase 2: File discovery
ALL files needing modification — tests, type definitions,
config, and downstream consumers, not just obvious targets.
## Phase 3: Risk assessment
Edge cases, breaking changes for consumers, race conditions,
security implications, rollback complexity — per step.
## Phase 4: Synthesis and review
Unify findings, order steps by dependency chain, flag
conflicts between phases, include rollback per step.
The trade is speed — four passes take longer than one — but for high-stakes planning the extra minutes are cheaper than the debugging they prevent. I keep both: real /ultraplan for parallel planning sessions and the web review experience, the skill for guaranteed depth. It slots into the same toolkit as the rest of my hidden Claude Code features workflow.
My actual decision rules
After the testing settled, my usage collapsed to five rules:
- One-sentence change, known files: local plan mode. Shift+Tab, review, execute. The 60-90 second cloud round-trip is pure tax here.
- More than ~5 files, dependency chains, or breaking changes: Ultra Plan. Even drawing Simple Plan, the browser review is better for long plans; drawing Deep Plan is a genuine upgrade.
- Architecture reviews and audits: Ultra Plan or the local deep-plan skill, always. High-stakes analysis deserves the deeper pass.
- Production is on fire: local mode, no exceptions. Latency is unacceptable when every second counts.
- Multitasking: Ultra Plan, unbeatable. Two or three planning sessions running in the cloud while I work locally is a workflow local mode cannot express. It pairs well with the parallel-execution side I run through git worktrees and parallel agents.
The trade-offs the launch posts skip
You're the experiment. The variant lottery means two identical prompts can produce different-quality plans. Calibrate trust per session, not per feature — check whether you got diagrams and multi-angle risk analysis before deciding how much scrutiny the plan needs.
Terminal-to-browser context switching is real friction. The inline commenting is excellent once you're there; the reach for the mouse still stings if you live on the keyboard.
GitHub-only, subscription-gated. No GitLab, no local-only repos, Pro/Max required. This excludes a lot of client work — several of my client repos can't use it at all.
The 30-minute window is mostly theoretical. None of my sessions came close; my longest finished in well under ten. It only matters for very large repos.
Ultra Plan isn't a finished feature — it's a research preview doubling as a live optimization platform for Anthropic's planning capability, which means the version you use in three months will not be the one you used today. That's not a criticism. It's a reason to re-test periodically instead of forming a permanent opinion — the same reason I re-ran my Ultra Review comparison after the feature settled.
Quick answers
How do I run it? /ultraplan <your prompt> in Claude Code v2.1.101+, with a GitHub-hosted repo and a Pro or Max subscription. You'll get a browser URL when the plan is ready.
Can I choose Simple, Visual, or Deep Plan? No. Variants are assigned server-side. A local skill replicating the multi-phase analysis is the workaround.
Does it modify my code? No — planning runs against a read-only snapshot. Changes happen only after you approve and choose cloud or local execution.
Take your next cross-cutting refactor, run it through local plan mode and /ultraplan on the same commit, and keep whichever plan you would be comfortable handing a teammate — that side-by-side tells you more about your own planning habits than any feature review, mine included. The end-to-end version of that discipline, planning through verification on a real production app, is a dedicated Claude Code course in my AI School.
