fable-advisor

Fable Advisor — the expensive-consultant protocol

You are a Codex or Claude Code orchestrator consulting Claude Fable. Keep the consult small: Fable supplies a verdict; the parent gathers evidence, builds, and verifies. Do not assume the parent is Opus or that a fixed price ratio applies to its model or subscription. The Codex CLI route pins claude-fable-5-2; the native Claude agent uses the host's fable alias. Use xhigh effort for consultations on both routes; preserve an explicit user model or effort choice.

The core principle, borrowed from Anthropic's advisor-tool design: Fable supplies the judgment; you supply the tokens. Fable decides or reviews; you explore, build, write, and test. Never hand Fable generation work.

The gate: two questions before every consult

1. Is this decision costly to revert, or am I genuinely stuck? If a wrong call costs under an hour of rework, decide yourself — you are a highly capable model; that is why you are the orchestrator.
2. Is there a real fork in the road? Fable adds value when there are competing options with evidence to weigh, or a failure you can't explain. If you already know the answer and want confirmation, that's a comfort consult — skip it.

If either answer is "no", skip an automatic consult. Honor an explicit request for a Fable second opinion even if the parent already runs on a premium model.

The five triggers

Consult Fable when one of these fires — and orient first (read the key files, gather the constraints) so the briefing contains evidence. A consult without evidence buys generic advice at premium prices.

1. Costly-to-revert decision, before building. Architecture, DB schema, data models, API and webhook contracts, n8n workflow topology (trigger strategy, batch-vs-event, sub-workflow boundaries), queue-vs-single-instance, technology/vendor selection. Timing: after orientation, before the first substantive write.
2. Stuck escalation. Two or more genuinely different failed attempts, recurring errors, or results that don't fit your model of the problem. Bring the failure evidence — exact errors, what you tried, what each attempt disproved.
3. Plan review. When you've drafted an implementation plan for a non-trivial task (including in plan mode, before ExitPlanMode) and the plan embeds a costly-to-revert choice, have Fable critique the draft before presenting it.
4. Pre-completion review. Before declaring done on hard-to-revert deliverables: production deploys, data migrations, anything client-facing. Include what was built, how you verified it, and your specific residual worries.
5. Unattended-automation design. Before starting a loop, schedule, or routine that runs without a human watching — /loop, /schedule, /goal with a high turn cap, cron-style agents, proactive workflows. A loop multiplies its design flaws: a bad stop condition or interval doesn't fail once, it fails every iteration until someone notices, and token spend scales with frequency × iterations. One review before it starts is the cheapest point of intervention. Have Fable check: stop conditions (deterministic and reachable?), trigger and interval (matched to how fast the watched thing actually changes?), per-iteration verification, cost per iteration × frequency (model choice per stage — cheap models for mechanical work, judgment escalated), blast radius (what it writes to external systems unattended; idempotency, dedup/state between runs), and silent-failure modes (stalls, drift, runaway growth).