fable-orchestration

Orchestration & delegation policy (scarce-top-tier stack)

A routing policy for stacks with one scarce, expensive main-loop model and cheaper or unlimited delegate tiers. Written against a Claude Fable main loop with Opus sub-agents and Codex lanes, but the shape transfers to any stack with the same economics.

Core law: the scarce model must not do pleb work, and must not be spawned as a sub-agent. Its tokens buy judgment, not throughput.

The hard rules

1. Scarce tier as sub-agent: sparingly, never aggressively. Default to an explicit model: 'opus' on every Agent tool / Workflow agent() call and meta.phases entry — never omit-and-inherit when the parent is the scarce tier, or you silently fan out your most expensive model. A rare judgment-heavy delegated task may use it, only when the cheaper tier genuinely can't carry the work. Also prefer the main loop doing work hands-on over reflexive delegation while limits are healthy — delegation has its own overhead.
2. No mid-tiers. Pick a small number of delegate tiers and stick to them. In this stack: Opus (unlimited) and Codex gpt-6-astra (via codex exec; history gpt-5.5 → gpt-5.6-sol → gpt-6-astra). Mixing in more tiers makes routing decisions unauditable.
3. The main loop keeps the big picture. Architecture, specs, contract-sensitive design, subtle state machines, integration and conflict resolution, final synthesis, judgment calls — all done in the main loop. Mechanical, scoped, parallelizable work gets delegated.

Choosing the delegate

• Codex (gpt-6-astra, medium/high reasoning effort by default) — the default for most high-level tasks, including substantial implementation lanes. astra is a frontier-tier peer of the scarce model, not a small model: it beats the main loop in some areas, so consult it for second opinions on hard calls. Reserve xhigh/max for an explicitly heavy lane, never as the reflex. It is an obsessive instruction follower: as capable as the scarce tier, but less creative. It does not improvise well — it executes. Give it a carefully written, detailed, explicit spec and it will grind through it relentlessly and precisely. Use for: implementation lanes, migrations, refactors, test-writing against a defined contract, scenario authoring — anything where the spec is complete and deviation is unwanted.
• Opus — mainly for context gathering. Exploration, codebase mapping, research sweeps, reviews, verification passes — work where the brief can be loose and the deliverable is understanding, not a diff. Opus copes well with ambiguity: hand it a goal and let it figure out the terrain.