Claude Code plans, Cursor Composer executes, Claude reviews. I wired the three together.

I was burning expensive Claude tokens on tasks a cheaper model could handle just fine. Renames,...

I was burning expensive Claude tokens on tasks a cheaper model could handle just fine. Renames, placeholder swaps, grinding through a well-scoped task list. That's not where Claude's magic is, and it's not where I want to spend the budget. So I stopped picking one tool and wired two together.

After a few weeks of juggling terminals, the setup settled into three moves:

• Claude Code makes the plan.
• Cursor Composer 2 executes it.
• Claude reviews the diff.

Tokens saved, quality kept. I packaged it as a Claude Code plugin so I don't reinvent the hand-off every time.

Why not just stay in Cursor?

Because Claude Code has a real edge in planning, and it's not only the model. It's the whole rig: long-context sessions, subagents, the TUI, the way tools compose. The plans it produces are consistently good, and I didn't want to give that up to save money on execution.

Why not just stay in Claude?

Because Composer 2 is genuinely good at day-to-day coding and one-shot work. File edits, applying diffs, churning through a well-scoped task list in force mode. Cursor and Composer are heavily tuned for exactly this CLI use case. Fast, and safe enough for mechanical changes.

Picking one meant either overpaying for execution or under-planning. Wiring them together meant each tool does the part it's best at.

What I actually use it for

• Bigger refactors: think out loud with Claude, then let Composer grind through the mechanical edits in the background. Multilingual site integration, where Composer swaps every hard-coded string for a placeholder, is a perfect fit.
• "Rename X to Y across the codebase and update the tests": classic Composer territory. No reason to spend Claude cycles on it.
• E2E testing via a browser MCP: one slash command spins it up. Composer 2 is more than enough here; I don't need a frontier model to click through a page and assert on it.

What didn't work

Letting Cursor do the planning. It's fine. But Claude's planning loop is better, and that's the one place I don't compromise. The lesson: don't split work by tool arbitrarily; split it by what each tool is actually best at. Planning to Claude, mechanical execution to Composer, review back to Claude.

What's in the plugin

Rather than re-do the hand-off by hand each time, I shipped it as a Claude Code plugin: eight /cursor:* commands (delegate, status, result, cancel, resume, browser-verify, sessions, setup) plus a cursor-runner subagent for automatic delegation. Zero runtime dependencies, MIT.

Heavily inspired by openai/codex-plugin-cc, which pulls the same trick with GPT/Codex, credit where it's due.

The takeaway

The interesting shift here isn't "use a cheaper model." It's treating your coding agents like a small team with different strengths instead of looking for one model to rule them all. A planner, an executor, a reviewer. They just happen to be three different CLIs, and the plugin is the glue that makes the hand-off free.

👉 github.com/freema/cursor-plugin-cc

Are you running a multi-tool coding setup, or still trying to make one model do everything? Curious how others split the work.