How to Use Claude Subagents Without Burning Through Fable 5.1
A disciplined orchestrator-builder-refuter workflow keeps Fable focused on decisions while cheaper agents handle search, coding, research, and verification.
AI SummaryGenerated from this article
A disciplined orchestrator-builder-refuter workflow can keep Fable 5.1 focused on planning and decisions while cheaper subagents handle repository search, coding, research, and verification.
The proposed routing uses Haiku scouts, Sonnet researchers and builders, and Opus refuters or debuggers, with Fable integrating concise reports. Agents receive narrow scopes, stop conditions, output limits, and independent tests; read-only work may run in parallel, but conflicting edits remain sequential. One Reddit poster reported avoiding the five-hour limit, though that quota result is not guaranteed.
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.
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.
Work with Zeniteq
Let’s work together
We’re open to thoughtful collaborations with teams building in AI. Explore the ways we can work together.
Plans, specifies, delegates, judges, and integrates
Decisions and next actions
Scout
Haiku
Finds files, symbols, references, and call sites
Paths, line ranges, and relevance
Researcher
Sonnet
Reads documentation and source material
Verified facts, links, and unknowns
Builder
Sonnet
Implements a clear specification and runs tests
Changed files, test results, and risks
Refuter
Opus
Challenges the implementation and independently verifies it
Evidence, failures, and verdict
Debugger
Opus
Investigates difficult root causes
Reproduction, causal chain, and focused fix
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:
Inspect the actual diff.
Check every acceptance criterion.
Look for regressions and missing edge cases.
Run the relevant tests independently.
Identify unsupported claims in the builder’s report.
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:
Fable defines the objective. It writes acceptance criteria, identifies known constraints, and decides whether delegation is worthwhile.
Haiku scouts when locations are unknown. It returns paths, symbols, and line ranges without copying full files.
Sonnet researches uncertain behavior. It checks source code or documentation and marks anything unverified.
Fable writes the implementation specification. It resolves architectural questions before the builder starts.
Sonnet builds. It edits only the approved scope and runs the named tests.
Opus refutes. It reviews the diff, checks the specification, and reruns verification independently.
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.
Frequently Asked Questions
5 questions
1
How do subagents reduce Fable 5.1 usage?
Subagents reduce Fable 5.1 usage by moving bounded work into separate contexts and returning concise results. Fable can make the plan and final decision without reading every file or producing every edit itself. The saving disappears if agents receive vague tasks, repeatedly rediscover known information, or return large code and log dumps to the parent session.
2
Which AI model should each subagent use?
Use Haiku for fast repository discovery, Sonnet for source research and implementation, and Opus for adversarial review or difficult debugging. Fable remains the orchestrator that writes specifications, resolves architectural questions, and integrates results. This split is a starting point, not a rigid rule, so low-risk work may justify a cheaper reviewer.
3
Should every coding task use a subagent?
No, small coding tasks should often stay in the main Fable session. A one-line fix, a single grep, or a quick local test may cost less than creating a separate agent context and processing its report. Delegate when the task is independently executable, clearly scoped, and large enough to justify the coordination overhead.
4
Can Fable subagents run in parallel?
Yes, but parallel execution works best for independent, read-only tasks such as repository scouting, documentation research, and test analysis. Avoid having multiple agents edit the same files simultaneously. Parallel agents may finish sooner, but each worker still consumes its own context, so concurrency should be capped rather than treated as free capacity.
5
What should a subagent report include?
A subagent report should include the result, relevant file locations, verification performed, unresolved risks, and a clear next action. It shouldn’t contain complete files or lengthy tool transcripts unless Fable specifically needs them. Large artifacts should go into a scratch or handoff file, with only the path and a concise summary returned to Fable.
