Fable 5: Quality Comes at a Price

Over the past few months, a subtle yet significant shift has been taking place in the world of AI tools: raw performance is no longer enough. Now, we must also consider how much it costs.

Claude Fable 5 perfectly illustrates this tension. The model is touted as one of the most advanced for long-running tasks, complex reasoning, code, and agents. It can handle ambitious workflows, follow instructions over long sessions, and work with a great deal of context.

But this power comes at a price: Fable 5 can consume far more tokens than lighter models on the market. And in a world where AI is increasingly billed on a pay-as-you-go basis, this detail becomes a strategic issue.

The best models think longer

To understand the cost of Fable 5, we need to return to a simple idea: not all tokens come solely from what the user writes or what the model responds with.

When an advanced model tackles a complex task, it also consumes tokens to analyze, plan, use tools, read context, execute intermediate steps, and correct its own errors.

This is particularly true of agent-oriented models. A traditional chatbot answers a question. An agent, on the other hand, explores a repository, reads multiple files, attempts a correction, runs tests, interprets errors, revises its plan, and then starts over. Each step consumes tokens.

Fable 5 is specifically designed for this type of time-consuming task. It can excel at difficult problems, but it can also remain "thinking" for much longer than a simpler model. As a result, a task that seems short from the user's perspective can become costly in the background.

This is where things get interesting. A smarter model can sometimes be less expensive if it finds the right answer quickly. But it can also cost much more if it over-explores, reads too much context, or overanalyzes a simple task.

Fable 5 and the "effort" parameter

With Fable 5, Anthropic introduces an important concept: effort control. The "effort" parameter allows you to adjust the depth of the model's reasoning. The higher the effort setting, the more time the model can spend analyzing and working. This is useful for a complex migration, a technical investigation, or a lengthy agentic task; it's unnecessarily costly for a minor correction, a rephrasing, or a simple search.

In other words, Fable 5 isn't just a model. It's a multi-speed engine.

The catch, as is often the case, is that users want the best quality without paying for the complexity that makes it possible. It's a wonderfully human stance: demanding a Formula 1 car to go buy bread, then being surprised by the gas bill.

In a development team, this raises a new question: do we really need the most powerful model for every task? The answer is no. To proofread a text, categorize a request, explain a simple error message, or generate basic documentation, a lighter model is often sufficient. To analyze an architecture, fix a tricky bug, or guide an agent through a complex repository, Fable 5 is the right choice.

The best approach isn't to "use the best model for everything." It's to choose the level of intelligence appropriate for the task.

Why does it consume so much?

There are three main reasons.

The first is context. Advanced models are often used for complex tasks: lots of files, history, dependencies, and instructions. All this context must be read, converted into tokens, and processed.

The second is reasoning. The more deeply a model analyzes, the more resources it consumes. Even if it's not visible in the final response, this reasoning impacts the overall cost.

The third is agent-based operation. An agent doesn't respond all at once: it operates in a loop — read, understand, act, verify, correct. This loop is powerful, but it multiplies the number of calls, tools, reads, and intermediate outputs.

That's why Fable 5 can become expensive in code workflows. It doesn't just produce a function: it inspects a project, manipulates files, follows a lead, abandons it, starts over, and delivers a more robust solution. This behavior is useful. It's also costly.

Avoiding unnecessary token consumption

With powerful models, the risk isn't just about the price per token. It lies in "token burn": the unnecessary consumption of tokens.

An agent can consume a lot of tokens due to a lack of direction. It reads too many files, requests too much context, makes the wrong assumptions, writes code before fully understanding the problem, makes corrections without a plan, and then starts over repeatedly.

This isn't necessarily the model's fault. Often, it's the workflow's fault. A vague request like "improve this feature" forces the agent to guess. A clear request like "fix this bug in this module, without changing the public API, by adding a non-regression test" greatly reduces the search space. The less the agent has to guess, the less it wastes.

Brainstorming

At first glance, adding a brainstorming step seems counterintuitive. Why make the agent think more if the goal is to reduce tokens? Because good brainstorming isn't aimless wandering. It's a short scoping phase.

In a coding workflow, it's used to quickly explore several approaches before writing code. The agent can identify possible options, risks, files likely to be affected, assumptions to verify, and success criteria.

This step helps avoid a common pitfall: rushing into a solution, modifying code too early, then discovering that the approach was wrong, and having to start all over again. Just like in human development — except that humans call it "experience" after breaking three environments.

A plugin like Superpowers, which integrates a brainstorming phase into a more structured workflow, is specifically designed to avoid these unnecessary loops. It encourages the developer to clarify, design, plan, code, and then verify. The idea isn't to make the AI talk more, but to make it act in the right order.

The importance of a structured workflow

An agent consumes a lot of resources when it backtracks. The cost rarely comes from a single response — it comes from unnecessary iterations. A structured workflow reduces this in several ways:

• It forces clarification. The agent verifies the requirement before generating code, which prevents off-topic corrections.
• It limits exploration. By identifying relevant files before reading the entire repository, it reduces the number of input tokens.
• It generates a plan. A precise plan allows for more direct execution, with fewer failed attempts.
• It checks the result. Tests and acceptance criteria indicate whether the task is complete, rather than endlessly modifying the code.

Brainstorming, then, is no magic trick. It doesn't compress tokens — it mainly reduces clutter. And in code agents, clutter is costly.

What's the takeaway?

Fable 5 raises a question that goes beyond its price alone: how can we use powerful models without letting them consume everything?

• Don't use the most advanced model for simple tasks. Lighter models are often sufficient for summaries, rephrasing, classifications, minor corrections, or simple scripts.
• Define the scope of tasks. The more precise a request is, the less the agent needs to explore.
• Limit the context. Feeding the entire repository to a model "just in case" is rarely a good strategy. Provide the right files, the right logs, and the right constraints.
• Measure. Track the cost per successful task, not just per request. An expensive response can be cost-effective if it saves two days of work; a cheap response can be useless if it produces an incorrect fix.
• Use workflows. Brainstorming, planning, test-driven development, human validation, and automated verification aren't just details. They're economic safeguards.

And in the near future?

Models like Fable 5 show that AI is entering a more mature phase. The question is no longer just "which model is the most powerful?" but "which model, with how much effort, for which task, and at what cost?"

The companies that will make the most of AI won't necessarily be those with access to the most expensive model, but those that know how to orchestrate multiple levels of intelligence: a lightweight model for simple tasks, a mid-range model for routine work, and a very powerful model for truly complex problems.

Fable 5 is therefore not just a technical advancement. It's also an economic reminder: when AI becomes capable of working for long periods, it also becomes capable of spending for long periods.

True expertise won't just be about asking AI to do more. It will be about teaching it not to do just anything before it gets started.