Delegate

Split the current task into self-contained subtasks, route each to the cheapest model that meets the quality bar, run them (in parallel where independent), then verify and integrate the results.

Orchestrator check

Before decomposing: check your own model (stated in your system prompt, e.g. "claude-sonnet-5"). This skill's routing assumes a strong orchestrator (opus-4.8+, sonnet-5+ or fable-5) doing decomposition and synthesis, with cheap models on leaf work - that split is what makes delegation a net win rather than just moving cost around.

If you are not opus-4.8, sonnet-5 or fable-5, warn the user once before proceeding:

You're running delegate on [model]. This skill assumes a strong orchestrator (Opus/Fable) for decomposition and synthesis - on a weaker model both layers end up similar strength, which weakens the payoff. Switch to Opus or Fable for better routing/synthesis quality, or continue if this task is simple enough not to matter.

Then proceed regardless - this is a warning, not a block, unless the user says to stop.

Model routing table

Intelligence and taste: higher = better. Cost: higher = more expensive (burns usage limit faster).

Each row wins exactly one kind of work; if a model never wins a rule below, it doesn't get a row.

Per-model caveats:

• gpt-5.x: codex's sandbox cannot git-commit inside worktrees - the orchestrator commits for it. Bare gpt-5.6 is not a valid model id (400s); use gpt-5.6-sol (frontier), -terra (balanced), or -luna (fast/cheap) on codex >= 0.144.x. On model-id errors or a stale codex install, read references/codex-troubleshooting.md.
• fable-5: ~2x opus cost and token burn; weak one-shot frontend/UI design and spec/PRD writing despite top intelligence. If fable-5 is the current orchestrator, delegating to it is pointless - keep that work in the main agent.

Routing rules:

• These are defaults, not limits. Standing permission to override: if a cheaper model's output doesn't meet the bar, rerun with a smarter model without asking. Judge the output, not the price tag.
• Cost is a tie-breaker only; for anything that ships, intelligence > taste > cost.
• Bulk/mechanical work (clear-spec implementation, data analysis, migrations) and trivial lookups: glm-5.2, or gpt when the spec is fuzzy enough to need more intelligence.
• Bulk/high-volume writing (website copy, boilerplate marketing copy, first drafts across many pages): glm-5.2. Higher-stakes single pieces still need opus-4.8's taste.
• Fast agentic implementation with a decent spec (multi-file edits, terminal-heavy tasks): grok-4.5 - near-frontier agentic coding at low cost relative to gpt/opus.
• Anything user-facing (UI, copy, API design) needs taste >= 7: opus-4.8.
• Reviews of plans/implementations: opus-4.8, plus gpt via codex as an independent perspective from a different model family. Don't spawn a subagent on your own model to "review" your own work.
• Second independent review perspective, or alternate bulk/implementation worker when glm is unavailable or underperforming: grok-4.5 (scores provisional, not eval-calibrated).
• Hard, single-threaded problems: keep them in the main agent; delegation overhead beats the savings. If the main agent is opus-4.8 and the problem is at the edge of its ability (deep debugging, gnarly algorithms, vision/document-formatting work), escalate that one subtask to fable-5 - but not for frontend design or long-form specs, where opus's taste wins despite fable's intelligence.

Invocation mechanics

Non-Claude models start cold with zero conversation context. Every prompt must be self-contained: state the task, absolute file paths, constraints, and the exact output format expected. Read stdout for the result.

The output format is not optional: every delegated prompt must demand compressed, structured output with a size bound - e.g. "return a findings list (file, line, claim, evidence), max 30 lines" or "return only the final answer, no narration". Workers are filters, not pipes: compression happens at the worker so the orchestrator never pays to read raw exploration output. If a result comes back unbounded or chatty, treat that as a failed acceptance criterion and rerun with a tightened prompt.

Exploration tasks also need a convergence rule, especially on glm: "do at most N exploration commands (default 8), then STOP exploring and synthesize; your FINAL message must be exactly the requested output and nothing else". Without an explicit budget, weaker models keep gathering until the run is cut off mid-loop and return working notes instead of an answer - exit code 0, no synthesis.

glm-5.2, gpt, and grok-4.5: prefer the courier agents glm-runner, codex-runner, and grok-runner (Agent tool, subagent_type). Their definitions ship in this skill's agents/ folder; if they are not registered as agent types, copy them to ~/.claude/agents/ once (new sessions pick them up automatically). Couriers are first-class subagents: agent UI, background runs, parallelism, SendMessage follow-ups. Give them the full task; they compose the cold-start prompt and relay the answer verbatim.

Raw Bash fallback (when a courier is unavailable or for a quick one-liner):

cd <dir> && opencode run -m zai-coding-plan/glm-5.2 "<self-contained prompt>" < /dev/null
codex exec "<self-contained prompt>" < /dev/null          # -s read-only: review only; --full-auto: allow edits
grok -p "<self-contained prompt>" --model grok-4.5 < /dev/null   # add --permission-mode acceptEdits to allow file edits

Always redirect stdin from /dev/null as shown above - all three CLIs hang waiting on stdin, not just when backgrounded. Add --skip-git-repo-check to codex outside a git repo. Answers: glm after the > build banner, codex after the tokens used line, grok straight to stdout (-p prints only the final response, no banner).

Claude models: Agent tool with model: haiku|sonnet|opus|fable. For fable escalations prefer subagent_type: fable-runner - unlike the couriers it runs the task itself on fable-5, with cold-start framing, bounded output, and the [fable-5 | <outcome>] prefix baked in. Always prefer the Agent tool over claude -p inside a session - subagents get tool access, parallel launch, background tracking, and SendMessage continuation. Use claude -p "<prompt>" --model <model> only from scripts/hooks outside a session, or when a run needs custom flags (e.g. --append-system-prompt) isolated from the current session.

Courier vs raw Bash - pick per task, not by default: couriers are first-class subagents but also a relay through a weaker model (haiku) that can occasionally drop a formatting instruction (e.g. skip the [model | status] prefix). Raw Bash is synchronous and blocks your turn, but what you read is the literal CLI output - nothing summarized or possibly mangled in between.

• Parallel/independent/background-worthy subtasks, or anything where you'll want to SendMessage a follow-up: courier.
• A single quick lookup, or anything where you need to see the exact unfiltered CLI output (debugging the delegation itself, verifying a courier's claim, a one-off sanity check): raw Bash.
• If a courier's result looks off (missing prefix, chatty, unbounded) - don't retry the same courier blind. Either tighten the prompt, or re-run the same task via raw Bash to see the ground truth and confirm whether the courier or the underlying model was at fault.

Live wezterm panes: couriers stay the default delegation path. A live pane is a different job entirely: a persistent, visible session the user watches or drives turn-by-turn in the model's own interactive CLI. When the user asks for a persistent, visible, or live session ("open a live GLM session in a pane"), read references/live-sessions.md before touching wezterm - it has the spawn and drive mechanics, the scrollback caveat, and the never-close-a-pane rule.

PR review with two independent models: for "review this PR"/"review my diff", read references/pr-review.md - parallel courier reviews from different model families, merged/verified/triaged before any fix lands. Not a live cross-model chat; that mechanic is deliberately rejected in the reference for groupthink/parallelism reasons.

Workflow

1. Decompose the task into subtasks; note which are independent (parallelizable) and which are sequential.
2. Route each subtask with the table above.
3. Write self-contained prompts. Include acceptance criteria so output quality is checkable, and a bounded output format (see invocation mechanics) so results come back compressed.
4. Launch independent subtasks in parallel (multiple Bash/Agent calls in one block; run_in_background for long ones).
5. Verify every result before integrating - run the code, check the claims. Escalate to a smarter model on failure rather than patching mediocre output.
6. Integrate and report: which model did what, what was verified, anything escalated.
7. When a model repeatedly fails at or aces a task type, propose an update to its scores in the routing table - real delegations are the eval.