Claude Code ships with two planning tools. /plan (or Shift+Tab to cycle into it) puts Claude in a read-only posture – it analyses your codebase, clarifies your goals, and produces a plan before touching a single file. Fast, built-in, no setup. For a contained task where you know what you want, it’s hard to beat.
Ultraplan goes further. You trigger it from the CLI, it hands the planning task to a cloud session running on Anthropic’s infrastructure, and you review the result in your browser – inline comments, section-by-section, emoji reactions if you’re that kind of person. When you’re satisfied, you either approve it to run in the cloud or teleport it back to your terminal. Your terminal stays free the whole time.
I want to be clear that I think this is genuinely good – especially for complex tasks. A well-structured plan, drafted remotely, reviewed with targeted feedback on individual sections, iterated before a file is touched. That review loop can even catch brief problems: if the plan surfaces that you were solving the wrong thing, you can revise before execution. That’s real progress over “type a prompt and hope.”
The early community reaction has been mixed. Ultraplan is in research preview, and the rollout brought OAuth failures, service instability, and quota exhaustion fast enough to leave paid subscribers hitting cooldowns inside an hour. The frustration is understandable – and worth naming, because it sits alongside genuine enthusiasm for what the tool is trying to do. The browser review surface is, in the words of one early user, “strangely satisfying.” The appetite for structured planning is real. The execution is still catching up.
There’s just one thing neither tool can do before the plan exists.
The gap
Ultraplan starts from your prompt. It takes what you wrote, analyses your codebase, and produces the best plan it can for that intent. The review loop gives you a chance to catch a wrong assumption – but reactively, once the plan is already in front of you.
What it doesn’t do is interrogate your intent before drafting starts.
For well-scoped tasks where the brief is solid, that’s fine. The plan appears, it looks right, you approve it. For complex tasks with genuinely ambiguous requirements, the review loop helps – but you’re still discovering the brief problem in the plan, not resolving it before the plan exists.
The sessions where that distinction matters are usually the expensive ones. Vague requirements that feel obvious until someone writes them down. Scope that seemed contained until the plan revealed it wasn’t. A wrong framing that produces a coherent, well-structured plan for the wrong thing.
Ultraplan will produce a brilliant plan for that. The review loop will give you a chance to notice. Whether you notice in time is a different question.
What FRAME does instead
FRAME’s SHAPE phase exists specifically for this problem.
Before any plan exists – before any files are read, before any roles are adopted – a Requirements Engineer runs. No code. No implementation. Just: what are we building, what are the hard constraints, what is explicitly out of scope, and what does done look like? The output is a PROJECT.md you confirm before anything else happens.
That agreement is the contract. The plan comes after.
It’s slower. That’s the point. The ten minutes you spend in SHAPE is the work of agreeing on what you’re building before you build it. The difference from ultraplan’s review loop isn’t the outcome – it’s the timing. FRAME resolves the brief before planning starts. Ultraplan surfaces it after.
What about using both?
I also tried activating Plan Mode mid-FRAME session – curious whether the two could work together. The answer was: not safely. Claude Code skipped the gate and started modifying files before I’d confirmed anything. Whether that’s a mode interaction issue or something else, I didn’t stay to find out. It felt like the wrong moment to run an experiment. That combination needs proper testing before I’d recommend it to anyone.
Different jobs
These aren’t competing tools. /plan and /ultraplan answer “how should Claude approach this?” FRAME answers “what are we building, and did we build it?” They can coexist – ultraplan for complex tasks where the brief is solid and you want cloud drafting and rich review, FRAME for sessions where agreeing on the brief is itself the hard part.
The repo is at github.com/SeriousByDesign/frame. If you haven’t read the earlier piece on what FRAME actually does and why I built it, start there – it covers the mechanics and has a real two-run comparison that’s more useful than anything I could add here.
bash
git clone https://github.com/SeriousByDesign/frame.git
cd frame
bash install.sh