CommandCodeAI / CommandCodeAI/command-code
Native Planner + Executor mode: pair a strong reasoning model with cheap execution models
まだ誰も着手していません。
- 主要言語
- 言語のデータがありません
- スター
- 4k
- フォーク
- 350
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
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 を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず、issueで言及されている既存のCLI、headless mode、設定フローを確認します。実装前に、plannerとexecutorの役割、worktreeの分離、objective checks、retry behavior、model selectionを定義します。Doneには合意済みの仕様と検証済みのエンドツーエンドフローを含める必要がありますが、issueでは実行するファイルやテストは指定されていません。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- git
- 領域
- ai, cli, devtools
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 静か
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 25/100