Claude Code Ultraplan — Planning Moves to the Cloud
Anthropic just shipped a hidden Claude Code feature called Ultraplan. Instead of planning locally, your session is offloaded to a multi-agent Opus 4.6 swarm in the cloud that builds a richer, faster, more structured plan — and then teleports it back to your terminal for execution.
Planning has always been the highest-leverage moment in agentic coding. Get the plan right, and execution is mostly mechanical. Get it wrong, and you spend the next two hours watching an agent confidently dig itself into a hole.
Anthropic just dropped a quietly significant Claude Code feature that doubles down on this insight: Ultraplan. Instead of running plan mode locally, your session is offloaded to a cloud-hosted Opus 4.6 instance where multiple agents explore your codebase in parallel and produce a deeper, more structured plan than anything the terminal can deliver — usually in a fraction of the time.
I’ve been testing it for the past few days. It’s not just faster planning. It also makes the execution phase noticeably faster, because the resulting plan is so unambiguous that the local agent doesn’t have to think — it just builds.
What Ultraplan Actually Is
Ultraplan offloads your planning session to Anthropic’s cloud container runtime, where it spins up a small swarm of agents:
- Three parallel exploration agents that walk your codebase, read existing skills and scripts, and propose approaches
- One critique agent that pressure-tests the proposals
- Opus 4.6 as the underlying model, regardless of what your local session is using
The output is a structured, document-style plan — context, what already exists, the new approach, files to be created, files to be modified, and a final verification section. Sometimes it includes diagrams. And critically, it lives on a web review surface where you can leave comments and emoji reactions on individual sections, not just dump text into your terminal scrollback.
When you’re happy, you click Approve Plan and it teleports back to your terminal session, ready for local execution. Or you can execute it remotely in the cloud and review the results later.
Triggering It
Two ways:
# Explicit slash command
/ultraplan build me a customer dashboard with MRR, churn, and cohort retention
# Or just include the keyword
ultraplan refactor the auth service to use the new Redis cacheThe keyword lights up the same way ultrathink does — Claude Code recognizes it and asks whether you want to send the planning session to the cloud. Say yes and you get a link to monitor progress in Claude Code on the web.
You can also start with an existing local plan and promote it to Ultraplan if you decide partway through that you want the heavier treatment.
One important constraint: this only works in the CLI. The desktop app and the VS Code extension don’t trigger Ultraplan — they silently fall back to nothing. If you want Ultraplan, you have to be in your terminal.
The Side-by-Side Test
The most striking demo is running the same prompt twice — once in local plan mode, once with Ultraplan — and watching what happens.
I gave both sessions the same dashboard spec: stats cards (MRR, ARR, churn rate), revenue tabs by tier, customer breakdowns, support analytics, light/dark mode, mock data, served on localhost.
| Local Plan | Ultraplan | |
|---|---|---|
| Time to plan | ~12 minutes | ~1 minute |
| Time to execute | ~30 minutes | ~10 minutes |
| Total wall clock | ~45 minutes | ~11 minutes |
| Local tokens used | 131k | 82k |
| Plan format | Terminal scrollback | Structured doc + diagrams |
| Review surface | Text dialogue | Comments, reactions, sections |
Both produced visually similar dashboards. But Ultraplan delivered roughly 4x faster end-to-end, used fewer local tokens, and produced a plan that was actually pleasant to review.
The token math is interesting. Yes, Ultraplan used cloud tokens that don’t show up in /cost — my best estimate is around 50k of additional planning tokens on the cloud side. But because the plan is so much sharper, the local execution phase consumed fewer tokens than the local-plan version. Net-net, it’s plausibly cheaper per finished feature, not just faster.
Why It’s Faster at Executing
This part surprised me. I expected better planning. I didn’t expect execution to be dramatically faster too.
My working theory: when a local agent gets a vague plan, it spends a lot of cycles re-deriving intent — rereading the brief, second-guessing structure, exploring the codebase mid-build. When the plan is unambiguous and structured (“create file X with these exports, modify file Y at this function, add migration Z”), the agent stops thinking and just executes. Less thinking means fewer tool calls, fewer reads, fewer diffs reconsidered.
It’s the same dynamic as a senior engineer handing a junior a perfect spec versus a vague one. The work itself takes the same number of keystrokes, but the wandering disappears.
“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” — Lincoln
Ultraplan is a sharper axe.
What’s Happening Under the Hood
| Dimension | Local Plan | Ultraplan |
|---|---|---|
| Runtime | Your terminal | Anthropic cloud container |
| Model | Whatever your session uses | Always Opus 4.6 |
| Approach | Single agent, linear thinking | Multi-agent: 3 explorers + 1 critic |
| Compute cap | Your session limits | 30-minute hard cap |
| Terminal blocked? | Yes, plan mode locks the session | No — terminal is free while cloud plans |
| Review surface | Text | Doc with comments and reactions |
The multi-agent piece is the most interesting architectural choice. Three exploration agents working in parallel — presumably with different prompts or different starting points — followed by a critique pass. This is a real agentic plan-then-critique loop, not just a longer single-agent chain of thought. It’s the same pattern that makes parallel-then-merge so effective in research workflows, applied to code planning.
Your terminal session also stays unblocked while the cloud is planning, which means you can keep working — though in practice I’d rather spin up a fresh session and keep contexts clean for the eventual handoff.
Requirements and Gotchas
You need a Git remote. Ultraplan only works on projects that are pushed to a Git host (typically GitHub) — the cloud planner needs to clone your repo to explore it. If you try to Ultraplan a local-only project, Claude Code will tell you to initialize and push first. This is a one-time setup, but it’s a hard requirement.
You need a Pro or Max subscription. Ultraplan is not available with API billing. I tried. The cloud planning surface is gated to subscription accounts only — likely because it’s billed against the same compute pool as Claude Code on the web.
Skills aren’t always invoked automatically. This caught me on a real task — I asked Ultraplan to build a research doc with custom diagrams, expecting it to use my visualization skill. Instead it produced generic Mermaid diagrams. I had to leave a comment on the plan saying “use my visualization skill” and even then it asked me to name the skill explicitly. Lesson: be explicit in your Ultraplan prompt about which skills you want it to use, even though it can technically see them in the repo.
Token visibility is poor. /cost doesn’t reflect cloud planning tokens. My max-plan usage went up roughly 1% per Ultraplan session in my experiments, but there’s no per-session breakdown yet. I’d love to see this improve — knowing the cloud-side cost matters for deciding when to reach for it.
Authentication can be flaky. I hit a few transient auth errors during testing. Re-running fixed it every time, but it’s clearly still in research preview.
When To Use It
Ultraplan is not the right tool for every prompt. It’s slower to start (you need a Git push, you need to context-switch to a web tab), and it consumes more tokens than a quick local plan. The break-even is somewhere around tasks that would have taken 10+ minutes to plan locally.
My current heuristic:
- Use Ultraplan for: new features that touch multiple files, refactors that span layers, dashboards or full pages built from scratch, anything where you want a structured doc you can share with a teammate or revisit later.
- Skip Ultraplan for: single-file bug fixes, quick edits, exploratory spikes, anything where you’re still figuring out what you want.
Combine it with ultrathink and you’ll burn through a session quickly — but for the right task, that’s the cheapest 11 minutes you’ll spend all week.
What This Means
Ultraplan is a small feature on the surface — a slash command, a web tab, a teleport back. But underneath it’s a meaningful architectural statement from Anthropic: planning is worth its own dedicated runtime, its own dedicated model, and its own dedicated multi-agent topology. Execution and planning have different cost profiles, different latency tolerances, and different reasoning patterns. Splitting them across two runtimes — cloud for planning, local for execution — is exactly the kind of separation that becomes obvious in retrospect.
I expect this pattern to spread. The next logical steps:
- Cloud-side execution as a first-class option, with the local terminal becoming a thin client for review and approval
- Persistent plan documents that live alongside your repo, version-controlled, comment-able, like ADRs but generated and maintained by agents
- Multi-agent topologies beyond plan/critique — parallel implementation agents, parallel review agents, all coordinated through the same web review surface
- Better cost telemetry so we can reason about cloud-vs-local tradeoffs without guessing
For now, Ultraplan is the most interesting Claude Code feature shipped this quarter. If you’re doing anything non-trivial in your terminal today, push your repo, type ultraplan, and watch what happens. The first time it teleports a structured 30-section plan back into your session in 90 seconds, you’ll understand why this matters.