ccc-plan-exec

$ccc-plan-exec — Plan Cheap, Execute Capable

Plan-exec splits work into two phases on two models. A cheap, fast model drafts the plan — the step list, the loop body, the structure. Then a capable model (Opus/Fable) executes each step. You write a loop, not a one-shot prompt: the structure is decided once, cheaply, then run N times against the expensive reasoner only where reasoning earns its cost.

CC Commander · Plan-Exec Mode · Docs

Plan-exec is the canonical workflow-first doctrine (commander/cowork-plugin/rules/workflow-first.md) applied to cost: let the cheap model decide the shape, let the capable model do the thinking. Motto: "Pay for Fable on the thinking, not the typing."

---

Write loops, not prompts

A prompt is a one-shot: "do this whole thing." A loop is a structure plus a body that repeats: "for each item, do the body." The loop body is small, predictable, and capable-model-worthy. The structure around it — the item list, the order, the guards — is boring scaffolding a cheap model nails for cents.

	One-shot prompt	Loop (plan-exec)
Who plans	Capable model (wasteful)	Cheap/fast model
Who executes	Capable model	Capable model, per step
Cost shape	Pay expensive for scaffolding + thinking	Pay cheap for scaffolding, expensive only for thinking
Failure mode	Whole run dies, re-pay everything	One step retries, rest survives
Verifiability	Monolithic blob	Step-by-step, each checkable

If the work decomposes into "the same body, N times," it's a loop. Plan it cheap.

Terminology: "loop" here is the plan-exec sense — a repeating per-step body inside one run. The $ccc-loop taxonomy names the session-level loops (/loop interval re-prompts, /goal converge-until-gate, /schedule cron routines). A plan-exec loop that must repeat until an external gate holds (tests green, criteria met) graduates into a /goal loop — use that primitive rather than hand-rolling retries.