model-orchestration

name	model-orchestration
description	How to combine the available models (Fable 5, Opus 4.8, Sonnet 5, Haiku 4.5, and GPT-5.6) by cognitive role on multi-step coding, research, design, and intensive audit tasks. Use when planning non-trivial work in a claudex or Codex proxy session, especially when deciding who gathers evidence, comprehends a large system, makes judgments, advises, implements, or independently reviews.

Using the models together

You have two backends via the proxy: Claude (claude-fable-5, claude-opus-4-8, claude-sonnet-5, claude-haiku-4-5-20251001) and GPT (gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna). Route by cognitive role and context shape, then consider quota. Cheap execution is useful; cheap judgment that produces the wrong design is not.

1. Pick a pattern by task shape

• Orchestrator — judgment is the hard part (research, ambiguous or complex features). Fable leads at low effort: recon, plan, write a spec-quality brief, delegate the whole implement→test→lint loop to a Sonnet worker, review the diff, commit. Rarely edits code itself.
• Deliberative audit — both comprehension and judgment are hard (architecture audit, workflow redesign, safety review, large-system critique). Fable owns the decision tree and synthesis. Sonnet performs mechanical inventory and evidence extraction. One persistent Opus comprehension auditor builds a faithful system model from that evidence. One persistent Sol deliberation advisor challenges the opening frame and closing recommendation. Use this pattern instead of asking several peers to produce overlapping opinions.
• Advisor — execution is the bulk (routine, well-scoped coding). Sonnet leads and does the work, consulting Fable ~once for a plan or to unblock, then keeps executing.
• Neither — short task or serial debugging where the accumulated context is the work. Just do it yourself; forced delegation delegates the wrong things.

2. Delegate well (this is what makes it cheap AND correct)

1. Hand off early — before dragging every file into your own context.
2. Brief like a design doc, not a dictation — enumerate constraints, edge cases, and a crisp definition of done (e.g. "must be O(1) in pointer length: NO full token scan"). Good briefs are why a cheaper model finishes correctly.
3. Review cheaply, re-delegate fixes — a git diff pass; if it is buggy, hand back another short brief instead of rewriting at lead prices.

For a deliberative audit, hand off in this order: Sonnet evidence manifest → Opus comprehension model → Fable synthesis → Sol closing challenge. Give Sol compact decisions and evidence, not the repository. Treat two Sol calls (opening and closing) as the default budget.

3. Cross-family check

Whoever wrote the code shouldn't be its only reviewer. Have a GPT model (gpt-5.6-terra) review Claude-written diffs — a different model lineage catches failure modes the author's lineage is blind to. For Codex-written diffs, use the opus-reviewer agent. This is the highest-value place to mix families.

4. Capacity-aware routing

Before a large fan-out, use the quota-axi skill and send bulk work to whichever family has more headroom. State which provider you chose and why.

Effort remains a property of the cognitive job and session scope, not the provider. Keep the proxy free of global reasoning-effort overrides and verify that invariant with <skill-dir>/scripts/check-effort-config.mjs. A quota-driven family switch must not silently downgrade design, synthesis, or specialist review.

5. Delegation policy (per-role subagents)

Under claudex, model choice is per-role via ~/.claude/agents/*.md. Under Codex, the cross-family roles use ~/.codex/agents/*.toml and the cliproxy provider. Route by task shape, not habit:

• Delegate early, brief like a design doc — enumerate constraints, edge cases, and an explicit "done" before dragging files into lead context.
• Wide reads / search sweeps → the explorer agent (Sonnet, big context) — NOT the built-in Explore, which inherits the expensive Fable lead. This is also what keeps a large fan-out from overflowing a small-context worker.
• System comprehension across gathered evidence → comprehension-auditor (Opus). It explains the current system, contradictions, and missing context; it does not choose the target design.
• Bulk implement / test / fix → worker (Sonnet), from your brief.
• One steering call → advisor (Fable), rarely; guidance only, no code.
• Persistent adversarial deliberation → deliberation-advisor (Sol), normally at opening and closing checkpoints. Do not also invoke planner for the same judgment.
• Cross-family diff review → reviewer (GPT) — give it a bounded diff, not the repo. claudex-only.
• Hard / novel decomposition → planner (GPT) — feed it a distilled problem statement, never raw file dumps (small context window). claudex-only.
• Lead effort follows task shape. Low effort is the normal orchestration default. Intensive audits may raise Fable effort because synthesis itself is the hard work; do not simulate deeper reasoning with a larger fan-out.

For a Codex lead, use the mirrored cross-family roles:

• Bounded steering → fable-advisor — spawn once with one compact decision brief; guidance only. Continue the same agent only when the decision itself has a later checkpoint.
• System comprehension → opus-comprehension-auditor — gathered evidence and relevant sources; facts and tensions, not target-design judgment. Reuse it while the same audit remains active.
• Codex-written diff review → opus-reviewer — spawn a fresh reviewer for a bounded diff plus approved behavior and invariants; findings only.

Do not use Fable and Opus as overlapping general-purpose peers. Fable owns bounded judgment; Opus owns faithful comprehension or adversarial review. The Codex lead owns synthesis and the user-facing answer.

Rule: never route wide raw-file reads to a GPT specialist — context window is a routing axis, not just cost/quality.

---

Full rationale and the benchmark plan live in <skill-dir>/references/routing-table.md. This skill is meant to be iterated — edit it as patterns prove out or fail in practice.