Feedback: /ultraplan is positioned as deeper planning but is really a fresh-container Claude Code

Summary

The naming and positioning of /ultraplan implies it does deeper or better planning than a regular Claude Code session. In reality it's a fresh cloud container running the same Opus model, with the same tools. The actual value-adds are operational (fresh context window, parallel cook, separate quota) — not cognitive.

Long-time terminal users can be led down a path of plumbing (auto-commit hooks, context-mirror scripts, shell wrappers) just to make the feature usable, when the same audit could have been done in their existing local session with no setup.

The user perception gap

• "ultra-plan" → users hear "ultra-deep reasoning" or "ultra-large planning capability"
• Reality → same model, same depth available locally
• Result → users invest time setting up infrastructure for what amounts to a UX wrapper

I'm an established terminal user with months of muscle memory in claude CLI. When /ultraplan came up, I assumed it unlocked planning that local plan mode couldn't do. I built:

• A PostToolUse git auto-push hook
• A UserPromptSubmit context-snapshot hook
• A bash wrapper to cd into the brain repo
• A 12MB read-only mirror of 14 venture repos

…to make the feature work end-to-end. After all that, I asked the model what /ultraplan actually gives me that local mode doesn't, and the honest answer is: a fresh context window, doesn't burn my Max rate-window, runs in parallel. That's it. Same brain.

What the value actually is (and what to rename to)

The genuine differentiated value is real but operational, not cognitive:

• Fresh context — useful when local session is context-heavy
• Parallel execution — keep working locally while it cooks
• Separate quota — doesn't eat Max rate-window
• Background-friendly — for long audits

Suggested rename/repositioning options that would set honest expectations:

• /remote-plan (descriptive, accurate)
• /parallel-plan (highlights the real value)
• /background-plan
• /sandbox-plan

Or keep /ultraplan but reposition the docs to say "offload a long planning task to a fresh cloud container so you can keep working locally" rather than implying it's a smarter planner.

Why this matters for terminal-native users

Terminal users discover /ultraplan through CLI docs and assume it must do something local can't (otherwise why have it?). The honest framing would help them choose correctly: "if your local session is fine and you have time, do it locally — only reach for /ultraplan when you specifically want parallelism or a clean context."

The current framing pushes terminal users toward a web UI they didn't need, and the web UI has its own friction (separate issue: https://github.com/anthropics/claude-code/issues/58977).

Environment

• Claude Code v2.1.112
• Long-time terminal user, multi-repo workflow, Max plan