Fable AI Coding in Practice: Optimizing Reasoning Levels and Multi-Model Collaboration to Cut Costs

This article is based on a hands-on YouTube video by well-known tech creator Theo (T3), focusing on the complete AI coding workflow he built around Anthropic's new model, "Fable."

A seasoned developer summed up his reaction to the new model in one sentence: "Saying Fable hit me like a truck is a massive understatement." On his first day back with the model, he accomplished more than he had in the entire previous month. This wasn't simply because "the model got smarter" — it was a complete restructuring of his entire working methodology.

Fable Is Not "A Better Opus": Clearing Up the Biggest Misconception

Many people mistakenly assume Fable is just an upgrade to Anthropic's Opus series, so they copy over their old Opus prompts unchanged — and are naturally disappointed with the results. Theo repeatedly emphasized: this is the most fatal misconception about this model.

To understand why old prompts can't simply be migrated, you need to understand Anthropic's technical evolution. Anthropic was founded in 2021 by former OpenAI VP of Research Dario Amodei and his sister Daniela Amodei as an AI safety company. Its Claude model series is distinguished by its "Constitutional AI" training approach — improving output safety and reliability by having the model critique and correct itself based on a set of value principles. This creates a notable methodological difference from OpenAI's RLHF (Reinforcement Learning from Human Feedback) approach. The core innovation of Constitutional AI lies in introducing an "AI Feedback (AIF)" component: the model not only receives preference signals from human annotators but also performs principle-based critique and revision of its own outputs under supervision, forming a self-refinement loop. This methodological difference doesn't just affect safety performance — it profoundly shapes the underlying mechanisms by which the model understands tasks, decomposes goals, and performs self-correction during multi-step execution. This is the deep reason why prompting strategies designed for other models often need to be recalibrated for the Claude series.

Claude's naming system has evolved multiple times: from the early Claude 1 and 2, to the later three-tier product matrix of Haiku (lightweight and fast), Sonnet (balanced), and Opus (top-tier intelligence), covering everything from edge computing to complex reasoning. The emergence of "Fable" represents not a linear iteration of Opus, but a fundamental restructuring of model architecture and task execution mechanisms — with essential changes in reasoning structure, context utilization, and multi-step planning capabilities. This is the deep reason why old prompting strategies completely fail, not simply because "it has more parameters."

Fable's true differentiator isn't that it "writes better code" — it's that it can "go further." It handles not just harder coding tasks, but complete end-to-end software development chains including implementation, testing, and verification. Especially when tasks need to be broken into smaller pieces and dispatched to sub-agents for execution, Fable demonstrates capabilities that previous models simply couldn't match.

In other words, Fable marks a paradigm shift: the model has evolved from a "code completion assistant" to "an executor capable of autonomously orchestrating complex engineering workflows." If you're still driving it with old-school thinking, you won't reap these benefits.

AI Coding Cost Optimization Lesson #1: Don't Use the Highest Reasoning Level

Theo admitted that during his first three days of unrestricted Fable usage, the actual cost ran into thousands of dollars. After optimizing his workflow, the same workload — including five and a half hours of continuous operation, fixing and merging over a dozen PRs — cost only about $150.

The most critical and surprising money-saving tip: don't go above the "high" reasoning level.

The tempting higher levels like X, high, and max are like "a slot machine begging you to put in just one more coin." They trap the model in excessive reasoning loops: repeatedly second-guessing itself, thinking longer and longer, ultimately producing "over-modified, over-engineered" terrible code at an outrageous cost.

The Truth About Reasoning Levels: They Affect Depth, Not Steps

Reasoning levels are essentially budget controls on the number of tokens the model uses for its "Chain-of-Thought (CoT)" process. CoT was systematically introduced by the Google Brain team in 2022. The core finding was that having the model generate intermediate reasoning steps before giving a final answer can significantly improve accuracy on complex tasks. This mechanism's effectiveness is rooted in the sequential generation nature of the Transformer architecture — the model works by predicting one token at a time, where each newly generated token can serve as an "anchor" for subsequent reasoning. Making intermediate steps explicit essentially leverages the model's own output space to extend effective context. However, this also means reasoning tokens consume computational resources and billing quota just like output tokens. In models that support extended reasoning (like Anthropic's Claude Thinking mode or OpenAI's o-series), the model generates large volumes of internal "draft" tokens before its formal response — invisible to users but counted for billing, often consuming far more than the final output itself. The higher the level, the greater the upper limit of internal reasoning tokens the model can consume, meaning the actual cost per tool call can grow exponentially.

The problem is that for most everyday coding tasks, excessively long reasoning chains lead to what cognitive science calls "analysis paralysis": the model repeatedly weighs edge cases, gets stuck choosing between equivalent paths, and ultimately generates overly defensive complex code that drifts away from clean, effective solutions. This closely mirrors how human experts make decisions — true experts tend to rely on pattern recognition to quickly produce simple, direct solutions rather than deploying massive cognitive resources for exhaustive reasoning. Research shows that overthinking under noisy conditions doesn't just fail to improve decision quality — it systematically degrades it.

Many people assume max can solve harder problems or let the model work longer, but in reality: reasoning level only affects the depth of thinking per individual tool call — it doesn't determine how many steps the model can execute. A task requiring 500 steps won't get any extra steps from max — it'll just think more deeply at each step, when most steps don't need that much deliberation.

Even more telling: the so-called "ultra code" mode under the hood is simply the high level spinning up more concurrent instances. "Even Anthropic themselves consider high the best value for money — there's a reason it's the default." The recommendation is to stick with low to high, lock it at high, and stop overthinking it. This single change alone can cut your bill by more than half.

Teaching Claude to Call Codex: Multi-Model Collaboration to Reduce Token Consumption

The second core technique is teaching Claude Code to call OpenAI's Codex (GPT-5.5). This seems contradictory — if Fable is so powerful, why use another model? The answer lies in rational division of labor based on cost and specialization.

Using different AI models for different task types — known as "Model Routing" — has become a core practice in AI Cost Engineering. This field borrows from the cloud computing concept of "right-sizing": different workloads should be matched with appropriately scaled compute resources rather than always using the highest configuration. The FinOps (Cloud Financial Operations) methodologies accumulated by cloud providers like AWS and GCP over the years are now being systematically transplanted to the AI inference layer: cost visibility, usage tiering, on-demand scaling, and continuous optimization — all these principles apply equally to AI coding scenarios. Notably, the engineering challenge of model routing isn't just about "which model to pick" but how to dynamically assess a task's intelligence density requirements at runtime. This has spawned a new class of "routing layer" tools (like LiteLLM, OpenRouter) that establish a programmable intelligent dispatch layer between callers and model providers, allowing developers to implement cost-aware cross-model routing through a unified API. This complements Theo's approach of manually defining routing rules in Claude.md — the former suits high-frequency standardized scenarios, while the latter suits complex tasks requiring deep project context.

For specific task tiering, you can roughly classify by "intelligence density": simple log parsing and document reading tasks have low deep reasoning requirements but high token consumption, making them suitable for cheaper models or those with generous quotas; tasks requiring deep code comprehension, cross-file architectural judgment, and edge case reasoning are the ones worth calling top-tier models for. The extreme form of this tiered thinking is the "Mixture of Experts" architecture — dynamically routing inputs to different expert networks within the model based on input characteristics — and model routing extends this concept to the system architecture level. OpenAI's Codex, with its subscription-based periodic quotas, is a natural fit as the workhorse for "heavy lifting," forming a complementary cost structure with Fable. This hybrid model architecture is expected to become the standard paradigm for future AI engineering.

Codex subscription quotas are "absurdly generous" — even after heavy use for an entire week, only about 15% of the weekly limit was consumed. Therefore, tasks that consume large amounts of tokens but don't require top-tier intelligence should be handed to Codex, such as:

• Sifting through massive logs
• Reading huge PDFs and implementation specification documents
• Computer use — OpenAI is notably stronger in this area

The Codex desktop app can truly control an entire Mac: configuring Xcode, navigating between complex apps to pull data, and recording a video for you when done. It takes about an hour to teach Fable in your global Claude.md which tasks should be "shelled out" to GPT-5.5.

Using a "Glossary" to Align Judgment Standards Across Models

In your configuration file, you can establish a scoring system for different models across three dimensions: intelligence, taste, and cost. For example, GPT-5.5 scores high on intelligence and low on cost, but lacks "taste" — "It writes TypeScript like a Python developer and writes Rust like an extremely paranoid C++ developer" — its output style may not match expectations. Fable, on the other hand, is best-in-class for both intelligence and taste, but costs more.

Key practice: Define a "glossary" in your Claude.md that spells out exactly what you mean by terms like "intelligence" and "taste."

Claude.md is the core configuration file in the Claude Code toolchain for persisting project context, designed around the engineering practice of "System Prompts." Unlike one-off conversational prompts, Claude.md is automatically injected at the start of every session, ensuring the model always has access to the project's tech stack preferences, code style conventions, architectural constraints, team glossary, and other critical information. This fundamentally addresses an inherent limitation of large language models: statelessness — Transformer-based models have no cross-session memory capability and start every conversation from scratch, requiring external files to explicitly pass context. The emergence of Claude.md essentially upgrades "prompt engineering" from an art to an engineering discipline: it's version-controlled, team-shareable, and evolves with the codebase, rather than being scattered across individual developers' conversation histories. In multi-model collaboration scenarios, Claude.md also serves a "meta-orchestration" role: telling the primary model when to delegate tasks to other models and how to judge the applicability boundaries of different models. Furthermore, the glossary in Claude.md solves a subtle but critical problem — "semantic drift": when you tell different models to "review code quality," each model's concept of "quality" based on its training data may differ significantly. Explicitly defining terms establishes a common language for the entire multi-model system, ensuring every executor has aligned understanding of task objectives. This elevates the configuration file from a simple prompt template to the "constitutional document" of the entire AI workflow — no less important than the code itself.

This helps the model understand task descriptions and also enables it to make decisions aligned with your intent when autonomously choosing which model to call.

Sub-agents and Workflows: Fable's True Killer Features

Understanding the distinction between these two concepts is key to mastering Fable's advanced capabilities:

• Sub-agents: The main agent uses tools to spawn another agent to execute a task — ideal for parallel analysis of multiple files.
• Workflows: Programmatically define multi-stage collaboration between sub-agents — for example, stage one scans all files, stage two dispatches two reviewers for each flagged item. It's essentially a JavaScript orchestration file generated by the model itself to dynamically manage long-running tasks.

The intellectual roots of multi-agent architecture can be traced back to Marvin Minsky's core thesis in The Society of Mind (1986): complex intelligence emerges from the collaboration of many simple individuals, not from a single omnipotent entity. This aligns closely with the "Divide and Conquer" principle in software engineering and has gained unprecedented engineering feasibility as large model capabilities have improved. It's worth noting that early multi-agent systems (like the precursor research to AutoGen in the 1990s) were limited by communication overhead and single-model capability bottlenecks, where collaboration benefits were often offset by coordination costs. The breakthrough in the large model era is that each sub-agent itself possesses sufficient language understanding and generation capabilities, making natural language protocols between agents a viable interface standard, dramatically reducing the design complexity of multi-agent systems. In practice, sub-agent architecture simultaneously addresses three key bottlenecks: first, it breaks through the length limitations of a single context window — even million-token contexts have physical boundaries, and splitting tasks across multiple agents bypasses this limit; second, it enables true parallel processing, compressing sequential workflows into concurrent execution and dramatically reducing end-to-end time; third, it allows different agents to call different models, enabling fine-grained cost optimization across the overall architecture. Fable's true breakthrough in this domain is that the model itself can dynamically design sub-agent role archetypes and collaboration protocols based on current task characteristics, rather than relying on developers to hard-code each agent type in advance. This means orchestration intelligence has been elevated from the "tool layer" to the "model layer" — developers shift from defining "how to divide work" to describing "what goal to achieve."

The most stunning breakthrough: previously, developers had to manually define various archetypes like "review sub-agent," "adversarial review sub-agent," and "exploratory sub-agent" in their tools — tedious and rigid. Fable can now invent these agent archetypes on its own based on specific task requirements. "Every time I want the model to review something, the needs are slightly different, and the model is now smart enough to define them itself."

Real-World Case: Using Fable to Clean Up 16 Zombie PRs

Theo demonstrated the full workflow using his project Lakebed. During his time without Fable access, he'd accumulated 16 "half-finished" PRs — 50% to 80% complete, but with unsatisfactory SDK changes, uncertain implementations, and painful cleanup work. The entire project had stalled for a full month.

Pull Requests (PRs) are the foundational unit of modern collaborative software development, originating from the patch email workflow Linus Torvalds designed for managing Linux kernel contributions. GitHub graphicalized and popularized it as an industry-standard process in 2008. A healthy PR workflow typically includes: feature branch development, automated CI/CD pipeline triggers, static code analysis, manual code review, and final merge to the main trunk (main/master) followed by deployment pipeline execution. The "zombie PR" phenomenon often isn't purely a technical problem but reflects the engineering team's cognitive burden and decision friction: when developers need to simultaneously maintain the mental state, dependencies, and potential conflicts of multiple half-completed branches, context-switching costs grow non-linearly with the number of backlogged items — this is precisely why "Work In Progress (WIP) limits" are a core practice in the Kanban method. The unique value of AI agents in cleaning up zombie PRs is that they can statelessly and without switching costs simultaneously examine all pending branches, replacing human serial cognitive burden with parallel analysis. A "staging environment" is the final validation barrier before production — architecturally identical to production but with fully isolated traffic, allowing verification of changes on real infrastructure without affecting real users. Restricting AI agents to operate strictly within staging boundaries reflects the creative application of the information security principle of "Principle of Least Privilege" in AI system design: even if agent behavior deviates unexpectedly, its impact is hard-limited to a recoverable sandbox, finding an acceptable engineering balance between "autonomy" and "safety."

He progressed through several steps, with each prompt reflecting the new thinking of the "Fable era":

1. Review and categorize first: Had Fable use a workflow to classify the 16 PRs into four categories: "ready to merge directly," "needs minor fixes," "superseded," and "has good ideas but should be rewritten." It dispatched 48 agents (one investigator + one stress tester per PR). 14 out of 16 reached consensus.
2. Clean up and replan: Closed useless PRs, wrote new HTML implementation plans for retained features, and required linking back to the original PRs that inspired them.
3. Set a Goal for autonomous execution: Finally set a "goal" — letting the model run continuously until conditions were met: create worktrees, rebase, merge, close PRs, until all items in todo.md were completed.

The result: the model ran continuously for five hours, with new code landing every time he refreshed GitHub. An entire month's roadmap was completed, transforming the project from a month behind to a month ahead.

Why Dare to Let AI Merge Directly to Main?

This sounds radical, but the safety boundaries are clear: production deployment always has human oversight — AI can only touch the staging environment. Merging to main only triggers a staging deployment; the model can't touch prod. Combined with three automated code reviewers — bug bot, Macroscope, and CodeRab — code goes through extensive feedback and simplification before being merged.

Afterward, he deliberately spent more tokens on verification than on code generation — dispatching other agents to test new and old features, check differences between prod and main, and add test cases. The conclusion was "hardly anything needed changing."

Using "Task Duration" to Gauge Codebase Health

A valuable mental framework: evaluate codebase quality based on how long the model takes to complete a task and how many changes it makes.

• Done in 3 minutes → Simple fix, safe to submit a PR
• 15 minutes → Deserves some attention
• Over 1 hour → "There might be architectural issues that need deep investigation"

For example, a "mobile scroll jitter" fix took over an hour and a half, putting Theo on alert and making him reluctant to blindly merge. Meanwhile, a more annoying "back swipe" issue was resolved in 2 minutes and 20 seconds. Task duration itself is an excellent indicator for exposing weak spots in a codebase.

The deeper logic behind this framework is that AI model reasoning time is highly correlated with a task's "essential complexity." When a seemingly simple UI fix requires the model to jump extensively through the codebase and repeatedly try different fix paths, it often means unclear underlying abstractions, poor separation of concerns, or deep technical debt. This closely aligns with signals captured by software engineering metrics like "Cyclomatic Complexity" and "Cognitive Complexity" — cyclomatic complexity measures the number of independent paths in a code control flow graph, while cognitive complexity attempts to quantify the mental burden on humans understanding the code. Both are core measurement dimensions on code quality platforms like SonarQube. But AI task duration provides a more intuitive, dynamic measurement — it's not an abstract metric analyzing code structure, but rather systemic performance emerging under real task pressure. Particularly noteworthy is that static complexity metrics can only capture the complexity of local code units, while AI duration reflects the "systemic comprehension cost" across files and modules — a dimension that static analysis tools can barely measure. In other words, the AI's "level of confusion" is a mirror of codebase health, quantifying with computation time what human developers sense intuitively but struggle to articulate as "code quality," transforming what was once a subjective judgment of technical debt into an observable, comparable engineering metric.

Toolchain and Mindset: The Underlying Logic of Mastering AI Coding

On the tooling front: using the open-source T3 Code to flexibly switch control of agents between phone, Mac Mini, and Linux machines; connecting remotely via tailscale; using vibe proxy to automatically distribute requests across multiple accounts to circumvent quota limits. A significant amount of work can even be done on a phone during meetings.

But the more important shift is in mindset: don't be afraid to modify configuration files. Theo deliberately withholds his skills and Claude.md originals: "I want you to learn from this, not copy-paste and then be afraid to touch anything for fear of breaking it." The real payoff comes from continuous experimentation and adjustment, turning it into a system that works for you.

The essence of this "systems thinking" is elevating AI tool usage from "tip accumulation" to "engineering design": design your AI workflow like you'd design software architecture, with clearly defined component responsibilities, data flows, and failure handling mechanisms. When your Claude.md starts looking like a serious technical specification rather than casually jotted prompts, you've truly entered the new paradigm of AI coding.

Summary: Core Lessons of the New AI Coding Paradigm

Fable brings not just a capability upgrade, but a fundamental reshaping of how we work. The core lessons can be distilled to a few points:

• Abandon the "better Opus" mental model — master Fable with an entirely new paradigm
• Keep reasoning levels at high or below — cut more than half of unnecessary costs
• Use Codex to handle high-consumption, low-intelligence tasks — boost efficiency through multi-model collaboration
• Leverage workflows to let the model autonomously orchestrate complex processes
• Always maintain human oversight over production environments

As Theo put it, this is a "new era" — the developer's role is shifting from "writing code" to "designing systems, orchestrating agents, and making architectural decisions." Those who know how to harness these models are building products at unprecedented speed.