Why the Most Powerful Claude Model Should Not Automatically Become Your Default
A few months ago, model selection for AI-assisted development felt relatively straightforward. For everyday coding, documentation, and analysis, I would start with Sonnet. It was fast, capable, and inexpensive enough that I did not need to think too much about every request. When a task became genuinely difficult — a large refactor, a subtle architecture decision, a multi-service investigation, or a code review where missing one edge case could become expensive later — I would reach for Opus. That was a reasonable mental model: Routine work → Sonnet Difficult work → Opus Then Anthropic released Claude Fable 5. At first glance, it is tempting to treat Fable as the new top option and move everything one level down: Routine work → Sonnet Difficult work → Opus Very difficult work → Fable That is not completely wrong. But it also misses the more interesting point. Fable is not simply a slightly smarter Opus. It represents a different assumption about how we will use models: less as assistants waiting for the next prompt, and more as agents expected to sustain complex work for extended periods, make decisions along the way, verify their own output, and carry a task closer to completion with fewer interventions. That changes the model-selection question. The question is no longer only: Which model gives me the best answer? It is increasingly: Which model should own this part of the workflow, for how long, with what budget, and under which operational constraints? That distinction matters more than the benchmark charts. What Claude Fable 5 Actually Is Claude Fable 5 is Anthropic’s most capable widely released model. It is designed for demanding reasoning and long-horizon agentic work: the kind of task where the model is not answering a single question, but investigating a problem, navigating a codebase, using tools, making intermediate decisions, validating results, and recovering when an initial approach does not work. This is the important part. Many model releases improve raw intelligence. They produce better code, stronger explanations, or fewer mistakes. Fable appears to be aimed at something broader: increasing the amount of meaningful work that can be delegated as one coherent unit. Consider a Spring Boot migration. A conventional coding assistant may help with individual steps: update the Java version; change Gradle dependencies; inspect deprecated APIs; migrate configuration properties; fix failing tests; review Docker images; update documentation. That is useful. But the developer still acts as the orchestrator. You decide what happens next, inspect each response, correct direction changes, and continuously feed context back into the conversation. A more autonomous model can take responsibility for a larger slice of the problem: Analyze the repository. Create a migration plan. Identify compatibility risks. Apply the changes incrementally. Run the tests. Investigate failures. Correct the implementation. Summarize the final result. The individual tasks are familiar. The difference is how long the model can remain useful before a human needs to intervene. That is where Fable becomes interesting. The New Claude Model Ladder The Claude lineup now has three practical levels for most engineering teams. ModelBest FitAPI Input CostAPI Output CostClaude Sonnet 4.6High-volume daily work and production-scale agents$3 per million tokens$15 per million tokensClaude Opus 4.8Complex reasoning, difficult coding tasks, and premium agent workflows$5 per million tokens$25 per million tokensClaude Fable 5Ambitious, long-running work where maximum capability and autonomy justify the premium$10 per million tokens$50 per million tokens The pricing difference matters. Fable costs twice as much as Opus 4.8 and more than three times as much as Sonnet 4.6. That means Fable should not become the default model simply because it is the strongest one. The right model is not necessarily the most intelligent model available. It is the least expensive model that can reliably complete the task to the quality level you need. This is the same lesson we already learned with cloud infrastructure. You do not deploy every service on the largest available server just because it is faster. You select capacity based on the workload, the latency target, the reliability requirement, and the cost of failure. Model selection is becoming a similar architecture decision. Sonnet 4.6: The Default Is Better Than It Looks Sonnet is easy to underestimate because it sits below Opus and Fable in the model hierarchy. That would be a mistake. Sonnet 4.6 is still the model I would start with for the majority of engineering tasks: generating a REST controller; adding validation; writing unit tests; producing DTO mappings; reviewing a pull request; explaining unfamiliar code; updating documentation; creating a first implementation from a clear specification; running high-volume agent workflows where cost matters. The reason is simple: many development tasks are not intelligence-constrained. They are specification-constrained. A model does not need frontier-level reasoning to add an endpoint if the contract is clear, the project structure is consistent, and the acceptance criteria are explicit. In those situations, using Fable may produce a good result. But it is solving the wrong problem with a larger budget. Sonnet is also particularly useful when parallelism matters. Imagine a code-review pipeline that analyzes 40 pull requests per day. Each review includes code-quality checks, test-coverage analysis, security observations, dependency review, and documentation verification. Running every review through Fable would be expensive and unnecessary. A better approach is to use Sonnet for the first pass, collect structured findings, and escalate only the uncertain or high-risk cases. Sonnet becomes the scalable worker. It handles the volume. Opus 4.8: The Premium Daily Driver Opus 4.8 occupies a more interesting middle ground. Before Fable, Opus was the obvious answer whenever Sonnet started to struggle. It remains extremely relevant because it combines strong reasoning with a substantially lower cost than Fable. Opus is the model I would choose for tasks such as: investigating an intermittent production issue; reviewing a complex architecture proposal; tracing behavior across multiple microservices; performing a difficult refactor; designing a migration strategy; evaluating whether generated code is actually correct; coordinating a multi-step coding session where judgment matters. The distinction between Opus and Sonnet is not that Sonnet cannot handle difficult tasks. Often it can. The distinction is confidence. When the cost of a wrong answer is meaningful, Opus gives you more room for ambiguity, incomplete requirements, and subtle edge cases. Consider a RabbitMQ issue in a Spring Boot system. A consumer is occasionally processing a message twice. The obvious answer is to make the handler idempotent. But the real investigation may involve acknowledgment mode, retry configuration, dead-letter exchanges, transaction boundaries, database uniqueness constraints, consumer concurrency, tracing gaps, and whether the publisher retries before receiving confirmation. Sonnet can help with that investigation. Opus is more likely to pause before jumping to the first plausible explanation. That quality — knowing when the initial answer is not sufficient — is often what makes a premium model worth paying for. Fable 5: Use It When the Unit of Work Gets Larger Fable becomes valuable when the unit of work expands. The typical coding prompt is small: Add pagination to this endpoint. A Fable-sized task is different: Review the search module across the API and frontend. Identify inconsistent pagination behavior, standardize the contracts, update the Spring Boot implementation, adjust the React client, add regression tests, verify backward compatibility, and document the migration risks. The value is not onl...