How to Reduce Claude Fable 5 Token Costs: 8 Settings to Change Right Now
Fable 5 now bills at API rates. Learn which settings to disable—MCP servers, auto-memory, Claude.md bloat—to cut token costs without losing quality.
Why Your Claude Bill Just Got Real
Claude token costs sneak up on you. One week you’re happily building, the next you’re staring at an invoice that looks nothing like you expected. If you’re using Claude Code (running under what Anthropic internally tracks as the Fable 5 architecture), you already know: this version bills at API rates, not the flat subscription you might have been used to.
That changes the math entirely.
The good news is that most of the cost isn’t coming from what you’re actually asking Claude to do — it’s coming from overhead. System prompts, MCP server noise, bloated memory files, and a handful of default settings that are running silently in the background, consuming tokens every single request.
This guide covers eight specific settings to adjust right now. Some cut costs dramatically. All of them are reversible. None require you to compromise on output quality.
Understand Where Claude Token Costs Actually Come From
Before optimizing anything, you need a clear picture of what’s using tokens. Most people assume the majority of their token spend comes from the model’s responses. That’s usually wrong.
In a typical Claude Code session, the breakdown looks something like this:
- Input tokens (your messages + context): 60–75% of total usage
- System prompt + injected context: 15–30% of input tokens
- Model output: 25–40% of total usage
This matters because input tokens — especially everything you’re injecting automatically before your actual prompt — are often the easiest place to cut.
Fable 5 bills both input and output tokens at the current Claude API rates. Extended thinking, if enabled, adds another layer on top. So trimming the invisible overhead (the stuff running before you type a single word) is where the biggest gains are.
Setting 1: Audit and Disable Unused MCP Servers
MCP (Model Context Protocol) servers let Claude connect to external tools and data sources — file systems, databases, APIs, and more. They’re powerful. They’re also one of the most common sources of token waste.
Every active MCP server adds to the context window on every request. Even if you never call that server during a session, Claude still receives its full schema and tool definitions upfront. For a session with four or five active MCP servers, that preamble alone can cost thousands of tokens per conversation turn.
What to do:
- Go to your Claude Code MCP configuration file (typically
.mcp.jsonor similar) - List every server you have enabled
- Disable any server you haven’t used in the last two weeks
- For project-specific servers, scope them per project rather than globally
The rule of thumb: only run MCP servers you actually use in active projects. A developer might have a Postgres MCP server enabled globally when they only need it for one specific project. That’s unnecessary overhead on every other session.
You can re-enable servers in under a minute. The cost of leaving unused ones on is permanent.
Setting 2: Cut CLAUDE.md File Bloat
CLAUDE.md is Claude Code’s persistent memory file — a Markdown document that Claude reads at the start of every session to understand your project context, preferences, and instructions.
It’s one of the most useful features in Claude Code. It’s also one of the most abused.
Many developers accumulate CLAUDE.md files that grow to 2,000, 5,000, even 10,000 tokens over time. Every conversation starts by injecting that entire file into context. If you’re running 20 sessions a day, that’s 20 full reads of a bloated document — most of which is probably outdated or irrelevant.
What to do:
- Open your CLAUDE.md and read it critically
- Remove anything that’s no longer accurate (old architecture decisions, deprecated dependencies, stale preferences)
- Strip out lengthy explanations — use bullet points, not paragraphs
- Move project-specific content to per-directory CLAUDE.md files rather than one global file
- Target under 500 tokens for your global CLAUDE.md; project-specific files should be under 1,000
A lean CLAUDE.md that’s actually accurate is more useful than a comprehensive one that’s half outdated. Claude doesn’t benefit from reading context it can’t act on.
Setting 3: Disable Auto-Memory for Low-Stakes Sessions
Claude Code’s auto-memory feature automatically saves information from your sessions back into memory files. It’s designed to reduce repetitive context-setting across sessions.
But auto-memory is a two-way cost: it writes tokens during a session (to update memory) and reads tokens at the start of the next one (to load it). For exploratory or throwaway sessions — debugging something minor, testing a quick idea — auto-memory is spending tokens on context you’ll never use again.
What to do:
- Identify session types where persistent memory adds no real value
- Disable auto-memory for those session types via the
memoryconfiguration in your settings - Use manual memory saves only when you’ve done something genuinely worth remembering across sessions
This is a judgment call, not a binary switch. Keep auto-memory on for your main development projects. Turn it off for experimentation and investigation sessions.
Setting 4: Compress or Disable Extended Thinking
Extended thinking gives Claude more reasoning capacity for hard problems by running internal chain-of-thought processing before responding. It’s genuinely useful for complex debugging, architecture decisions, and multi-step problems.
It’s also expensive — often 2–4x the token cost of a standard response for the same task.
The problem is that many workflows have extended thinking enabled globally, which means Claude is running full internal reasoning on tasks like “add a comment to this function” or “rename this variable.” That’s like using a sledgehammer to hang a picture.
What to do:
- Set extended thinking to off as your default
- Enable it explicitly for tasks that genuinely need it (architecture review, debugging complex race conditions, refactoring large systems)
- Use the
thinkingparameter in API calls to toggle per-request rather than globally
You’ll notice almost no quality difference on routine tasks, and significant cost reductions across your total usage.
Setting 5: Scope Tool Permissions More Tightly
Claude Code can be given permission to use a wide range of tools — file reading, terminal commands, web browsing, code execution, and more. By default, many configurations grant broad tool access.
The issue: when Claude has access to many tools, it often uses more of them than necessary — reading multiple files “just to be sure,” running verification commands, pulling in additional context. Each of those tool calls costs tokens.
What to do:
- Review the tools you’ve granted Claude Code access to
- For most coding sessions, you need: file read, file write, terminal (scoped), and search
- Remove web browsing and broad file system access unless you actively need them
- Scope terminal permissions to specific commands where possible
Tighter tool permissions also improve Claude’s behavior — when fewer tools are available, it tends to focus more on solving the actual problem rather than gathering supplementary context.
Setting 6: Reduce Context Window Injection
Many Claude Code integrations automatically inject large amounts of context into every request — open files, recent git history, project structure, dependency lists. Some of this is genuinely useful. A lot of it isn’t.
What to do:
- Check what your integration is automatically injecting before each request
- Disable automatic injection of files you haven’t recently edited
- Turn off auto-import of git history unless you’re explicitly working on something history-dependent
- Only inject the current file and immediately related files — not the entire project structure
A common setup injects 3–5 open files automatically even when you’re only working on one. Cutting that back to just the relevant file can reduce input token costs by 40–60% on a per-request basis.
Setting 7: Use Smaller Models for Simpler Subtasks
Not every task in your workflow needs Claude’s most capable model. Fable 5 supports routing to different model tiers depending on the task complexity — and the cost difference is significant.
Claude Haiku, for instance, is roughly 15–25x cheaper than Claude Sonnet on a per-token basis. For tasks like:
- Generating boilerplate code
- Writing simple unit tests
- Formatting or linting suggestions
- Summarizing short documents
Other agents ship a demo. Remy ships an app.
Real backend. Real database. Real auth. Real plumbing. Remy has it all.
…Haiku handles them well. Reserving Sonnet or Opus for tasks that actually require deep reasoning isn’t a compromise — it’s just sensible resource management.
What to do:
- Identify the recurring, lower-complexity tasks in your workflow
- Route those to a smaller model via your API configuration or workflow settings
- Keep your high-stakes, reasoning-heavy tasks on the most capable model
If you’re building agentic workflows, this kind of model tiering can cut costs by 50% or more without any change in output quality for the tasks that matter most.
Setting 8: Configure Conversation Compaction Aggressively
Claude Code includes conversation compaction — a feature that summarizes older parts of a long conversation to keep the context window from ballooning. But the default settings are often too conservative, letting conversations grow quite long before compaction kicks in.
Long conversations are expensive because every new message includes the full context of everything that came before. A 10,000-token conversation means each new exchange carries 10,000+ tokens of input overhead before you’ve said anything.
What to do:
- Lower the compaction threshold so Claude summarizes earlier in long conversations
- Use explicit
/compactcommands (or the equivalent in your setup) when a conversation has clearly moved past a distinct phase of work - For multi-session projects, prefer starting fresh sessions over continuing very long ones — pull in only the relevant context manually
A fresh session with a focused CLAUDE.md entry about where you left off is almost always more cost-effective than a 15,000-token conversation that’s accumulated over hours.
How MindStudio Handles Token Cost Control
If you’re running Claude-powered agents as part of a broader automation workflow — not just interactive coding sessions — then managing token costs at the workflow level matters just as much as individual session settings.
MindStudio lets you build multi-step AI workflows visually, and because you control exactly what gets passed to the model at each step, you’re not fighting against defaults you can’t see. You decide what context each step receives, which model runs which part of the workflow, and how outputs get compressed before being passed downstream.
That kind of explicit control is hard to replicate when you’re working inside a tool where context injection happens automatically. In MindStudio, if you want Claude Sonnet to handle the analysis step and Claude Haiku to handle formatting, you set that up directly — no configuration files, no hidden behavior.
For teams that are already comfortable with Claude Code but want to automate repeatable workflows without incurring full-conversation token overhead on every run, connecting those workflows through MindStudio is worth looking at. You can try it free at mindstudio.ai.
For more on controlling costs in multi-model setups, this guide to building cost-efficient AI workflows covers how model selection affects total cost across agentic pipelines.
Putting It Together: A Token Cost Audit Checklist
Before adjusting anything, run through this checklist to understand your current baseline:
- How many MCP servers are currently active globally?
- What’s the token count of your CLAUDE.md file?
- Is extended thinking on by default or request-specific?
- What files and context are being auto-injected before each request?
- Which model tier is running your routine tasks?
- When does conversation compaction trigger in your current setup?
- Which tool permissions are enabled that you haven’t used recently?
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
Answering these before making changes gives you a real before/after comparison. Token costs aren’t abstract — once you know your baseline, cuts of 30–60% are realistic for most setups without any loss in output quality.
Frequently Asked Questions
Does reducing token usage actually affect Claude’s output quality?
For most tasks, no. The settings described here — trimming CLAUDE.md, disabling unused MCP servers, scoping tool access — reduce overhead, not capability. You’re removing tokens Claude didn’t need, not tokens it was actively using to reason. The exception is extended thinking: disabling it on genuinely complex tasks will affect reasoning quality. The key is using it selectively rather than globally.
How do MCP servers affect token costs?
Every active MCP server adds its schema and tool definitions to the context window at the start of each session. This happens automatically, regardless of whether you actually call the server. For complex server definitions, this can add 500–3,000+ tokens per session. Multiply that by multiple servers and dozens of daily sessions, and it becomes significant quickly.
What’s the ideal length for a CLAUDE.md file?
For a global CLAUDE.md, aim for under 500 tokens (roughly 350–400 words). Project-specific CLAUDE.md files can be slightly longer — up to 1,000 tokens — if the additional context genuinely improves Claude’s output for that project. If you’re writing CLAUDE.md entries in full paragraphs, switch to bullet points. You’ll cut token count by 40–50% and improve readability at the same time.
Is it worth using different Claude models for different tasks?
Yes, significantly. The price difference between Claude Haiku and Claude Sonnet is substantial — often 15–20x per token. For simple, repetitive tasks (boilerplate generation, basic formatting, short summaries), Haiku performs well. Reserving Sonnet and Opus for high-complexity reasoning tasks means you’re spending on capability only when you need it.
How often should I review my token cost settings?
A monthly review is reasonable for most developers. Your project context changes, MCP servers accumulate, and CLAUDE.md files drift over time. A 15-minute review once a month — checking active servers, pruning memory files, and reviewing what’s being auto-injected — is enough to keep costs predictable.
Does starting a new conversation reduce costs compared to continuing a long one?
Yes, often substantially. Every message in a long conversation carries the full context of everything before it as input tokens. A fresh session with a focused CLAUDE.md entry about your current task is usually more cost-effective than continuing a conversation that’s grown to tens of thousands of tokens. The tradeoff is the friction of re-establishing context, which a well-maintained CLAUDE.md minimizes.
Key Takeaways
- Most Claude token waste comes from input overhead, not model output — fix the overhead first.
- Unused MCP servers and bloated CLAUDE.md files are the two highest-impact areas to address immediately.
- Extended thinking should be opt-in per task, not a global default.
- Routing simpler tasks to smaller models (Haiku vs. Sonnet) can cut costs by 50%+ without quality loss.
- Aggressive conversation compaction and scoped tool permissions compound the savings over time.
- Regular audits matter — token overhead tends to grow quietly until it becomes a real budget problem.
Everyone else built a construction worker.
We built the contractor.
One file at a time.
UI, API, database, deploy.
The settings above aren’t about limiting what Claude can do. They’re about making sure every token you spend is actually doing useful work. Start with the two or three changes most relevant to your current setup, measure the difference, and go from there.
