PowerUp Coaching — Living Knowledge Base

How Fable Beats Opus for 80% Less

42 min read

How Fable Beats Opus for 80% Less

Plus 5 More Ways to Stretch Your Claude Usage Limits

Audience: Claude Pro users, Claude Code users, AI builders, developers, technical creators, and power users who are hitting usage limits faster after moving from Sonnet or Haiku to Opus or Fable.

Promise: By the end of this guide, you will understand why your Claude usage limits disappear faster with frontier models, how Fable can sometimes outperform Opus at a fraction of the burn, and how to build a workflow that preserves your strongest model usage for the moments where it actually matters.

Core idea: Claude usage limits are not just about how many messages you send. They are about how many tokens Claude has to process, how much reasoning effort you ask for, how much old context you drag forward, how verbose the model gets, and whether you are using expensive models for cheap work.

This is a guide to Claude tokenomics.

Not API tokenomics in the abstract. Practical tokenomics for people who use Claude every day and suddenly notice that their plan feels smaller than it used to.

Table of Contents

  1. The New Claude Usage Shock
  2. The Benchmark That Changes the Conversation
  3. The Fable Usage Ladder
  4. Use Fable as Architect, Not Laborer
  5. Stop Paying the Stale-Context Tax
  6. Slim Down Always-Loaded Context
  7. Do Not Feed Fable Terminal Noise
  8. Retrieve the Answer, Not the Haystack
  9. Use Subagents for Verbose Work
  10. Advisor Mode: Cheap Execution, Expensive Judgment
  11. Output Discipline: Make Claude Write Less
  12. Measure Before You Optimize
  13. The Claude Usage Stretch Playbook
  14. Quick Setup Stacks
  15. Claims, Caveats, and How to Think About the Numbers
  16. Sources

1. The New Claude Usage Shock

Why this matters

Many Claude Pro users are running into the same problem: the usage limits feel much tighter than before.

The experience usually sounds like this:

  • “I used to work in Claude for a long time before hitting limits.”
  • “Now I switch to Opus or Fable and the limit disappears fast.”
  • “I am not sending that many more messages, so what changed?”
  • “Why does one coding session eat so much of the plan?”

The answer is that the limiting factor is not only message count. It is token burn.

Every Claude conversation is made of tokens. Tokens include your prompt, Claude’s response, tool results, file contents, previous conversation context, memory instructions, system instructions, and, for models that use extended thinking, reasoning tokens. A short message can be cheap in a short session and expensive in a long session. A simple coding request can be cheap if Claude only needs one file and expensive if Claude reads half a repo, digests test logs, keeps old history alive, and explains everything in detail.

Fable and Opus make this more visible because they are stronger models, and stronger models tend to be used on bigger, messier, more context-heavy tasks. If you use them exactly the way you used Sonnet or Haiku, you may burn through your limits two or three times faster.

That is not a moral failure. It is a workflow mismatch.

What is actually happening

When people move to stronger models, three things usually change at once:

  1. They use the model for harder tasks. Harder tasks require more context, more reasoning, more tool use, and more follow-up.
  2. They keep longer sessions alive. The model accumulates plans, files, logs, decisions, mistakes, and summaries. Each new message has to operate inside that accumulated context.
  3. They stop noticing token-heavy side effects. Terminal output, MCP tool definitions, verbose explanations, large memory files, screenshots, docs, and codebase scans all become part of the token economy.

The result is a very specific kind of frustration: you feel like you are using Claude normally, but the plan behaves as if you suddenly became a heavy user.

In one sense, you did. You started spending more tokens per unit of work.

How to think about usage limits

Claude usage limits are easiest to understand as a budget with several leak points:

Total usage burn =
  model choice
+ effort / thinking level
+ input context size
+ output length
+ tool and terminal output
+ stale conversation history
+ always-loaded instructions
+ repeated retries and rework

Most people optimize only the first variable: model choice.

They ask, “Should I use Sonnet, Opus, or Fable?”

That matters, but it is only one lever. The better question is:

What is the cheapest workflow that preserves the quality I need?

Sometimes that means using a cheaper model.

Sometimes it means using Fable at a lower effort level.

Sometimes it means using Fable only for planning.

Sometimes it means clearing context, compressing logs, moving instructions into skills, or asking a subagent to do noisy exploration so your main session stays clean.

Benefit of this mindset

Once you see Claude usage as tokenomics, your control surface gets much larger.

Instead of thinking:

I guess I have to stop using Fable.

You can think:

I need to stop wasting Fable on low-value tokens.

That distinction matters. The goal is not to avoid strong models. The goal is to spend strong-model tokens where strong-model reasoning changes the outcome.

2. The Benchmark That Changes the Conversation

Why this matters

The most important hook from the source video is not merely that Fable is powerful. Most users already assume that.

The interesting claim is that Fable on low effort can outperform Opus on max effort in the benchmark shown, while costing dramatically less.

DeepSWE score vs average cost per task, showing Fable effort levels against Opus and other models

Source: DeepSWE v1.1 leaderboard by Datacurve, 113 tasks, updated July 1, 2026. Screenshots annotated from the leaderboard view.

The graph is useful because it shows two things at once:

Vertical axis:
  DeepSWE score, or task performance.
 
Horizontal axis:
  Average cost per task.
  Lower cost is farther to the right.

So the most efficient results live toward the upper-right: higher score, lower average task cost.

The headline comparison comes from two points on the orange Claude line.

First, claude-fable-5 [low] sits at about a 60% DeepSWE score with an average cost of $3.76 per task:

Annotated DeepSWE graph showing Claude Fable 5 low at 60% score and $3.76 average cost per task

Second, claude-opus-4.8 [max] sits at about a 59% DeepSWE score with an average cost of $13 per task:

Annotated DeepSWE graph showing Claude Opus 4.8 max at 59% score and $13 average cost per task

That gives you the cleanest version of the argument:

Fable 5 low:
  60% score
  $3.76 average cost per task
 
Opus 4.8 max:
  59% score
  $13 average cost per task

That means Fable on low effort is not merely cheaper. In this benchmark, it roughly matches or slightly beats Opus on max effort while costing less than one-third as much.

The simple math:

Approximate savings:
  ($13 - $3.76) / $13 = 71% cheaper

Or put differently:

$13 / $3.76 = 3.46x

So in this benchmark comparison, Fable low delivered roughly matched or slightly better performance while giving you about 3.5x more cost-normalized usage than Opus max.

The video also compares Fable low against Fable max, where the spread is even more dramatic: roughly $3.76 at low effort versus roughly $22 at max effort. That is the “more than 80% less” claim:

Fable 5 max:
  about $22 per task
 
Fable 5 low:
  about $3.76 per task
 
Approximate savings:
  ($22 - $3.76) / $22 = 83% cheaper

So there are two different but related lessons:

Against Opus:
  Fable low can match or beat Opus max at roughly 70% lower cost.
 
Against Fable max:
  Fable low can preserve much of Fable's performance while cutting average task cost by more than 80%.

That changes the conversation because most users assume there are only two choices:

  1. Use the stronger model and burn limits quickly.
  2. Use the cheaper model and accept weaker results.

Effort level creates a third option:

  1. Use the stronger model at a lower reasoning budget.

That is the core of the savings idea. The direct Opus comparison supports the “matched or better performance for roughly 70% less” claim. The 80% version comes from comparing Fable low against Fable max.

You are not only choosing the model. You are choosing how hard the model thinks.

This is also why the graph belongs early in the guide. It gives people permission to test lower effort levels without feeling like they are automatically downgrading quality. The practical conclusion is not “always use low.” It is:

Do not assume high or max effort is the default price of using Fable.

What effort level actually controls

In Claude Code, effort level controls the reasoning intensity for models that support adaptive reasoning. Higher effort can improve performance on complex tasks, but it also increases usage. Anthropic’s cost-management docs explicitly call out extended thinking as a cost lever and note that thinking tokens are billed as output tokens. They also recommend lowering effort for simpler tasks where deep reasoning is not required.

The practical translation:

Low effort = cheaper reasoning
Medium effort = balanced reasoning
High effort = heavier reasoning
Max effort = expensive reasoning

Higher is not automatically better. Higher is better only when the task benefits from deeper reasoning.

If you ask Fable to do something straightforward, high or max effort may spend extra reasoning tokens to solve a problem that did not need them.

The key mechanism

The mechanism is not “Fable is cheaper than Opus.”

Fable is not generally cheaper than Opus. The precise mechanism is:

Fable at low effort can sometimes deliver better benchmark performance than Opus at max effort, while using far less reasoning budget.

That is why the title should preserve curiosity:

How Fable Beats Opus for 80% Less

The explanation comes later:

Fable low > Opus max in the benchmark shown

The educational point is bigger than the benchmark. The point is that effort level is a first-class cost-control lever.

How to apply it

In Claude Code, use:

/effort

Then choose the lowest level that can reliably handle the task.

A useful default ladder:

Low:
  - simple UI work
  - scoped edits
  - small refactors
  - simple transformations
  - boilerplate generation
  - light review
 
Medium:
  - normal coding
  - bug fixing
  - moderate debugging
  - feature implementation
  - light architecture
  - synthesis across a few files
 
High:
  - ambiguous bugs
  - complex architecture
  - multi-step migrations
  - decisions with tradeoffs
  - tasks where wrong direction creates expensive rework
 
Max:
  - deeply stuck problems
  - high-stakes design decisions
  - long-horizon reasoning
  - tasks where failure is more expensive than token burn

Example

Weak usage pattern:

/model fable
/effort high
 
Build this settings page.

Better usage pattern:

/model fable
/effort low
 
Build this settings page. Use the existing component patterns. Make the smallest sufficient changes. Do not redesign adjacent flows.

Even better if the task is routine:

/model sonnet
 
Build this settings page. Use the existing component patterns. Make the smallest sufficient changes. Ask for escalation only if you hit an architecture decision.

Benefit

Effort control lets you keep access to stronger model behavior without always paying for the deepest reasoning mode. It is the fastest, lowest-friction change most users can make.

If someone only changes one habit, it should be this:

Try low or medium before assuming Fable needs high.

3. The Fable Usage Ladder

Why this matters

Most users choose models emotionally.

They use the model that feels safest:

I want the best answer, so I will use the best model.

That is understandable. It is also expensive.

The better approach is to choose the model based on task shape.

This is not about being cheap. It is about matching cognitive difficulty to model capability.

What the ladder does

The Fable Usage Ladder gives you a decision structure:

Use the cheapest capable model.
Escalate only when the task demands it.
Lower effort before abandoning the stronger model.
Reserve high effort for high-leverage uncertainty.

This prevents two common mistakes:

  1. Under-modeling: using a cheap model for a task that needs stronger reasoning, then wasting usage on retries.
  2. Over-modeling: using Fable for tasks that Sonnet could do cleanly.

Both waste tokens. Under-modeling wastes tokens through rework. Over-modeling wastes tokens through unnecessary capability.

A practical ladder

Use this as a starting point:

Haiku:
  - classification
  - extraction
  - formatting
  - short summaries
  - disposable drafts
  - simple subagent tasks
 
Sonnet:
  - normal coding
  - implementation
  - light debugging
  - docs
  - repetitive changes
  - routine agent work
 
Opus:
  - complex coding
  - code review
  - multi-file debugging
  - higher-quality implementation
  - tasks where Sonnet gets sloppy
 
Fable low / medium:
  - strong reasoning with controlled burn
  - planning
  - architecture
  - benchmark-sensitive tasks
  - difficult synthesis
 
Fable high / max:
  - rare frontier judgment
  - deeply ambiguous problems
  - high-stakes decisions
  - long-horizon agentic work

This is not a rigid hierarchy. It is a routing system.

The question is not “Which model is best?”

The question is:

Which model is sufficient for this part of the job?

How to use the ladder during a session

Before starting, ask:

What part of this task actually requires intelligence?

Most tasks have several parts:

1. Gather context
2. Understand the problem
3. Make a decision
4. Execute edits
5. Run tests
6. Summarize results
7. Review risk

Only some of those parts require Fable.

For example:

Task: Refactor an authentication flow
 
Context gathering: Sonnet or Opus
Architecture decision: Fable medium/high
Implementation: Sonnet or Opus
Test fixing: Sonnet
Final review: Fable low/medium or Opus

This is how you stretch limits without giving up quality.

Benefit

The ladder gives users a repeatable model-selection habit. It reduces panic-switching to expensive models and reduces false economy from using weak models where they cause expensive retries.

The goal is not “always use cheap.”

The goal is:

Spend just enough model for the current layer of the work.

4. Use Fable as Architect, Not Laborer

Why this matters

This is the strategic heart of the workflow.

Fable is expensive because it is good at the things that are hardest for weaker models:

  • seeing the whole system
  • weighing tradeoffs
  • identifying hidden risks
  • decomposing ambiguous work
  • making architecture decisions
  • choosing a route through uncertainty
  • recovering when other agents get stuck

Those are architecture tasks.

But many users make Fable do everything:

  • search files
  • read logs
  • run tests
  • write boilerplate
  • implement routine edits
  • generate long explanations
  • gather docs
  • execute every step of its own plan

That turns Fable into a general laborer.

It may do the work well, but you are paying premium reasoning rates for tasks that do not need premium reasoning.

What “architect, not laborer” means

Use Fable to create the plan, not necessarily to perform every step.

The pattern:

Fable:
  - diagnoses the problem
  - designs the approach
  - decomposes the task
  - identifies risk
  - assigns model/tool roles
  - reviews critical decisions
 
Cheaper models:
  - search
  - read
  - implement
  - test
  - summarize
  - clean up

This is not about disrespecting cheaper models. It is about giving them the right work.

Sonnet can execute a good plan. Opus can execute a harder plan. Fable should write or validate the plan when the plan quality matters.

How to do it

Use a planning prompt like this:

Act as the architect, not the executor.
 
Goal:
[Describe the outcome]
 
Context:
[Paste only the relevant context]
 
Constraints:
[Time, files, quality bar, tools, risks]
 
Your task:
1. Diagnose the work.
2. Break it into work packages.
3. Identify which packages require Fable-level reasoning.
4. Assign the cheapest capable model to each package.
5. Produce a handoff plan another model can execute.
 
Do not write code yet.
Do not perform routine execution.
Output a clear plan with checkpoints and verification steps.

Example output you want:

Package 1: Inspect current auth middleware
Model: Sonnet
Why: context gathering, low reasoning
 
Package 2: Decide migration strategy
Model: Fable medium
Why: architecture tradeoff, high blast radius
 
Package 3: Implement chosen migration
Model: Opus or Sonnet
Why: execution once plan is fixed
 
Package 4: Run tests and summarize failures
Model: Sonnet
Why: verbose output, routine diagnosis
 
Package 5: Final risk review
Model: Fable low or Opus
Why: check assumptions and edge cases

Simple version

If multi-model routing feels too complex, use this:

  1. Start a Fable session.
  2. Ask Fable for a plan only.
  3. Save the plan to Markdown.
  4. Start a cheaper model session.
  5. Give the cheaper model the plan and ask it to execute.
  6. Bring back a concise summary for Fable only if a decision point appears.

You do not need a complex agent framework to get most of the benefit.

Benefit

This gives you the strongest part of Fable without paying for Fable to do every low-level action.

The benefit is both economic and qualitative:

  • less token burn
  • clearer plans
  • fewer wandering sessions
  • better delegation
  • easier review
  • less rework

The deeper principle:

Use Fable where wrong judgment is expensive.
Use cheaper models where correct execution is enough.

5. Stop Paying the Stale-Context Tax

Why this matters

This is one of the most important ideas in the entire guide:

Every message inherits your mess.

As a Claude session gets longer, it accumulates context:

  • old plans
  • old errors
  • stale assumptions
  • terminal output
  • code snippets
  • tool results
  • files that no longer matter
  • abandoned implementation paths
  • long explanations
  • screenshots or pasted docs
  • previous corrections

Even if your next message is short, the model may still process a large amount of previous conversation context.

Anthropic’s Claude Code cost docs say token costs scale with context size and explicitly recommend using /clear between unrelated tasks because stale context wastes tokens on every subsequent message.

What stale context looks like

Stale context is anything that was useful earlier but is no longer useful now.

Examples:

You debugged a failed build for 45 minutes.
The build is fixed.
Now you ask Claude to write a README.
The build logs are still in the session.

Or:

You explored three possible architectures.
You chose one.
Now Claude still sees the rejected options.

Or:

You pasted a long transcript.
Now you ask for a title.
Claude still has the full transcript in context.

Sometimes stale context is not only expensive; it is actively harmful. It can cause Claude to keep optimizing for constraints that no longer apply.

How to manage it

Use /clear when switching to an unrelated task:

/clear

Before clearing, rename the session if you may need to return:

/rename fable-tokenomics-guide-research

Then resume later if needed:

/resume

Use /compact when the task is related but the session has become bloated:

/compact Focus on:
- decisions made
- current file paths
- unresolved bugs
- test results
- next action
 
Discard:
- failed approaches
- old logs
- verbose exploration
- unrelated discussion

The difference:

/clear = start fresh
/compact = preserve the useful state, summarize the rest

When to clear

Clear when:

  • you switch projects
  • the old task is done
  • the session contains huge logs
  • the session went down a wrong path
  • you are moving from research to execution
  • you are moving from coding to writing
  • the next task does not depend on previous details

When to compact

Compact when:

  • the task is still active
  • the plan is still useful
  • Claude has important decisions in memory
  • you need continuity but not raw history
  • you are approaching context limits

Example compaction instruction

/compact Preserve only the information needed to continue implementation:
 
1. Goal and acceptance criteria
2. Files changed
3. Current plan
4. Decisions already made
5. Commands already run
6. Remaining test failures
7. Risks or unresolved questions
 
Remove:
- raw terminal logs unless still relevant
- old rejected approaches
- repeated explanations
- unrelated conversation

Benefit

Context hygiene gives you more useful work per limit because each future turn starts lighter.

It also improves quality. Claude performs better when the relevant signal is not buried under stale details.

The habit:

Clear aggressively.
Compact intentionally.
Do not let one session become your entire workday.

6. Slim Down Always-Loaded Context

Why this matters

Many power users create large instruction files:

  • CLAUDE.md
  • project rules
  • global preferences
  • coding standards
  • workflow notes
  • review rubrics
  • style guides
  • tool instructions

These can be useful. They can also become an invisible tax.

Anthropic’s docs state that CLAUDE.md is loaded into context at session start. Their cost-management guidance recommends moving specialized instructions from CLAUDE.md into skills because skills load on demand, while CLAUDE.md instructions are present even when you are doing unrelated work. The docs suggest aiming to keep CLAUDE.md under 200 lines.

The mechanism is simple:

Always-loaded context costs tokens even when it is irrelevant.

What belongs in CLAUDE.md

Use CLAUDE.md for stable, universal rules:

  • project setup commands
  • test commands
  • architecture overview
  • important safety constraints
  • naming conventions
  • files or directories to avoid
  • short workflow preferences

Do not use it as a dumping ground for every possible process.

If a rule only matters sometimes, it probably does not belong in always-loaded memory.

What belongs in skills

Skills are better for specialized, on-demand procedures:

  • PR review workflow
  • database migration workflow
  • release checklist
  • content style guide
  • long testing protocol
  • client onboarding procedure
  • schema generation process
  • incident response playbook

The idea is:

Base memory should orient Claude.
Skills should equip Claude for specific jobs.

How to audit your memory file

Open your CLAUDE.md and mark each section:

Always needed
Often needed
Rarely needed
Outdated
Duplicated elsewhere
Too detailed

Then apply this rule:

Always needed -> keep
Often needed -> compress
Rarely needed -> move to skill
Outdated -> delete
Duplicated -> consolidate
Too detailed -> summarize and link

Example

Before:

## Database Migrations
 
[250 lines of detailed migration procedure]

After:

## Database Migrations
 
For migrations, use the `database-migration` skill before editing schema files.
Never run destructive migrations without explicit approval.

The detailed procedure moves into a skill that loads only when the migration workflow is invoked.

Benefit

Slimming always-loaded context improves every session:

  • lower token usage at session start
  • lower per-turn context cost
  • less instruction conflict
  • less irrelevant guidance
  • cleaner model behavior

This is especially important for Pro users who work across many different task types. A giant memory file may feel like personalization, but if it loads every time, it is also rent.

The rule:

Your memory file is a tax on every prompt.
Keep the tax low.

7. Do Not Feed Fable Terminal Noise

Why this matters

Terminal output is one of the easiest ways to waste Claude usage.

Developers know how to skim terminal output. Claude does not skim for free. If you show Claude 10,000 lines of logs, dependency warnings, stack traces, test output, or build artifacts, that content enters the token economy.

Anthropic’s cost docs explicitly recommend offloading processing to hooks and skills. Their example is a hook that filters test output so Claude sees only failures instead of full logs.

The principle:

The model pays attention to every line you feed it.
So do not feed it lines you would ignore yourself.

What terminal noise looks like

Common sources:

  • full npm install output
  • long test logs
  • repeated warnings
  • successful test details
  • dependency trees
  • stack traces with repeated frames
  • git diff for generated files
  • full build logs
  • linter output across unrelated files
  • grep output with too many matches

The problem is not that terminal output is bad. The problem is unfiltered terminal output.

How to reduce it manually

Use shell filters:

npm test 2>&1 | grep -A 5 -E "(FAIL|ERROR|error:)" | head -100

Show only changed files:

git status --short

Summarize large diffs:

git diff --stat

Limit search output:

rg "pattern" --line-number --max-count 20

Show the first or last relevant part:

some-command | tail -100
some-command | head -100

Filter logs around errors:

grep -A 20 -B 5 "ERROR" app.log | head -200

How to reduce it with hooks

Claude Code hooks can preprocess command output before Claude sees it. A hook can detect test commands and return only the relevant failure snippets.

The value is not the exact hook implementation. The value is the pattern:

Raw tool output -> filter -> compact evidence -> Claude

For example:

Instead of:
  10,000-line test log
 
Return:
  failing test name
  assertion error
  relevant stack frame
  command run
  exit code

Open-source tool: RTK

RTK is a CLI proxy designed to reduce token consumption on common development commands. Its README describes it as reducing LLM token consumption by 60-90% on common dev commands. Treat that as a project claim, not a universal guarantee, but the underlying mechanism is sound: command output is often much larger than the useful information inside it.

RTK is most useful for:

  • git output
  • command summaries
  • test and build output
  • structured terminal compression

It will not automatically solve every source of token waste. It does not replace context management, model routing, or good prompts. But it belongs in the toolbox because terminal noise is a real leak.

Benefit

Filtering terminal output gives you three wins:

  1. Lower usage burn: fewer irrelevant tokens enter context.
  2. Better reasoning: Claude sees the important evidence faster.
  3. Less rework: errors are easier to diagnose when logs are clean.

The rule:

Do not paste the transcript of the machine.
Paste the evidence the model needs.

8. Retrieve the Answer, Not the Haystack

Why this matters

Another common token leak is dumping too much documentation or code into context.

Examples:

  • pasting an entire library docs page
  • asking Claude to read a whole directory
  • loading multiple files when one symbol definition would do
  • giving Claude a whole repo snapshot
  • asking broad search questions that return dozens of files

This feels safe because you are “giving Claude context.”

But context is not free. Excess context can reduce quality by burying the useful evidence under irrelevant material.

The better pattern is retrieval.

Find the relevant evidence first.
Then give Claude only the relevant evidence.

What retrieval changes

Traditional context loading says:

Here is everything. Figure out what matters.

Retrieval says:

Find what matters. Then reason over that.

That is a major difference in token economics.

If Claude needs to answer a question about one function, it should not read twenty files. If it needs current API docs for one method, it should not ingest a full documentation site.

How to do it manually

Ask targeted questions:

Find the file that defines the login validation function.
Do not read unrelated files yet.
Return only the path, symbol name, and reason it is relevant.

Then:

Read only that function and its direct callers.

For docs:

Find the current docs for configuring middleware in Next.js.
Return only the relevant section for matcher configuration.
Do not summarize the entire routing system.

For codebases:

Search for where invoices are created.
Return the top 5 candidate files with one-line reasons.
Wait before reading files.

This turns discovery into a staged process instead of a context dump.

Tool: Context7

Context7 provides up-to-date code documentation for LLMs and AI coding tools. Its tools can resolve a library ID and retrieve relevant documentation for a specific query. This is useful because library docs change, and generic model memory may be stale.

Use it when:

  • you need current framework docs
  • you are configuring an API
  • you are using a library with version-specific behavior
  • you want relevant docs instead of a broad search dump

The key is to query narrowly:

Use Context7 to retrieve only the docs for Next.js middleware matcher config.

Not:

Use Context7 to learn Next.js.

Tool: Claude Context

Claude Context is an MCP plugin that adds semantic code search to Claude Code and other coding agents. Its README positions it as a way to search relevant code from large codebases instead of loading entire directories into context.

This can help when:

  • your repo is large
  • keyword search misses conceptual matches
  • Claude keeps reading too many files
  • you need semantic code search across millions of lines
  • you want the model to retrieve code evidence on demand

There is a tradeoff: semantic retrieval infrastructure adds setup complexity and may require an embedding provider and vector database. For small repos, rg and careful file reads may be enough. For large repos, retrieval can earn its place.

Benefit

Retrieval saves usage because it narrows the context before the expensive reasoning step.

The rule:

Do not give Claude the haystack.
Give Claude the needle, the nearby straw, and enough context to verify it.

9. Use Subagents for Verbose Work

Why this matters

Some tasks are useful but noisy:

  • running tests
  • fetching docs
  • searching a codebase
  • comparing options
  • reading logs
  • producing summaries
  • checking edge cases
  • reviewing generated output

If all of that happens inside your main Fable session, your main context gets polluted with verbose exploration.

Anthropic’s cost docs recommend delegating verbose operations to subagents so the noisy output stays in the subagent’s context and only a summary returns to the main conversation.

This is one of the most practical ways to stretch usage in agentic workflows.

What subagents do for tokenomics

A subagent creates a context boundary.

Instead of:

Main Fable session reads everything.
Main Fable session runs everything.
Main Fable session keeps all logs forever.

You get:

Subagent explores.
Subagent absorbs noisy output.
Subagent returns compact summary.
Main session keeps only the useful result.

This matters because your main session is where the expensive judgment often happens. Keep it clean.

What to delegate

Good subagent tasks:

Search the repo for every place this function is called.
Return only the top relevant files and why they matter.
Run the test suite and summarize only failing tests, error messages, and likely causes.
Review the current docs for this API and produce a one-page implementation brief.
Compare these two approaches and return tradeoffs, not a recommendation.
Inspect the codebase for existing patterns before we implement this feature.
Return path references and a short recommendation.

Poor subagent tasks:

Figure this whole project out.
Improve the codebase.
Research everything about this.

Subagents save usage only when their task is bounded and their return format is compact.

How to write a good subagent prompt

Use this structure:

Task:
[Specific task]
 
Scope:
[Where to look / what to ignore]
 
Output:
Return a compact summary with:
1. Findings
2. Evidence paths or sources
3. Risks
4. Recommended next step
 
Do not include raw logs unless essential.
Do not implement changes.
Do not broaden the scope.

For coding exploration:

Find the existing pattern for form validation in this repo.
Look only at app forms and shared validation helpers.
Return:
- 3-5 relevant files
- the pattern used
- any edge cases
- recommendation for where a new validator should live
 
Do not read unrelated modules.
Do not write code.

Benefit

Subagents help you preserve your main session for decisions.

They also make the work more reviewable. A good subagent returns a digestible evidence packet instead of a mountain of output.

The rule:

Verbose exploration belongs outside the expensive main context.

10. Advisor Mode: Cheap Execution, Expensive Judgment

Why this matters

Advisor mode is the more advanced version of “Fable as architect.”

Instead of manually switching models, you configure a cheaper model as the executor and a stronger model as the advisor. The executor performs the routine work. When it gets stuck or needs guidance, it consults the advisor.

That is a strong pattern for usage limits because most long coding sessions are not uniformly hard. They contain a mix:

routine execution
routine search
minor fixes
test runs
some hard decisions
occasional uncertainty spikes

If Fable handles the entire session, you pay Fable rates for all of it.

If Fable advises only at the hard points, you preserve Fable for judgment.

What advisor mode changes

Without advisor mode:

Fable drives the whole session.
Fable reads files.
Fable writes code.
Fable runs tools.
Fable processes logs.
Fable makes decisions.

With advisor mode:

Opus or Sonnet drives the session.
Opus or Sonnet reads files.
Opus or Sonnet writes code.
Opus or Sonnet runs tools.
Fable advises when judgment is needed.

The advisor model becomes a decision layer.

How to use it

The key detail from the transcript is that the currently selected model is the executor. So if you want Opus to execute and Fable to advise, set the main model to Opus, then set Fable as advisor.

Example:

/model opus
/advisor fable

Use the exact model names available in your Claude Code environment.

When advisor mode is useful

Use it for:

  • long coding sessions
  • refactors
  • debugging loops
  • architectural implementation
  • tasks where the executor may get stuck
  • workflows with many routine steps and a few hard decisions

Do not use it automatically for every small task. Advisor mode adds coordination overhead. It earns its place when the session is long enough or complex enough that the cheaper executor can carry most of the load.

How to prompt the executor

You are the executor.
 
Use the advisor only when:
- the decision has architecture consequences
- there are multiple plausible approaches
- you are stuck after one focused attempt
- proceeding may create expensive rework
- the user-facing behavior is ambiguous
 
Do not ask the advisor for routine file reads, simple edits, formatting, or obvious test fixes.
When you do consult the advisor, send a compact brief:
1. Goal
2. Current state
3. What you tried
4. Decision needed
5. Options considered

This prevents advisor mode from becoming another token leak.

Benefit

Advisor mode gives you a structured way to pay for expensive judgment only when the work reaches a decision point.

The rule:

Let the cheaper model drive.
Let Fable grab the wheel when judgment matters.

11. Output Discipline: Make Claude Write Less

Why this matters

Token burn is not only input. Output matters too.

Claude can be verbose. It may explain decisions you did not need explained, rewrite code more broadly than necessary, generate large helper abstractions, or produce long summaries after simple actions.

On expensive models, output discipline matters.

Every unnecessary paragraph, every avoidable code block, every broad rewrite, and every “while I was here” improvement consumes usage.

What output discipline means

Output discipline means telling Claude what kind of answer you want and what kind of answer you do not want.

It does not mean “be terse at all costs.” Sometimes you want detailed reasoning. But you should choose detail intentionally.

The default should be:

Use the smallest sufficient output for the task.

Prompt constraints that work

Use this add-on for coding:

Make the smallest sufficient change.
Avoid broad rewrites.
Do not refactor adjacent code.
Do not generate new abstractions unless necessary.
Prefer minimal diffs.
Explain only decisions that affect implementation.
Keep the final summary concise.

Use this for planning:

Give me the decision-relevant reasoning only.
Avoid generic background.
Use bullets.
Call out tradeoffs and risks.
Do not write implementation code yet.

Use this for debugging:

Do not list every possible cause.
Rank the top 3 likely causes.
For each, include the evidence that would confirm or falsify it.
Start with the cheapest test.

Use this for writing:

Draft the section directly.
No preamble.
No recap of the instructions.
Keep examples tight and functional.

Tools: Ponytail and Caveman

The transcript mentions Ponytail as a style or skill that attempts to reduce token count by making Claude write less while preserving usefulness. Caveman is another terse-output style tool that aims at similar territory.

These tools should be treated as experiments, not magic. Their value is the principle they embody:

Constrain verbosity before it becomes usage burn.

If a tool gives you a 10-20% improvement in output token discipline without harming quality, it may be worth using. But the tool should not replace judgment. Some tasks need explanation. Some tasks need careful reasoning. Some terse outputs hide assumptions you actually needed to inspect.

The risk of over-compression

There is a failure mode here:

You make Claude so terse that it stops showing its reasoning.
Then you miss a bad assumption.
Then you spend more tokens fixing the mistake.

Output discipline is not about starving the model. It is about removing low-value output.

Use concise reasoning, not zero reasoning.

Benefit

Output discipline reduces burn and improves reviewability.

It also forces better prompting. When you ask for the kind of output you actually need, Claude spends less time guessing the format.

The rule:

Ask for enough output to act.
Do not pay for output you will not use.

12. Measure Before You Optimize

Why this matters

Tokenomics without measurement is vibes.

If you do not know where your usage is going, you will optimize the wrong thing. You may blame the model when the real issue is stale context. You may blame context when the real issue is verbose terminal output. You may blame terminal output when the real issue is using max effort by default.

Measurement turns usage limits from a mystery into an operating system.

What to measure

At minimum, track:

  • model used
  • effort level
  • session length
  • context size
  • tool usage
  • MCP usage
  • subagent usage
  • cache reads
  • output verbosity
  • whether the task required retries
  • whether the session was cleared or compacted

You do not need to become obsessive. You need enough visibility to find the biggest leaks.

Built-in tools

Claude Code provides /usage.

Anthropic’s docs explain that /usage shows token usage statistics for the current session. On subscription plans, it also shows plan usage bars, activity stats, and breakdowns across things like skills, subagents, plugins, and MCP servers. The exact billing relevance differs between API users and Pro/Max subscribers, but the usage breakdown is still useful operationally.

Use:

/usage

Also consider configuring a status line so usage is visible continuously.

Open-source tool: ccusage

ccusage reads local usage data from coding agent CLIs and turns it into daily, weekly, monthly, and session reports. It supports Claude Code and other agent CLIs. Its features include model breakdowns, cache token tracking, cost views, session reports, five-hour block tracking, and status-line integration.

Basic command:

npx ccusage@latest

Claude-specific examples:

npx ccusage@latest claude daily
npx ccusage@latest claude daily --breakdown
npx ccusage@latest blocks
npx ccusage@latest session

Use it to answer:

  • Which model is consuming the most?
  • Which days or sessions burned unusually high?
  • Are cache reads helping?
  • Which projects or instances are expensive?
  • Are your five-hour windows being consumed faster than expected?

Open-source tool: Claude Code Usage Monitor

Claude Code Usage Monitor provides real-time monitoring, predictions, warnings, and status-line features. Its README emphasizes official-limit capture where available and labels estimates by confidence.

This is useful when the pain is not monthly cost, but “how close am I to getting cut off today?”

Use this category of tool if you want:

  • live burn-rate awareness
  • warning thresholds
  • session-window predictions
  • plan-specific usage visibility

How to diagnose a bad session

After a session burns too much usage, ask:

1. Did I use a stronger model than necessary?
2. Was effort level too high?
3. Did the session contain stale context?
4. Did Claude read too many files?
5. Did terminal output flood the context?
6. Did an MCP server add overhead?
7. Did I ask vague prompts that triggered broad exploration?
8. Did the model produce overly verbose output?
9. Did I retry because the first plan was wrong?
10. Could a subagent have isolated the noisy part?

This is how you improve the workflow instead of just feeling punished by the limit.

Benefit

Measurement helps you optimize the real bottleneck.

The rule:

Do not guess where the tokens went.
Look.

13. The Claude Usage Stretch Playbook

This section turns the guide into an operating procedure.

Default workflow

Use this as your standard Claude Code workflow:

1. Start with the cheapest plausible model.
2. Use low or medium effort unless the task is clearly hard.
3. Ask for a plan before execution on complex work.
4. Use Fable for architecture, ambiguity, or hard judgment.
5. Use cheaper models for routine execution.
6. Clear or compact context aggressively.
7. Keep always-loaded memory slim.
8. Filter terminal output before Claude sees it.
9. Retrieve targeted docs/code instead of dumping context.
10. Use subagents for verbose exploration.
11. Use advisor mode for long sessions with occasional hard decisions.
12. Measure usage after heavy sessions.

The 30-second preflight

Before starting a task, ask:

What is the task type?
What is the cheapest model that can do it?
What effort level is justified?
What context does Claude actually need?
What should be excluded?
What output format do I want?
What would make me escalate to Fable?

This prevents vague work from becoming expensive work.

The model-routing prompt

Before starting, classify this task:
 
Task type:
- routine execution
- context gathering
- research
- debugging
- architecture
- hard reasoning
- review
 
Recommended model:
[Haiku / Sonnet / Opus / Fable]
 
Recommended effort:
[low / medium / high / max]
 
Reason:
[Why this level is sufficient]
 
Escalation trigger:
[What would justify switching to a stronger model or higher effort]
 
Then wait for approval before execution.

The Fable escalation prompt

Use this when a cheaper model is stuck:

We are escalating to Fable for judgment only.
 
Goal:
[Goal]
 
Current state:
[Short summary]
 
What has been tried:
[Attempts]
 
Evidence:
[Relevant files/logs only]
 
Decision needed:
[Specific decision]
 
Constraints:
[Constraints]
 
Please:
1. Diagnose the bottleneck.
2. Recommend the next move.
3. Explain the tradeoff briefly.
4. Do not perform routine execution.

The context reset ritual

At the end of any meaningful task:

1. Ask Claude for a compact handoff summary.
2. Save the summary if needed.
3. Rename the session.
4. Clear before starting unrelated work.

Handoff prompt:

Create a compact handoff summary:
 
1. Goal
2. Final state
3. Files changed or artifacts created
4. Commands run
5. Decisions made
6. Open risks
7. Suggested next step
 
Keep it concise. Do not include raw logs.

The noisy-output protocol

Before running any command likely to produce lots of output:

Can I filter this?
Can I show only failures?
Can I use --stat instead of full diff?
Can I inspect one file instead of many?
Can a subagent absorb this output?

Benefit

The playbook converts tokenomics into habit.

You should not have to think from first principles every time. You want defaults that protect usage automatically.

The principle:

Good defaults save more usage than heroic optimization.

14. Quick Setup Stacks

Different users need different levels of complexity. Do not install a complex stack before you need it.

Beginner stack

Use this if you mostly work manually in Claude Code and want immediate relief.

/usage
/effort low or medium
/clear between unrelated tasks
/compact before long sessions overflow
short CLAUDE.md
specific prompts
minimal output instructions

Primary habits:

  • Stop defaulting to high effort.
  • Clear stale context.
  • Ask specific prompts.
  • Keep output concise.

Best for:

  • solo users
  • Pro users
  • smaller projects
  • non-engineers using Claude heavily
  • people who want results without tooling complexity

Intermediate stack

Use this if you spend serious time in Claude Code and want operational visibility.

ccusage
Claude Code Usage Monitor
RTK or command-output filters
custom compact instructions
skills instead of long CLAUDE.md
Sonnet/Opus execution with Fable planning

Primary habits:

  • Measure usage by model/session.
  • Compress terminal output.
  • Move long procedures into skills.
  • Use Fable as planner/reviewer.

Best for:

  • developers
  • AI builders
  • technical creators
  • people hitting limits regularly
  • people working across multiple projects

Advanced stack

Use this when your workflows are long, agentic, or codebase-heavy.

advisor mode
subagents
Context7
Claude Context
Context Mode or similar context-control MCPs
custom hooks
code intelligence plugins
task-specific skills

Primary habits:

  • Separate research, planning, execution, and review.
  • Use retrieval infrastructure for large codebases.
  • Keep main context clean.
  • Use Fable only at decision points.

Best for:

  • large repos
  • agentic coding workflows
  • teams
  • long-running builds
  • users who need Fable but cannot afford to let Fable do everything

The complexity rule

Do not install everything at once.

Start with:

/effort
/clear
/usage
specific prompts

Then add tooling only when you can name the leak:

Too much terminal output -> RTK or hooks
Too much docs/context dumping -> Context7
Too much codebase search -> Claude Context
Too little visibility -> ccusage or usage monitor
Too much noisy exploration -> subagents
Too much Fable execution -> architect/executor or advisor mode

The rule:

Add a tool to fix a measured leak, not because the tool sounds clever.

15. Claims, Caveats, and How to Think About the Numbers

The savings claim

The savings claim should be presented as benchmark-contextual, not universal.

Precise version:

In the benchmark shown in the source video, Fable at low effort roughly matched or slightly beat Opus at max effort while costing about 71% less.
 
In the same benchmark context, Fable at low effort cost about 83% less than Fable at max effort.

Do not phrase it as:

Fable is 80% cheaper than Opus.

That is not generally true.

The better phrasing:

Fable low can beat Opus max at much lower cost, and low effort can make Fable itself more than 80% cheaper than max effort.

Even better in body copy:

The point is not that Fable is cheap. It is that effort level can change the cost/performance curve dramatically.

Tool claims

Open-source tools often make strong token-saving claims. Treat them as useful signals, not universal guarantees.

For example:

  • RTK claims 60-90% reduction on common dev commands.
  • Context/retrieval tools claim reduced context waste by returning relevant evidence.
  • Terse-output skills may reduce output tokens by making responses shorter.

These claims depend on:

  • task type
  • model behavior
  • command output size
  • repo size
  • configuration
  • user prompt quality
  • whether compressed output preserves enough evidence

The correct stance:

Experiment, measure, keep what improves your workflow.

The risk of optimizing too hard

Token-saving can go too far.

Failure modes:

  • using too weak a model and causing retries
  • lowering effort when the task needs deep reasoning
  • over-compressing logs and hiding the real error
  • making Claude too terse to expose assumptions
  • using retrieval that misses relevant files
  • adding complex tooling that burns more time than it saves

The goal is not minimum tokens.

The goal is:

minimum sufficient tokens for the outcome you need.

How to know a tactic earns its place

A tactic earns its place if it does at least one of these:

  • reduces repeated context
  • reduces irrelevant input
  • reduces unnecessary output
  • prevents expensive rework
  • moves low-value work to cheaper models
  • keeps expensive models focused on judgment
  • improves visibility into usage
  • preserves or improves quality

If a tactic adds complexity without doing one of those, skip it.

16. Sources

This guide uses four kinds of sources:

  1. The source video transcript that supplied the original structure and benchmark interpretation.
  2. The DeepSWE benchmark leaderboard that supports the Fable low vs Opus max cost/performance comparison.
  3. Official Anthropic / Claude documentation for Claude Code mechanics and cost-management behavior.
  4. Open-source tool references for optional usage-monitoring, retrieval, and token-compression workflows.

Treat the benchmark and open-source project claims as directional evidence, not universal guarantees. The guide uses them to explain mechanisms and practical workflows, not to claim that every user will see the same savings on every task.

Primary source material

  • Source YouTube video transcript provided by user
    The user-provided transcript from this video supplied the original five-tip structure: lower effort, use Fable as architect, reduce token output, delegate research, and use advisor mode.

  • DeepSWE v1.1 leaderboard
    Primary benchmark source for the graph and cost/performance comparison. The leaderboard lists 113 tasks, updated July 1, 2026, and includes model score, average task cost, output tokens, and agent steps.

  • DeepSWE v1.1 announcement / blog
    Supporting benchmark context for the v1.1 leaderboard and model comparison table. Used to verify the DeepSWE model entries and average-cost framing.

  • DeepSWE methodology article: Measuring frontier coding agents
    Background on what DeepSWE measures and how tasks are structured. Used to frame DeepSWE as a coding-agent benchmark rather than a general-purpose reasoning benchmark.

Official Claude / Anthropic documentation

Open-source tools and projects referenced

  • ccusage
    Referenced as a usage-reporting CLI for Claude Code and other coding agents, including daily, weekly, monthly, session, model-breakdown, cache-token, and five-hour-window views.

  • Claude Code Usage Monitor
    Referenced as a real-time Claude Code usage monitor with predictions, warnings, status-line support, and confidence labels for official vs local estimates.

  • RTK
    Referenced as a CLI proxy for reducing token consumption from common development command output. Its savings claims are treated as project claims that should be tested in the user’s own workflow.

  • Context7
    Referenced as a documentation-retrieval tool for bringing targeted, up-to-date library docs into AI coding workflows.

  • Claude Context
    Referenced as a semantic code-search MCP for Claude Code and other coding agents, useful for retrieving relevant code from large repos instead of loading broad file context.

Research and watchlist references

Local image artifacts used

The guide uses three local image files copied from the user’s screenshots and placed beside the Markdown artifact:

  • assets/how-fable-beats-opus-for-80-percent-less/deepswe-cost-fable-opus-graph.png
  • assets/how-fable-beats-opus-for-80-percent-less/deepswe-fable-low-60-3-76.png
  • assets/how-fable-beats-opus-for-80-percent-less/deepswe-opus-max-59-13.png

These images are visual annotations of the DeepSWE v1.1 leaderboard and support the Fable low vs Opus max section.

Closing: The New Rule of Claude Tokenomics

The strongest Claude users are not the ones who always use the strongest model.

They are the ones who know which part of the work deserves the strongest model.

Fable is expensive. For many average AI enthusiasts and Pro users, it is realistically too expensive to use casually. That does not make it unusable. It means you need a usage strategy.

Use Fable when:

  • the decision is hard
  • the plan matters
  • the architecture is ambiguous
  • cheaper models are stuck
  • failure creates expensive rework
  • the reasoning quality changes the outcome

Avoid using Fable for:

  • raw exploration
  • long logs
  • routine edits
  • broad file reads
  • boilerplate
  • docs gathering
  • tasks Sonnet can execute from a good plan

The final rule:

Spend frontier tokens only where frontier reasoning changes the outcome.

That is how you stretch Claude usage limits without giving up the reason you wanted Fable in the first place.

Graph View