Fable AI Coding in Practice: Optimizing Reasoning Levels and Multi-Model Collaboration to Save Money

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: "To say Fable hit me like a truck would be a massive understatement." On the very first day he got access back to this model, he accomplished more work than he had in the entire previous month. This wasn't simply because the "model got smarter" — it was a complete restructuring of how he works.

Fable Is NOT "a Better Opus": The Biggest Misconception

Many people mistakenly assume Fable is just an upgrade to Anthropic's Opus series, so they copy-paste their old Opus prompts without any changes — and are naturally disappointed by the results. Theo repeatedly emphasizes: 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 known for its "Constitutional AI" training approach — having the model critique and revise its own outputs based on a set of value principles to improve safety and reliability. This represents a significant 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)" step: 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 model's underlying mechanisms for understanding tasks, decomposing goals, and performing self-correction during multi-step execution. This is the deep reason why prompt strategies designed for other models often need recalibration on the Claude series.

Claude's naming system has evolved multiple times: from the early Claude 1 and 2 to the 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 arrival 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 old prompt strategies completely fail, not simply "more parameters."

Fable's real differentiator isn't that it "writes better code" — it's that it can "go further." It handles not only 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 still approach it with old thinking, you won't reap these benefits.

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

Theo admits that during the first three days of unrestricted Fable usage, the cost based on actual consumption amounted to 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: keep reasoning levels at "high" or below.

The X, high, and max tiers that look so tempting are like "a slot machine begging you to insert one more coin." They trap the model in cycles of over-reasoning: second-guessing itself repeatedly, thinking longer and longer, ultimately producing "over-modified, over-engineered" terrible code at outrageous costs.

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

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

The problem is that for most everyday coding tasks, overly long reasoning chains lead to what cognitive science calls "analysis paralysis": the model repeatedly weighs edge cases, can't decide between multiple 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 rely on pattern recognition for quick, straightforward solutions rather than deploying massive cognitive resources for exhaustive reasoning. Research shows that overthinking under noisy conditions doesn't improve decision quality — it systematically degrades it.

Many people assume max can solve harder problems or make the model work longer, but in reality: reasoning levels only affect the depth of thinking per tool call, not how many steps the model can execute. A task requiring 500 steps won't get any additional steps with max — it will just think more deeply at each step, and most steps simply don't need that depth.

Even more convincing: the so-called "ultra code" mode actually just spins up more instances in parallel at the high level. "Even Anthropic themselves consider high the best value — there's a reason it's the default." The recommendation is to stick with low to high, set it to high, and stop overthinking it. This single change alone can cut your bill by more than half.

Having Claude 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 — "Model Routing" — has become a core practice in AI Cost Engineering. This field borrows from the "right-sizing" philosophy in cloud computing: different workloads should be matched with appropriately scaled compute resources rather than always using the highest configuration. The FinOps (Cloud Financial Operations) methodologies accumulated over years by AWS, GCP, and other cloud providers are now being systematically applied 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 (such as LiteLLM and 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 categorize by "intelligence density": simple log parsing and document reading require little deep reasoning but consume lots of tokens, making them ideal for cheaper models or those with generous quotas. Tasks requiring deep code understanding, cross-file architectural judgment, and edge-case reasoning are the ones worth invoking a top-tier model for. The extreme form of this tiered thinking is the "Mixture of Experts" architecture — dynamically routing inputs to different expert networks within a model based on input characteristics. Model routing extends this idea to the system architecture level. OpenAI's Codex with its subscription-based periodic quotas is naturally suited 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" — a full week of heavy use only consumed about 15% of the weekly limit. Therefore, tasks that consume lots of tokens but don't require top-tier intelligence should be handed off to Codex, such as:

• Searching 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 your entire Mac: configure Xcode, navigate complex applications to pull data, and record a video for you when it's 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 Rust like an extremely paranoid C++ developer" — its output style may not match expectations. Fable is best-in-class for both intelligence and taste, just at a higher cost.

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 each session, ensuring the model always holds key information about the project's tech stack preferences, code style conventions, architectural constraints, and team glossary. This fundamentally addresses an inherent limitation of large language models: statelessness — Transformer-based models have no cross-session memory, starting from zero with each conversation, and must receive context through external files. The emergence of Claude.md essentially upgrades "prompt engineering" from art to engineering specification: it has version control, can be shared across teams, and evolves alongside the codebase, rather than being scattered across individual developers' conversation histories. In multi-model collaboration scenarios, Claude.md also takes on a "meta-orchestration" role: informing the primary model when to delegate tasks to other models and how to judge the applicability boundaries of each. 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 can vary dramatically. Explicitly defining terminology establishes a shared 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 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 difference between these two concepts is key to mastering Fable's advanced usage:

• Sub-agents: The main agent invokes a tool to spawn another agent to execute a task — ideal for analyzing multiple files in parallel.
• Workflows: Programmatically define multi-stage collaboration among 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 trace 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 with the recent advancement of large models. It's worth noting that early multi-agent systems (such as precursor research to AutoGen in the 1990s) were limited by communication overhead and single-model capability bottlenecks, where collaboration benefits were often negated by coordination costs. The breakthrough in the large model era is that each sub-agent itself possesses sufficient language understanding and generation capability, 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, breaking through the length limit of a single context window — even million-token contexts have physical boundaries, and splitting tasks across multiple agents bypasses this; second, enabling true parallel processing, compressing serial workflows into concurrent execution for dramatically shorter end-to-end times; third, allowing different agents to invoke different models for granular cost optimization across the overall architecture. Fable's real breakthrough here is that the model itself can dynamically design sub-agent role archetypes and collaboration protocols based on the current task's 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 "review sub-agent," "adversarial review sub-agent," and "exploratory sub-agent" archetypes in their tools — tedious and rigid. Fable can now invent these agent archetypes on its own based on specific task requirements. "Every time I ask the model to review something, the requirements are slightly different, and the model is now smart enough to define them itself."

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

Theo demonstrated the complete process with his project Lakebed. During the period without Fable access, he accumulated 16 "half-finished" PRs — 50% to 80% complete, but with unsatisfactory SDK changes and uncertain implementations that were tedious to clean up. The entire project had stalled for a full month.

Pull Requests (PRs) are the fundamental 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 into the trunk (main/master) triggering deployment pipelines. The "zombie PR" phenomenon often isn't purely a technical issue — it reflects a team's cognitive load and decision friction: when developers need to simultaneously maintain the state, dependencies, and potential conflicts of multiple half-finished branches in their heads, context-switching costs grow non-linearly with the number of pending items. This is precisely why "Work In Progress (WIP) limits" are a core practice of the Kanban method. The unique value of AI agents in cleaning up zombie PRs lies in their ability to simultaneously examine all pending branches statelessly and without switching costs, replacing the serial cognitive burden on humans with parallel analysis. A "staging environment" is the last validation barrier before production — architecturally identical to production but with completely isolated traffic, allowing changes to be verified on real infrastructure without affecting real users. Restricting AI agents to operate strictly within staging boundaries reflects the creative application of information security's "Principle of Least Privilege" in AI system design: even if agent behavior deviates unexpectedly, its impact is hard-limited to a recoverable sandbox, striking an acceptable engineering balance between "autonomy" and "safety."

He progressed in several steps, with each step's prompts reflecting the new thinking of the "Fable era":

1. Review and classify first: Have Fable use a workflow to sort all 16 PRs into four categories: "ready to merge," "needs minor fixes," "superseded," and "has good ideas but should be rewritten." It dispatched 48 agents (one investigator plus a stress tester per PR). 14 out of 16 reached consensus.
2. Clean up and re-plan: Close useless PRs, write new HTML implementation plans for retained features, and require linking back to the original PR that inspired them.
3. Set a goal for autonomous execution: Finally set a "goal" — let the model run continuously until conditions are met: create worktrees, rebase, merge, close PRs, until all items in todo.md are 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 one month behind to one month ahead.

Why Dare to Let AI Merge Directly to Main?

This sounds aggressive, 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 — the code goes through extensive feedback and simplification before merging.

Afterward, he deliberately spent even more tokens verifying the results than generating code — dispatching other agents to test old and new features, check differences between prod and main, and add test cases. His conclusion: "There was barely anything that needed changing."

Using "Task Duration" to Gauge Codebase Health

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

• Finished in under 3 minutes → Simple fix, safe to submit a PR
• 15 minutes → Warrants some attention
• Over 1 hour → "There might be an architectural problem that needs deep investigation"

For example, fixing a "mobile scroll jitter" issue took over an hour and a half, making Theo wary of blindly merging. But another 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: an AI model's 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 usually indicates unclear underlying abstractions, poor separation of concerns, or deep-seated technical debt. This closely aligns with signals captured by software engineering's "Cyclomatic Complexity" and "Cognitive Complexity" static analysis metrics — cyclomatic complexity measures the number of independent paths in a code's control flow graph, while cognitive complexity attempts to quantify the mental burden on humans understanding the code. Both are core measurement dimensions in code quality platforms like SonarQube. But AI duration provides a more intuitive, dynamic measurement — it's not an abstract metric analyzing code structure, but a systemic performance that emerges 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 "degree of confusion" serves as a mirror of codebase health, using computation time to quantify what human developers perceive intuitively but struggle to articulate about "code quality" — transforming what was previously a subjective judgment about technical debt into an observable, comparable engineering metric.

Toolchain and Mindset: The Underlying Logic of Mastering AI Coding

On the tooling side: use the open-source T3 Code to flexibly switch between controlling agents from a phone, Mac Mini, or Linux machines; connect remotely via tailscale; use vibe proxy to automatically distribute across multiple accounts to circumvent quota limits. A large portion of the work can even be done from a phone during meetings.

But more important is the mindset shift: don't be afraid to modify configuration files. Theo deliberately doesn't share his skills and Claude.md verbatim: "I want you to learn from this, not copy-paste and then be afraid to make changes for fear of breaking things." The real gains come 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 the way you'd design software architecture, with clear responsibility boundaries, data flows, and failure handling mechanisms for each component. When your Claude.md starts to read like a serious technical specification rather than casually jotted-down prompts, you've truly entered the new paradigm of AI coding.

Summary: Core Lessons for the New AI Coding Paradigm

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

• Abandon the "better Opus" mindset and master Fable with an entirely new paradigm
• Keep reasoning levels at high or below, cutting more than half of unnecessary costs
• Use Codex to handle high-consumption, low-intelligence-requirement tasks for multi-model efficiency
• Leverage workflows to let the model autonomously orchestrate complex processes
• Always maintain human oversight of the production environment

As Theo puts 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.