How to Use Claude Subagents Without Burning Through Fable 5.1

AI coding allowances disappear quickly when one premium model searches the repository, reads every dependency, writes the code, runs the tests, reviews its own work, and then explains the entire process. The problem isn’t necessarily the amount of coding. It’s repeatedly spending expensive context on work that a smaller model could handle.

A Claude Code workflow shared on Reddit takes the opposite approach. Its central rule is simple: “Fable is my orchestrator, not my worker.” The poster reported running Fable 5.1 on High for long periods without hitting the five-hour limit, with the dashboard showing a nearly even split between Fable and all-model usage. That is one person’s experience rather than a guaranteed quota result, but the underlying strategy is widely applicable.

The real optimization isn’t merely turning on subagents. It’s controlling which model receives each task, how much context it reads, what it may change, and how much information it sends back.

Make Fable the Orchestrator, Not the Worker

Fable should own the parts of an AI coding session that require continuity and judgment:

• Turning a request into an implementation plan
• Defining acceptance criteria
• Deciding which agents to launch
• Resolving architectural questions
• Reading concise reports
• Integrating completed work
• Deciding whether a result is ready to accept

It shouldn’t spend most of its context locating symbols, reading large files, making mechanical edits, or generating lengthy documentation.

That distinction fits the architecture described in the Claude Code subagent documentation. A subagent starts with its own context window, system prompt, tools, permissions, and model selection. It performs the assigned task independently, then returns its result to the parent conversation. The parent doesn’t need to absorb every intermediate tool call or every file the worker examined.

A practical division of labor looks like this:

The exact economics of a Fable allowance may differ from API billing, but Anthropic’s published model pricing illustrates the general hierarchy behind this routing strategy: Haiku is the lower-cost option, Sonnet sits in the middle, and Opus costs more. Using the strongest model for every repository search is rarely a sensible allocation of reasoning capacity.

Give Every Agent a Narrow Contract

A subagent with a vague prompt can waste more context than it saves. “Investigate authentication and fix any problems” invites the agent to wander across the repository, reinterpret the task, and return an oversized report.

Each agent should instead receive a compact contract:

Goal:
[One specific outcome]

Scope:
[Exact files, directories, symbols, URLs, or documents]

Allowed changes:
[What the agent may edit, create, or delete]

Required verification:
[Tests, commands, sources, or acceptance criteria]

Do not:
[Explicit boundaries and prohibited changes]

Known facts:
[Relevant discoveries already made]

Output:
[Required report structure]

Output limit:
[Suggested maximum length]

Stop conditions:
[When to stop and report rather than continue]

The known facts field prevents rediscovery. If Fable already knows that the retry loop lives in src/api/client.ts, the builder shouldn’t search the whole codebase to find it again.

The stop conditions field is just as important. An agent should stop when it leaves the assigned scope, encounters an architectural decision, can’t reproduce the problem, or needs to modify a prohibited file. It should report the blocker rather than improvising a broader project.

Different roles also need different output formats. A scout might return:

- src/auth/session.ts:88-132
  Symbol: refreshSession()
  Relevance: Owns the failed-token retry loop

- tests/auth/session.test.ts:211-268
  Relevance: Covers refresh success but not repeated failure

Unverified:
- A second retry path may exist in the mobile client

That gives Fable useful coordinates without pushing complete files into its context. Researchers should separate verified facts from assumptions, while builders should report changed files and test commands instead of pasting the finished implementation.

Use the Builder-Refuter Loop for Coding

The default coding path can remain short:

Fable → Builder → Refuter → Fable

Fable first converts the request into a specification. That specification should name the relevant files, expected behavior, edge cases, prohibited changes, and tests that must pass.

A Sonnet builder then performs the implementation. It receives enough information to begin coding immediately, but not an unrestricted invitation to redesign adjacent systems. Its final report can be limited to:

• What changed
• Which files changed
• Which tests ran
• The result of each test
• Any remaining uncertainty

The Opus refuter gets the original acceptance criteria and access to the resulting diff. Its job isn’t to repeat the builder’s explanation or approve a convincing “done” message. It should try to falsify the implementation.

A useful refuter prompt asks it to:

1. Inspect the actual diff.
2. Check every acceptance criterion.
3. Look for regressions and missing edge cases.
4. Run the relevant tests independently.
5. Identify unsupported claims in the builder’s report.
6. Return a pass, fail, or blocked verdict with evidence.

Separating implementation from acceptance reduces the risk of one agent grading its own work. The refuter may use the builder’s report to locate test commands, but it shouldn’t treat the builder’s conclusions as evidence.

Reserve the Opus debugger for problems that survive this routine loop. Before launching it, provide a reproducible failure, the relevant logs, attempted fixes, and the smallest known scope. Otherwise, a powerful debugging model may spend a large reasoning budget exploring a problem that was never adequately defined.

Protect Fable’s Context From Bulk Output

Subagent isolation only helps if the returned reports remain compact. Claude Code can return a subagent’s final result without exposing all of its intermediate work, but a worker can still defeat that advantage by putting thousands of lines into its final message.

Give each role a clear reporting boundary:

• Scouts return locations, not full files.
• Researchers return findings, sources, and unresolved questions.
• Builders return a diff summary and test evidence.
• Refuters return failures, evidence, and a verdict.
• Debuggers return the causal chain and recommended next step.

When an agent produces something too large for a useful chat report, have it write the material to a scratch file. Logs, dependency maps, benchmark output, code inventories, and long research notes can live in a gitignored directory such as .ai/scratch/.

The agent should return only the path and a short summary:

Artifact: .ai/scratch/oauth-investigation.md

Summary:
- Found two independent token refresh paths.
- The desktop path already limits retries.
- The web path can retry indefinitely after a 401.
- Relevant symbols and test gaps are listed in the file.

The next agent can read that artifact directly. Fable only needs the information required to choose the next action.

Long-running projects benefit from a separate handoff document containing the current goal, accepted decisions, completed changes, tests, open risks, and next task. A new session can load that file instead of rebuilding the project history through another expensive exploration pass.

Batching related changes offers another reduction. If three fixes touch the same large parser, group them into one scoped implementation task when practical. Reopening and rereading the parser for three separate agents can cost more than the edits themselves.

Parallelize Reading but Serialize Conflicting Edits

Parallel agents are most useful for independent, read-only work. A scout can map the repository while a researcher checks external documentation and a reviewer studies an existing test suite.

Parallel writing needs stricter boundaries. Two builders editing the same files can create conflicting changes, duplicate effort, or force Fable to reconcile incompatible interpretations. Keep writing sequential unless the tasks touch clearly separate modules and have a defined integration point.

This distinction matters for large fan-out modes. Anthropic’s agent-team documentation warns that multi-agent coordination uses substantially more tokens than a normal session because every worker maintains its own context. Parallelism can reduce elapsed time, but it doesn’t reduce the total amount of reading and reasoning performed.

If your environment offers Ultracode or another mode that launches a larger workflow, leave it off by default. Before enabling it, answer three questions:

• Can the task be divided into genuinely independent workstreams?
• How many agents may run?
• What condition ends the workflow?

Set a hard agent cap and give Fable permission to stop workers that leave scope. An agent going in the wrong direction shouldn’t continue consuming context simply because it hasn’t reached a natural stopping point.

Don’t Delegate Tasks Smaller Than the Delegation

A one-line correction, a single search, or a quick local inspection often belongs in the Fable session. Spawning an agent introduces a fresh context, startup latency, instructions, a result report, and coordination work.

Claude Code’s documentation explicitly lists those tradeoffs: subagents begin with fresh context, add latency, and require enough information to work independently. Tasks involving rapid back-and-forth or several tightly connected phases may fit the main conversation better.

Before delegating, check whether the task:

• Contains enough work to justify agent startup
• Can be described without a long briefing
• Benefits from a cheaper or more specialized model
• Produces intermediate information Fable doesn’t need to see
• Can finish without frequent architectural decisions

If most answers are no, let Fable handle it directly.

Verification should also match the risk. A one-line typo doesn’t always need an Opus refuter. A normal behavioral change can follow the builder-refuter loop. Cross-cutting migrations may justify scouting, research, implementation, and independent review. Difficult intermittent failures deserve the debugger only after someone has produced a reliable reproduction.

A Repeatable Fable 5.1 Runbook

For a typical coding task, the complete workflow can remain concise:

1. Fable defines the objective. It writes acceptance criteria, identifies known constraints, and decides whether delegation is worthwhile.
2. Haiku scouts when locations are unknown. It returns paths, symbols, and line ranges without copying full files.
3. Sonnet researches uncertain behavior. It checks source code or documentation and marks anything unverified.
4. Fable writes the implementation specification. It resolves architectural questions before the builder starts.
5. Sonnet builds. It edits only the approved scope and runs the named tests.
6. Opus refutes. It reviews the diff, checks the specification, and reruns verification independently.
7. Fable integrates or rejects the result. It makes the final judgment and records relevant decisions in the handoff document.

The sequence doesn’t need every role on every task. Scouting is unnecessary when the files are already known. External research can be omitted when the expected behavior is fully specified. Debugging is reserved for cases where the builder-refuter loop can’t identify the cause.

Consistency matters more than agent count. The workflow saves Fable usage when every agent receives a bounded task and produces a bounded artifact.

Final Thoughts

The most valuable part of this approach isn’t the choice between Haiku, Sonnet, Opus, and Fable. It’s the interface between them.

A poorly scoped scout can search an entire repository and return a wall of text. A disciplined builder can complete a substantial change while returning only a file list, test evidence, and two unresolved risks. Model routing helps, but context routing makes the system sustainable.

The original poster’s near-continuous usage without reaching the five-hour limit remains anecdotal. Repository size, task complexity, plan limits, prompt length, and agent behavior will change the result. Still, the architecture is sound: keep Fable responsible for specifications and decisions, push bounded execution to workers, and prevent intermediate debris from flowing back into the orchestrator’s context.