Model and effort level are routed by pipeline stage, not by card — and the reviewer is deliberately a different vendor than the builder.

As of 2026-08-28, five models do work for me, but only three of them run inside the automated pipeline: Fable 5, Sonnet 5, and GPT-5.6 Sol, across three different effort levels between them. None of it is one preference applied everywhere. Every card moves through the same lane — spec, build, review, fix, verify, ship — and model and effort level are picked for the stage, not the card.

There’s no per-card override. “I don’t really have a way to say for an individual card that I’m going to change, for it to not use Sonnet or for it to use a different kind of model, just for that individual card, it’s kind of everything carte blanche at this point.” The model is bound to the stage, not the card — per-card routing is, at most, “maybe an opportunity,” something I haven’t built.

The casting

My practice, as of 2026-08-28.

Why the reviewer is a different vendor

The review stage didn’t start on a different vendor. For about three weeks it was all one model, and the seams showed: “any bugs or issues that I would have found at night, they didn’t come through. So things were being accepted, they were being deployed, and then, as I was validating, there would be bugs and there would be issues. And that was really obnoxious. So I really needed to find a different model.” I’ve written before about the shape of that failure: the reviewer shared the builder’s blind spots, and more than half of my tokens were going to review.

Anthropic’s own multi-agent research names the mechanism I was running into: agents on the same model, the same context, and the same scaffolding converge on the same behavior, so one bad call spreads system-wide instead of staying isolated. In one internal test, eighteen of thirty agents independently named their git branch mvp-game-loop, with no shared prompt guidance on the name at all. Same model plus same task correlates on its own — no coordination required to produce it.

My answer wasn’t a smarter model. It was a different one: “I ended up choosing to have a multi-vendor fleet specifically to get around the issues of having the same model doing multiple roles.” The reviewer isn’t a second opinion so much as an outside one: “you want to have an outside perspective, no different than you would in business or anywhere else… it thinks differently. It sees problems differently. It works differently.”

Effort is a routing dimension

Effort level is the second dial, and it moves independently of which model is running. What I actually run each stage at, against what I’d run it at with no constraint — my own statement, not a measurement.

The gap at spec is the honest one: “Fable simply thinks better, or thinks differently, than Opus, and I prefer the way that it goes. Fable on xhigh burns a lot of tokens on its thinking, and I just don’t have that kind of credit capacity, so Fable low is the best that I can do. I’d run it high if I could.” The model I prefer most runs at the lowest effort setting in the pipeline — that’s a budget line, not a verdict on the model.

Prompts are model-coupled

Opus was my workhorse before it wasn’t. I gave the swap a week or two before I settled it: “I tried to give it a week or two or a couple weeks, and I just got frustrated with it, quite frankly… that’s when I pretty much quit using Opus 5.” “Opus used to be my work horse… I can’t wait until they come up with a new Opus version.”

The part of that story that generalizes, without any of the guesswork about why quality changed: prompts are coupled to the model they were written for. “It feels like what they did with Opus 5 is that it’s designed to be a sub-agent used with Fable. And so Fable will be very chatty and give a very verbose prompt for Opus 5, and it loves it. But if I try to use my existing prompts, or anything that used to work great with Opus 4.8, it doesn’t work as well as it should with Opus 5. Again, maybe it’s subjective, that’s how I feel.” Swapping a model in a fleet like mine isn’t picking a new name off a menu. It’s a migration of the whole prompt library that fed the old one.

What stays out of the pipeline

Two models never enter the automated fleet at all, and neither exclusion is about quality.

Qwen runs locally, on an M5 MacBook with 128 GB of memory, and it’s genuinely good. Qwen3.8-27B “works actually exceedingly well… pretty reliable for a local model.” Qwen3.6-35B-A3B is “insanely fast and super capable,” though “for coding tasks, for agentic tasks, the 27B is better.”

What keeps either off the board is scale, not the model: “I don’t have a great way to scale it up; running it on my MacBook M5 128GB is not great for multi-agents to be hitting it.” “I don’t have a great hosting provider similar to Anthropic or OpenAI to be able to have something that I can hit with a dozen agents at the same time.” “Maybe if I did subscribe to one of the Qwen platforms, I might be willing to do that.”

Grok stays interactive by design. The jobs, in my own list: real-time research, my day-to-day driver on my personal MacBook, Grok voice, and Grok Imagine, which generates the engraved plates on this site “in exactly the style that I want.” Real-time research is the internet and X giving it “real-time information and feedback that none of the other models have.”

It’s not in the automated pipeline because my subscription doesn’t cover a dozen agents hitting it at once — the same capacity shape as Fable’s effort ceiling above, not a verdict on the model. By Grok 4.6, it had crossed a real threshold, going from giving up after roughly ten tool calls to holding the plot over a long agentic run. Grok 4.5/4.6 were trained with Cursor data, and that changed the model.

One rule sits underneath both exclusions: “if I were to just use OpenRouter, that’s paying with API costs, and I really prefer paying a subscription cost where I get a whole lot better ratios.” Subscription seats, not metered tokens, is why Fable runs at low instead of xhigh, why Codex joined the fleet as a subscription seat rather than a metered one, and why Qwen and Grok stay outside it for now.

Underneath

Every model fact here is the vendor’s own, not mine. Anthropic’s published lineup: Claude Fable 5 (claude-fable-5, June 9, 2026), Claude Sonnet 5 (claude-sonnet-5, June 30, 2026), and Claude Opus 5 (claude-opus-5, July 24, 2026) — see the models overview. Effort is a first-class API parameter, not a Claude Code invention: Anthropic’s own effort documentation lists five levels, low through max, with low named explicitly for subagent work and xhigh for long-horizon sessions running past thirty minutes.

The reviewer’s name is OpenAI’s own tier, not a nickname. Its naming announcement says “the number identifies a model’s generation, while Sol, Terra, and Luna identify durable capability tiers” — model id gpt-5.6-sol. Its xhigh reasoning effort is documented and current, with a further max level above it: OpenAI’s reasoning guide, and xhigh arrived with GPT-5.1-Codex-Max.

Qwen3.8-27B is a real, currently-shipping model — dense, 27B parameters, open weights on Hugging Face and documented on GitHub. What I heard in the moment as “Qwen 3.6 35B” is Qwen3.6-35B-A3B, a real, already-shipped sibling in Qwen’s own Qwen3.6-27B announcement — a sparse mixture-of-experts model, 35B parameters total, but only 3B activated per token, which is why it feels faster than its size suggests while still occupying roughly 35B worth of memory when loaded.

The conformity mechanism behind the review stage traces to Anthropic’s own multi-agent research: Patterns and problems in emerging multiagent systems is where the branch-naming example above comes from.

The Cursor line is data lineage, not editorializing. xAI’s own Grok 4.6 model card states it “received supplemental training on anonymized Cursor workflow data to improve coding and agentic performance,” and Cursor’s own Grok 4.5 announcement describes the training data as drawn from real user interactions with codebases and software tools.

Neither vendor publishes a spec, build, review, and interactive effort taxonomy — the four-way split above is my own framework, mapped onto documented effort semantics, not a vendor-endorsed routing table. The subscription tiers behind the pricing rule are sold the same way on both sides: Anthropic’s plan and OpenAI’s plans are both priced as usage multiples over a base tier, not raw token grants — exactly the ratio the rule is chasing against metered, per-token API pricing.

More field notes

Start