Claude Fable 5 Explained: What Is Real and What Is Hype

The codebase had been inherited three times and touched by people who had all since left. No documentation. No tests. A 12,000-line CRM that everyone knew had to change and nobody wanted to touch.

I am Madhuranjan Kumar, and I want to walk through what happened when a software consultancy used this migration project as a live test of Claude Fable against Opus 4.8. They went in expecting to compare output quality between two models. They came out with a functioning migration, a detailed understanding of Fable's cost model, an unexpected lesson about how the classifier routes requests under real working conditions, and a tiered system they now apply across every project that comes through their door. This is the account of that test, from the first session to the final workflow decision.

The project nobody wanted: a 12,000-line CRM with no documentation and three departing developers

The project came in as an emergency. A client company had built a bespoke CRM over five years, adding features incrementally as needs arose, without documentation, without tests, and without any consistent architectural approach. Three of the four developers who had built and maintained it were leaving the company within the same two-week window. The fourth developer had been hired six months earlier and knew only the portions of the codebase that intersected with her daily tasks.

The CRM handled client relationships, proposal tracking, contract lifecycle management, invoicing triggers, and a custom reporting layer that the client's management team used every day to make resource allocation decisions. Migrating it meant untangling business logic that had been embedded across 12,000 lines of mixed concerns over five years, identifying what was genuinely critical versus what was dead code from deprecated features, rebuilding the core functionality in a maintainable architecture, and producing output that the client's remaining team could understand, extend, and debug without the people who had written the original.

Two senior developers who reviewed the codebase before the consultancy committed to the project estimated the work at six weeks of dedicated senior developer time. Fully loaded, including overhead and project management, the estimate ranged from twenty-eight thousand to forty thousand dollars depending on what edge cases emerged during the rebuild. The consultancy was looking for a way to compress that timeline significantly without introducing new problems into an already fragile system.

What happened when they handed Fable the entire codebase and walked away

The first test session loaded the entire 12,000-line codebase into Fable's context window along with a plain-language description of the migration objective: identify the core business logic, separate it from the data access and UI layers, propose a clean architecture for the rebuilt version, and produce a first working draft of the three most critical modules. No scaffolding. No incremental breakdown. They handed Fable the full codebase and the full objective and left it to run.

The session ran for approximately forty minutes. At the end of it, Fable had produced a complete architectural analysis identifying eight distinct logical concerns that had been mixed together across the original codebase, a proposed separation of those concerns into five clean modules with defined interfaces between them, and fully written first drafts of the client relationship module and the proposal tracking module with accompanying test stubs.

The architectural analysis was the most striking output. Fable had traced the business logic through the mixed-concern code in a way that made the implicit structure of the original system explicit. It identified three places where the codebase was handling the same conceptual operation in three different ways across different files, flagged those as consolidation targets, and proposed a single canonical implementation in the new architecture that would serve all three cases. That kind of analysis, done by a human senior developer reading 12,000 lines cold, takes a full working day under optimal conditions. It arrived in forty minutes, and the analysis was substantially correct when the consultancy's most senior developer reviewed it against their own reading of the codebase over the following two days.

The token bill after the first session and what it meant for the pricing model

The cost of that first session was approximately three hundred and twenty dollars. The consultancy had not pre-calculated this number and it landed with some weight when the invoice arrived. Three hundred dollars for a single forty-minute session was not the mental model anyone had been operating with when they decided to use the tool.

The calculation that followed was the important part. The session had produced work that would have taken a senior developer one to two full days to produce manually, at a fully loaded cost of somewhere between eight hundred and sixteen hundred dollars. At three hundred and twenty dollars, even with the surprise factor, the economics of the session were strongly positive. The output per dollar was better than the human alternative by a substantial margin.

But the lesson the consultancy drew from this was not simply that Fable is cheap relative to senior developer time. The lesson was that you need to know before the session starts how much it is likely to cost, so that you can confirm the task justifies Fable rather than a lighter model. The cost surprise happened because they had not built the cost estimation step into their workflow before the first session. After that session they did. Every Fable session they run now starts with an approximate token count of the context they plan to load and a check that the expected output value justifies the expected session cost.

This is the central challenge in deploying Fable effectively: it is priced for heavy work and it earns its price on heavy work, but deploying it on lighter work costs more than necessary. The cost management discipline is not complicated. It just requires making the decision explicitly before each session rather than after the invoice arrives.

The classifier fires mid-feature and routes the request to Opus without warning

Three sessions into the migration work, a specific sub-task triggered an unexpected behavior that caused significant confusion. The consultancy's developer was deep into the contract lifecycle module, which required handling a series of interdependent state transitions. She had loaded a large context slice and was partway through a complex implementation when she asked Fable to produce a specific configuration file needed for the module.

Fable's classifier, which routes certain request types to different processing paths based on the assessed complexity and nature of the task, identified the configuration file generation as a task that did not require the full Fable processing path and silently routed it to an Opus path. The response came back quickly and was technically correct, but the framing, the level of commentary, and the structural choices in the output were noticeably different from what had been coming back in the preceding exchanges. The developer noticed the shift, flagged it to the rest of the team, and the consultancy spent roughly thirty minutes working out what had happened and whether the output could be trusted.

The classifier behavior is designed behavior, not a failure. It is a cost and efficiency optimization: Fable routes tasks to the lightest model capable of handling them at the required quality level. The configuration file was a well-defined, bounded task that Opus could handle correctly, and routing it to Opus reduced the cost of that sub-task significantly. The confusion arose because the routing happened mid-conversation without explicit notification, which meant the developer had no way to know which model was handling which part of the work without careful attention to the character of each response.

After this experience the consultancy stopped relying on in-session routing decisions. They made model selection a pre-session decision: before loading any context, they determine explicitly whether the task warrants Fable or can be fully handled by Opus, and they open the appropriate session accordingly. If a task they thought required Fable turns out partway through to be decomposable into Fable and Opus sub-tasks, they complete the Fable portions, close the session, and open a separate Opus session for the remainder. This approach gives them cost visibility and removes the disorientation of mid-session routing changes that they did not initiate.

The tiered system they settled on: Fable for the heavy builds, Opus for everything daily

By the end of the migration project the consultancy had documented a clear tiered model for how the two tools should divide the work. They use it now as a standard pre-task checklist.

Fable is used when two conditions are simultaneously true. First: the task requires reading and understanding a substantial body of existing code or context before the output can be produced. Second: the output needs to operate at the level of a senior architect rather than a skilled implementer. Architectural analysis of a new legacy codebase. Design of a module that must integrate with many existing systems simultaneously. A complex refactor that touches many interdependent parts. A specification that needs to anticipate system-level failure modes that only become visible when you understand the full behavior of the existing code. These tasks justify the Fable context load.

Opus handles everything that does not meet both criteria simultaneously: feature additions to a well-understood module, bug investigations in a specific file or function, test writing against existing code, documentation generation, code review of a pull request, explanation of a specific design choice, generation of utility functions where the context is narrow and the task is well-specified. For these tasks, Opus produces output that is indistinguishable from Fable in practical quality while costing substantially less per session.

The practical threshold the consultancy uses: if the task requires loading more than approximately three thousand lines of existing code before the work can begin, evaluate it for Fable. If the task can be fully and precisely specified in a few hundred tokens without loading a large existing codebase, Opus is the appropriate tool. That threshold is not exact and needs calibration for the specific complexity of the codebase being worked on, but it gives developers a concrete decision point rather than a subjective judgment call at the start of each session.

What the consultancy would do differently at the start of a project like this

Three practices became standard after the migration project ended.

The first is pre-session cost estimation. Before any session that will load a substantial codebase context, they estimate the token count of the planned context load, multiply by Fable's per-token rate, and compare the estimated session cost to the expected value of the output before opening the session. If the estimate suggests the session cost exceeds thirty percent of what a human developer would charge for the equivalent work, they review whether the full context load is actually necessary or whether a more targeted slice would produce equivalent output at lower cost.

The second is context decomposition before Fable sessions. Rather than loading an entire codebase and asking Fable to find what it needs within it, they now spend twenty to thirty minutes with a junior developer identifying exactly which files and modules are relevant to the specific task, loading only those into the context, and providing a concise summary of the broader system for orientation. This approach reduces the token cost of Fable sessions by forty to sixty percent compared to full-codebase loads while preserving most of the output quality, because the task-relevant context is still complete even if the full codebase is not present.

The third is explicit model selection before opening any session. Making a conscious decision about which model to use before loading any context, rather than relying on the classifier to make routing decisions mid-session, gives them cost predictability and removes the disorientation that came from discovering mid-session that the model had changed.

The migration project was completed in eleven working days of actual work against the six-week human-developer estimate. The total token cost across all Fable sessions was approximately two thousand four hundred dollars. Against the conservative twenty-eight thousand dollar human-developer estimate, the economics were clear. The tool worked. The question was never whether it could do the work. The question the consultancy ended up answering was how to deploy it precisely enough that every session earns its cost, and the tiered system they now use is their answer to that question.