Native Planner + Executor mode: pair a strong reasoning model with cheap execution models

Feature Description

Hey team! Following up on a conversation I had with Ahmad on X about this — wanted to put it here properly as a suggestion.

The idea: a native "planner + executor" mode for Command Code. A strong/frontier reasoning model (e.g. Claude, Kimi K3, GPT) acts as the planner — it reads the repo, breaks the task down into a plan (mission.md + task graph), and decides what can run in parallel. Cheap models (DeepSeek, Mimo, Minimax, etc.) act as executors, each running its assigned subtask isolated in its own git worktree. The planner then reviews the output against objective checks (tests/lint passing, not just "looks right"), and either merges + reports back to the user, or sends specific feedback back for a retry — escalating back to the planner if it fails a few attempts.

Diagram of the full flow below (drawn it out in Excalidraw so the loop is clear):

Use Case

The core reasoning: what makes an agent make good decisions is the model's reasoning quality, not the price of the model doing the typing. Since the biggest cost driver is output tokens, using a frontier model to do everything — thinking AND writing every line of code — gets expensive fast. Splitting the roles (expensive model only for planning/reviewing, cheap models for the actual execution) keeps quality high while cutting cost a lot, especially running executors in parallel.

I already do a rough version of this manually today: I use Claude (in Claude Code) as the planner, and call cmdc in headless mode as the executor. It works, but it's a workaround. If Command Code supported this natively — right in the CLI, or eventually in a desktop app — with planner agent / executor agent as a first-class config, I think a lot of people would use it. Basically pairing the "brain" with the "worker."

Additional Context

Also roughly mocked up what the config UX could look like — a simple "select planner agent / select executor agent" step, so it's configurable per role instead of hardcoded:

This is just a suggestion / starting point, not a finished spec — happy to help however's useful, whether that's more detail, testing, or feedback on implementation.

How important is this to you?

Nice to have

Start by reviewing the existing CLI, headless mode, and configuration flow mentioned in the issue. Define the planner and executor roles, worktree isolation, objective checks, retry behavior, and model selection before implementation. Done should include an agreed specification and a validated end-to-end flow, but the issue does not name files or tests to run.