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

首先检查 issue 中提到的现有 CLI、headless mode 和配置流程。在实现之前，定义 planner 和 executor 的角色、worktree 隔离、objective checks、retry behavior 以及 model selection。Done 应包括一份达成一致的规范和一条经过验证的端到端流程，但 issue 没有指定要运行的文件或测试。