After Fable: Scaling and Layering

Today is 2026.7.2, and Fable has been unlocked again. I'd already spent a day doing all-Fable development, so I had a relative sense of the model's strength — but at that point my understanding of Fable was more like "a bigger Opus." Then, a couple of days ago, I tried migrating my Opus workflow over to Sonnet 5 (the benchmarks looked close), and only then did I really come to understand Claude's model lineup as a whole.

I. Let's Talk Models First #

T0: Anthropic's Complete, Mature Pyramid #

For Sonnet 5 and Fable 5, the key points are:

1. Sonnet 5 is built on the same generational base as Opus; after the update to 5.0, the tokenizer was unified.
2. Comparing GLM 5.2 with Sonnet 5, GLM reaches extremely close performance — which at minimum shows that at the same size, Chinese models are not behind at all.
3. Comparing Opus 4.8 with Sonnet 5, Opus is far better than Sonnet at digging into and planning around a problem (even Opus low versus Sonnet max).
4. Same as point three: Fable is far better than Opus at digging into and planning around a problem.
5. All three models — Sonnet, Opus, Fable — show a sharp performance drop when the "depth of the error" runs too deep.

My most central view is still point five: Anthropic already holds a stable, well-defined expectation for all three models, and has specifically reinforced them for particular task depths. This has shifted Anthropic's model pyramid up by a whole tier (meaning Haiku is simply abandoned — completely inapplicable).

A concrete explanation of point five:

• If you ask Fable what to eat tonight, Fable will search your memory and try to generalize an answer with a huge number of branches and enormous depth — but purely in terms of the outcome, it hasn't helped you decide what to eat tonight.
• If you ask Sonnet about deploying a specific server configuration, Sonnet will do a shallow search and a worse summary, handing you an answer that's workable but simple-minded — usable, but it hasn't designed you a good server architecture.

This kind of pyramid layering was visible from the earliest Opus-Sonnet-Haiku naming, but once we entered the agent era, Anthropic's depth of understanding and degree of execution on the pyramid idea far surpassed everyone else's. Concretely:

• The so-called Flash-size and Pro-size models are just a simple scaling down/up of performance — a family resemblance, but no real layering — which ultimately pushes more users to just reach for Pro for everything.
• Many Chinese model makers don't even have adequate model layering; more often they pull out a single flagship and ride it forever, using so-called "thinking depth" to fake a layering (GPT 5.5 included — I'm glad GPT 5.6 got it right).
• Anthropic trained specifically for each task-difficulty level, so it can make the optimal ranges of the three models interlock — on one hand locking in family-wide API usage, on the other being enormously beneficial to engineering (even when you're designing your own workflow).
  • If a 1T-scale open-source model were 20% cheaper than Sonnet 5, I'd still use Sonnet inside Claude Code, because Sonnet's zone of advantage is predictable to me. That matters even more in a stable workflow.
  • A small model's flashes of brilliance (1T counts as a "small model" here) are catastrophic for the workflow as a whole — they actually demand stricter skills and context to rein them in.

In sum, I firmly back Claude as the strongest AI product of this era — though of course AI opens a new era roughly every two months (prompts and skills have both been surpassed by loops, which is genuinely painful), so I've gotten used to it.

T0.5: OpenAI's Dawn, Before Sunrise #

This piece was written before GPT 5.6 shipped, and I'm glad OpenAI has also learned this architecture. Relative to Claude's pyramid structure, GPT's 5.5 series — and the mini size they discontinued outright — looks severely inadequate, especially the split between a code-purpose model and a general model, which to me is pouring too many resources into a compromise.

But I still think OpenAI is a rock-solid T0.5 vendor, and that's because of Codex. On the stability I mentioned earlier, Codex's agent architecture is very good; I'll get into that comparison later.

Before GPT 5.6 ships, there's really no way to guess anything. Current benchmarks don't adequately display a model's capability — a 10% performance gain may do nothing, while the 2% gap between Opus and Fable is a clear two-tier difference. So it all comes down to how powerful GPT 5.6 actually is, and how well GPT 5.6 adapts to Codex.

T2: Everyone Else #

Relative to those two, the gap for other models was already stretched too wide in the previous era (i.e., before Opus 4.6 shipped).

• Claude's constitution demonstrates Claude's research into and understanding of what a model fundamentally is; they've turned that understanding into precise "sweet-spot" model design.
• OpenAI's image integration correspondingly specialized text-detail capability (the increase in noise after multiple image edits is exactly the compromise made for text precision), which shows that this giant, OpenAI, has also started to seriously think about what a model's goal actually is (the utterly pointless project Sora — I don't get why OpenAI wants to build a community from scratch).

The methodologies of these two are already too far ahead, and stacking their dedicated agents on top, I don't think you should spend time on any agent architecture other than Codex and Claude Code. Time is worth more than tokens; spending a year or two optimizing an open framework is only surface work — what's actually eternal is fine-tuning and adapting to the model.

Worth a sentence here: the reason DeepSeek doesn't get its own tier is that they haven't yet released their own DeepSeek agent architecture, and that's forever the crux — otherwise it's hard to piece together an agent framework's design from scratch. Aside from DeepSeek, the other models are severely behind the times. I of course hope we can have a strong open-source model, even a whole open-source series, but as it stands the vast majority of series chase "each model size hitting SOTA on general tasks" rather than actually producing a lineup of usable models.

A few more gripes about benchmarks:

Just as I've always disliked academia, taking a 3B Qwen2.5 and heavily optimizing it on all sorts of toy benchmarks is essentially another kind of overfit. It now looks like 100B-to-1T models generally hit this too — usually using Claude Code or the opencode framework, squeezing a 1–2% lead on a specific benchmark out of a carefully designed framework, then declaring themselves SOTA.

This tireless little sparring can keep going until the year 2077, but what does it actually do for AI? Investors believe in AI as a future industry — not in treating an AI company like an especially expensive football club.

II. There Has Never Been an "Open Harness" #

We often say a model needs to be constrained by a framework — model + harness = agent — but that sentence gets explained very thinly. For stable large companies like Anthropic and OpenAI, they can clearly control the style and specific traits of their own models, so they conceive and develop the harness around that, producing their own corresponding framework. So model and harness are not a simple stacking; their union is closer to forging a blade and its hilt: the blade is designed for a particular kind of cut, and the hilt ensures the blade can be wielded steadily by the user. Here my assessment of the frameworks runs exactly opposite to my assessment of the models.

T0: Stable Codex VS Wild Claude Code #

It's quite striking that Claude, which has such deep understanding at the model level, in actual use often ends up neck-and-neck with the messier GPT 5.5; depending on the task, users come to prefer either Codex or Claude Code. Let me briefly contrast the two:

• Claude: unbridled yet rational. Claude's top-tier models usually have both extremely strong exploratory power and extremely strong management ability in long-horizon planning. You can watch Opus, under deep research, spin up 100 subagents for an outrageously divergent search, yet finally distill it into a lean, dry spec; you can also see, in concrete UI design, Opus's control over the specific elements Sonnet lays out. The essence of Claude Code is to constrain the tool calls well, not to constrain the Claude model's play. That's why I've always found it strange to plug open-source models into Claude Code — it's like pulling the cane out from under someone who already walks unsteadily, leaving them to stagger. This missing stability opens an even wider performance gap in an environment where loop engineering is everywhere.
• Codex: serious. Codex's overall design strictly constrains the model's capability and massively strengthens instruction-following. That's a big advantage for most lab staff and data-analysis work, and even for everyday tidying of files on your computer. But correspondingly, GPT's autonomy is much smaller; I think a small part of that comes from OpenAI's design of GPT, but a larger part comes from Codex's constraint of the framework.

For this part in practice, you can just test with the skill-creator pipeline in my repo. This set of skills is itself designed for Claude and uses Claude for the eval flow, and it has a lot of loop-verification designs that require the model to judge autonomously and pause. In Claude, this set of skills paired with Opus can quickly and autonomously generate high-quality skills.

Whereas if you run the same set of skills in Codex, you get extremely severe token waste, because GPT's gate forces it to strictly obey the guiding loops in the skill; most likely you'll see GPT hugging my prescribed defaults and running the loop mechanically, which leaves the generated skill simultaneously under-developed in function and over-fitted in function.

Here's a simple intuitive test to help you choose between the $200 tiers of Codex and Claude:

• If you know what you want to do and want the agent to be as stable and reliable as a tool: buy Codex — Claude will steer the project toward the direction it prefers.
• If you have a vague idea and want the agent to help you build the concept out fully, like an assistant: use Claude — Codex will ship a crude, unpleasant MVP.

What's excellent about these two is that they clearly gave their model team and their harness team two distinct goals, and both teams executed the corresponding design. Setting aside add-ons like remote phone control and computer use, and talking purely about the code framework, these two are still in a class of their own at T0 — and once again my framework rankings have no T1.

Given that GPT 5.6 has now become a three-tier layered architecture, I think Codex's current framework can't fit its own three models. In the end, execution will make the bottom-tier model do overly aggressive "forced fixes" (i.e., unspecified changes that ignore the spec), and then the top-parameter model gets yanked back to the prompt's requirements by the framework. As for actual practice, we'll have to see how Codex designs it.

T2: Open-Source Frameworks and Headless Frameworks #

By "headless framework" I mean, broadly, the frameworks companies build that encourage switching among various open-source models. These frameworks are forced to design fallback settings and cases; from the overall design they have to account for the execution noise that model differences introduce. As a result, the bulk of the framework goes into suppressing noise — and that algorithm is still a crude, passive denoiser.

• Versus Codex: because there's no corresponding model, you can't be sure whether the model has an unbridled or a conservative style, so you must specify relatively neutral instruction-following, which leaves the capability behind.
• Versus Claude Code: relatively more control is added, but you can't verify what each capability tier's model can actually do, can't stably use subagents for development and downgrading, and also lack a true flagship model to fully control the big picture.

The most speechless of all is still Tencent's WorkBuddy — whose UI design is, in my view, still one of the worst of the year. Pointless repeated UI changes (I tried it during the closed beta too, and the design back then was even weirder; I thought it was a cat Meituan had specially designed for the name LongCat), an overall lack of a central design, a user-hostile quota/points system — yet by leaning on integration with Mini Programs and a brute-force hookup with WeCom, it has already become one of the overlords. That says something about how the current market is still channel-driven: domestic users, capped by model limits, have such low demand for framework performance that jokes like this can happen.

T1*: The Multimodal Possibilities of Doubao, GPT, Gemini, Claude #

Especially worth calling out: the frameworks designed by these three-and-a-half (Claude Design counts as half an image tool) all carry an integration of the vendor's image and video capabilities, which means they can't be lumped in with traditional engineering frameworks benchmarked on coding or analysis. But I have no design experience in this area — mostly it's Claude and GPT doing the generating — still, I'll plant a flag here: I believe integrating multimodal capability into agents will bring new opportunities.

III. Some Miscellany on Loop Engineering #

• On loop engineering, I think repeated looping and specs cannot solve an intelligence problem. If a model's ability is at level B, then no matter how you loop, it can still only do level-B tasks; a sudden emergence of higher-level understanding is unstable and needs a lot of tokens to trial-and-error — whereas a higher-tier model can solve the problem in a single round (using subagents to expand context, so you're not cramming the whole project's code into 1M tokens).
• More looping places enormous demands on both the spec and the model's ability. Even with subagents doing good-enough context isolation, and even with a live-updating mechanism to refresh the spec, none of these improvements solves the most basic problem of model capability.
• In the loop, the Attacker that gives feedback at the end matters a lot; you must ensure context isolation (the other parts, for performance, ultimately have to leave enough context to make use of the long-context ability). Of course, from start to finish the most important thing is still the spec at the beginning, then the attacker (checking whether the loop is done), then the engineer (the concrete building); the router, by contrast, just needs to handle automated management of temp files.

IV. A Dialogue with Fable #