Fable 5: The Architect, Not the Worker

My Thoughts

Fable 5 is insanely capable, but expensive.

Most people waste it on tiny tasks cheaper models can handle. Don't use Fable as your default worker.

Use Fable as the architect.

Fable plans.
Others execute.
Fable reviews.

10-80-10 Rule

10% — Plan with Fable
Architecture, risks, edge cases, decisions.

80% — Execute
Opus → Deep reasoning
Sonnet / GPT-5.5 / Codex → Coding
Haiku → Formatting, tests, cleanup
Kimi / GLM → Long-context analysis
DeepSeek / Qwen → Boilerplate + bulk work

10% — Review with Fable
Bugs, missed edge cases, final sign-off.

Claude x Codex Setup

Use Claude Code as the orchestrator. Use Codex as the execution engine.

Install Codex

npm install -g @openai/codex

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/codex:setup

Create Subagents

The old /agents wizard was removed. Ask Claude to create them.

Create a personal subagent called deep-reasoner.

Save it to ~/.claude/agents/ so it works across all projects.

Model: Opus 4.8

Use for architecture, planning, debugging, risks, edge cases, and hard technical decisions.

Instructions:
Think deeply, then return a concise conclusion.
Avoid simple mechanical edits.

Create a personal subagent called fast-worker.

Save it to ~/.claude/agents/ so it works across all projects.

Model: Sonnet 5

Use for boilerplate, tests, formatting, refactors, simple edits, and implementation.

Instructions:
Execute efficiently.
Keep output short.
Report changed files and test results.
Ask only when blocked.

Add Codex SKILL.md

Ask Fable once:

Write a SKILL.md that teaches Codex how to:
- Execute implementation plans
- Run tests and report clearly
- Follow this project structure
- Make safe code changes
- Avoid unrelated files

Short CLAUDE.md

# CLAUDE.md

## Role
You are the orchestrator.
Plan, delegate, and review.
Do not waste premium reasoning on mechanical work.

## Routing
Fable → Planning, architecture, final review
Opus → Deep reasoning and complex debugging
Sonnet / GPT-5.5 / Codex → Implementation
Haiku → Formatting, tests, cleanup
Kimi / GLM → Long-context analysis
DeepSeek / Qwen → Boilerplate and bulk work

## Workflow
1. Plan with Fable.
2. Execute with the right cheaper model.
3. Keep outputs short.
4. Review with Fable before shipping.

## Delegation
Reasoning-heavy → deep-reasoner
Mechanical work → fast-worker
Implementation → Codex / Sonnet / GPT-5.5

## Codex
Codex is a peer executor.
Use it for scoped coding, UI checks, and fresh perspective.

## Effort
Default to Medium.
Use High for architecture/debugging.
Avoid Max unless needed.

## Output
State changes.
List files touched.
Report tests.
Flag blockers.

/goal and /loop

/goal gives Claude a finish line.

/goal refactor auth until all tests pass without touching payments or database schema

/loop repeats a check or task until the timer ends.

/loop run security checks on all API endpoints --interval 24h --expires 7d

Use both for bigger jobs:

/goal rebuild dashboard until Lighthouse scores 90+ on mobile without breaking tests
/loop run the dashboard goal above --interval 6h --expires 48h

Prompts To Get You Going

Read my CLAUDE.md and project structure.

Set up a 10-80-10 routing system.

Create:
1. Cleaner CLAUDE.md
2. Model routing table
3. Task list showing which model handles what

Do not code. Just plan.

I want to build: [feature]

Do not code yet.

Create a plan with phases, file changes, risks, edge cases, test plan, and what Codex/Sonnet should do first.

Quick Tips

Don't leave Fable as default.
Start fresh chats often.
Give full context upfront.
Use Codex for implementation.
Use Fable only for serious reasoning.
Default to Medium.
Avoid Max unless needed.

Use the right model for the right job.

When to Break the 10-80-10 Rule

The rule is a default, not a law. A few situations where breaking it is correct:

When speed matters more than cost. If you're debugging a production incident at 2am, use the best model for everything. The rule optimises for normal operations, not emergencies.

When the 80% task is actually architectural. Some implementation tasks look mechanical but contain hidden complexity — ambiguous requirements, cross-cutting concerns, security implications. If you discover this mid-task, escalate to Fable. Don't force a cheaper model to guess at things that need architectural judgement.

When the review reveals a design flaw. If Fable's 10% review catches something that requires redesigning the approach, the next iteration starts with a full Fable planning session, not another 10% allocation.

When the task is genuinely short. For a five-line change with no architectural implications, the overhead of routing through three models is more expensive than just using Sonnet for all three phases.

The rule exists to prevent the most common mistake: using the most capable model for everything by default. Once you've internalized the cost of that habit, you'll know when breaking the rule is actually the right call.

Common Mistakes When Implementing This Workflow

Using Fable for execution tasks. The most expensive mistake. Fable reasoning a boilerplate CRUD route is like using a surgeon to change a lightbulb. Route mechanical work to Sonnet or Codex.

Skipping the plan phase. Sending implementation tasks directly to the execution model without a Fable plan means the cheaper model makes architectural decisions it isn't well-suited for. The plan phase is where ambiguity gets resolved — skipping it moves ambiguity into the code.

Over-specifying in the plan. Fable's plan should define what and why, not how line by line. Over-specified plans constrain the execution model unnecessarily and create brittleness when the implementation encounters reality.

Not giving the execution model enough context. The 80% model doesn't have Fable's reasoning in its context — it only sees what you pass it. Include the relevant parts of the plan, the constraints, and the expected output format. Context you assume is context the model doesn't have.

Treating the review as a formality. The 10% review is where bugs and missed edge cases get caught. If Fable's review is consistently finding nothing, either the execution model is doing excellent work (validate this with tests) or the review prompt isn't specific enough to surface issues.