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

[literallyfabin]

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

[ObaidNadeem]

Thanks for creating the issue @literallyfabin, team will have a look at it.

[ahmadawais]

@vipulgupta2048 check this, i ask @literallyfabin to do this. compare it with the PR i had made.

[shunia]

Is this an enhanced workflow to sub-agents?

Currently the sub-agents capability allows to fire multiple sub-agents with the same model (I believe?), which is kind similar with this approach right? I have successfully trigger the sub-agents calls with deepseek-flash model without explicitly prompt it to, and it is really useful.

[literallyfabin]

Good question! From what I understand of the current system, sub-agents fire using the same model as the parent — so if I use Kimi K3 as the planner and it spawns sub-agents, those sub-agents are Kimi K3 too. That's actually the core cost problem: running an expensive/frontier model for every single sub-task gets unfeasible fast, especially with several running in parallel.

The idea here is to decouple the two: an expensive/frontier model does the planning and the auditing (reviewing the work against explicit acceptance criteria — tests/lint passing, not just "looks right"), while it dispatches the actual sub-tasks to cheaper models as executors. Each executor runs isolated in its own git worktree. If something doesn't pass the planner's review, it goes back for a bounded number of retries with specific feedback, and escalates back to the planner (or a bigger model just for that one step) if it keeps failing.

It could go a step further too — if a sub-task the planner dispatches is design-related, it could automatically pull in Command Code's native design skills for that call, so the user doesn't have to keep track of which design skill does what.

Not sure how feasible this is on your end architecturally, just sharing the idea! To sum it up: the planner has the ability to dispatch different (cheaper) executor models instead of being locked to its own model — pairing a strong, smart "brain" (planner) with good, cheap "work" (executor).