The LLM Router Era Starts with Fable 5¶

---
name: plan-big-execute-small
description: Cost-saving delegation harness based on Anthropic's "plan big, execute small" cookbook. Keep planning, judgment, and synthesis on the expensive main model (Fable); fan out mechanical token-heavy work (bulk file reads, code searches, web research, log trawls, per-item transforms, doc summarization) to cheaper subagents - Sonnet 5 by default, Opus 4.8 for harder sub-tasks, NEVER Haiku (my quality floor). Trigger when the user says "/pbes", "do this cheaply", "save tokens", "frugal mode", or when a task involves pulling large volumes of content (many files, many web pages, long logs) through the model.
---

# Plan Big, Execute Small

You (the main loop, running an expensive frontier model) are the **coordinator**. Your tokens cost 3-10x more than a Sonnet subagent's. The single biggest cost driver in agentic work is *mechanical reading* - files, web pages, logs, search results pulled into context. Move that reading onto cheap subagents; keep only planning, judgment, and synthesis here.

**Key insight from the cookbook:** the savings come from **rate arbitrage, not reading less**. Both approaches read roughly the same volume - the split team was 2.5x cheaper and 3x faster because 84-98% of input tokens were billed at the worker rate, and workers ran in parallel. Do NOT respond to cost pressure by skimping on rigor; respond by changing *who* reads.

## Rate table (why this works)

| Model | Input $/M | Output $/M | Role |
|---|---|---|---|
| Fable 5 | $10 | $50 | Coordinator only: plan, decompose, verify, synthesize |
| Opus 4.8 | $5 | $25 | Worker for reasoning-heavy sub-tasks (tricky debugging, nuanced analysis) |
| Sonnet 5 | $3 ($2 intro) | $15 ($10 intro) | Default worker: reading, searching, per-item transforms |

**Quality floor (my standing preference): never use Haiku for workers.** Use **Sonnet 5 and Opus 4.8 interchangeably** - both are approved worker tiers, don't agonize over the choice. Rough default: Sonnet for volume reading/searching, Opus when the sub-task smells reasoning-heavy or you're unsure - either way it's still 2-5x cheaper than Fable.

Every token a Sonnet worker reads instead of you is a 3-5x saving on that token. It also keeps your own transcript small, which compounds: your context is re-sent (cache-read billed) on every subsequent turn.

## Step 1 - Classify the work

Before acting, split the task into:

- **Judgment work** (stays here): understanding the ask, decomposing into sub-questions, deciding the approach, resolving conflicts between worker reports, verifying suspicious findings, writing the final deliverable.
- **Mechanical work** (delegate): anything where the *procedure* is clear and the cost is in volume - read N files and report X, search the web for Y and return evidence, trawl logs for pattern Z, apply the same transform to each item, summarize each document.

If the whole task is mechanical and small (one grep, one file read), just do it - delegation has a floor (see anti-patterns).

## Step 2 - Fan out with the Agent tool

Spawn workers with an explicit cheap `model`, in parallel (one message, multiple Agent calls), in the background:

- `subagent_type: "Explore"` + `model: "sonnet"` or `"opus"` - codebase searches and file-location sweeps.
- `subagent_type: "general-purpose"` + `model: "sonnet"` or `"opus"` - web research, multi-file reading, per-item transforms, debugging.
- Sonnet 5 and Opus 4.8 are interchangeable worker tiers - pick freely, don't deliberate. Lean Opus when the sub-task needs real reasoning (root-cause debugging, nuanced comparison, anything where a wrong worker conclusion would mislead the synthesis).
- Never `model: "haiku"` (quality floor); never spawn `fable` workers (no arbitrage).

For large structured fan-outs (10+ items, multi-stage, verify passes) - and only when the user has opted into multi-agent orchestration - use the Workflow tool instead, with per-agent overrides: `agent(prompt, {model: 'sonnet', effort: 'medium'})` for mechanical stages (drop to `'low'` only for truly rote transforms); leave `model` unset (inherit) only for the final judge/synthesis stage.

## Step 3 - Write worker briefs correctly

Workers know NOTHING you don't put in the prompt - not the conversation, not your plan, not the other workers' briefs. From the cookbook: "Everything the coordinator believes about its workers comes from its own system prompt."

Each brief must contain:
1. **One focused sub-question** - self-contained, no references to "the task above".
2. **Rigor instructions** - "try multiple query phrasings / search patterns, follow promising leads, cross-check across sources." Cheap models default to shallow; the brief supplies the rigor.
3. **An evidence-bearing report format** - require `file:line` references, URLs, verbatim quotes, exact values. You will verify from evidence, not by re-reading the sources yourself. Ask for structured findings (a list of facts + evidence), NOT polished prose.
4. **A size cap** - "report at most N findings / keep the report under ~500 words" so worker output doesn't flood your context.

## Step 4 - Synthesize and verify here

- Read only the reports. Do not re-read what workers already read - that pays the expensive rate twice and defeats the pattern.
- Spot-check: if a finding is load-bearing and the evidence looks thin, send ONE targeted verification (a single file read, or a cheap verify-subagent with a refute-this brief) rather than redoing the sweep.
- Conflicting reports -> resolve with judgment here, or spawn one tie-breaker worker with both claims and their evidence.

## Anti-patterns (from the cookbook's measurements)

- **Over-sharding.** Delegation has a floor: each worker pays a bootstrap cost (system prompt + brief + report). Narrowly-scoped micro-briefs *increased* total cost in the cookbook's tests. A brief should represent at least several tool calls' worth of mechanical work. 3-6 meaty workers beat 20 tiny ones.
- **Delegating judgment.** Final synthesis, architecture decisions, security-sensitive conclusions, and anything needing the full conversation context stay on the main model. That's what the expensive tokens are *for*.
- **Prose reports.** Workers returning essays waste their output tokens and your input tokens. Demand structured findings + evidence.
- **Cutting rigor to cut cost.** A solo agent that "reads less" is a lower-rigor product, not a cheaper equivalent. Keep the rigor; move it to the cheap rate.
- **Doing the sweep yourself first "to understand it".** Scout minimally (list files, scope the diff - cheap), then delegate the heavy reading. Don't pull 50 files into your own context and then also spawn workers.

## Cheap-by-default habits (apply even without fan-out)

- Noisy investigation (grep sweeps, log trawls, broad search) -> always a subagent; keep only the conclusion in the main transcript.
- Long web pages / docs -> a `sonnet` worker fetches and distills; you read the distillation.
- When the user asks for a quick answer, answer directly - this skill is for volume, not for adding ceremony to small tasks.