I Maxed Out Fable 5 and Regretted It. Here’s How I Actually Run It Now

A working playbook: effort by task, model routing, agentic runs, and vibe coding without the surprise bill.

The first day I had Fable 5, I did the obvious thing. I turned the reasoning effort to max and let it rip.

If the model is this smart, give it room to think. That was my logic. The bill scared me and the code came out worse. It rewrote files I never asked it to touch, added abstractions nobody needed, and turned a two line fix into a refactor with opinions.

So I spent the next couple of weeks figuring out how to actually drive it. Not the marketing version. The version where you use it every day, on real work, and want the output to be good without the cost getting stupid.

This is that playbook. Effort settings, model routing, how I hand it big autonomous jobs, and how it changes vibe coding. Steal what is useful.

---

The one setting that quietly controls your bill

Fable 5 lets you choose how hard it thinks, through low, medium, high, and the heavier tiers above (xhigh and max). The effort setting is the single biggest lever you have, and most people move it the wrong way.

Here is what it actually does. It does not decide how long the model can work or how hard a problem it can crack. It decides how much it thinks per step. Push it past high, into xhigh or max, and it does not take more steps. It overthinks every single one. Most steps in real work are boring. They do not need a philosophy degree.

The cost of that is worse than it looks, because reasoning compounds. Every thinking token the model spends on step one becomes part of the history it re-reads on step two, and step three, and every step after. On a long agentic run, a fat reasoning habit does not add cost in a straight line. It multiplies. This is the same trap I fell into before I took token waste seriously, and it is why cutting reasoning is the single best move you can make.

Now the honest part. On the hardest coding benchmarks, more effort does score higher, from around 11% at low to 31% at max. But your day is not the hardest benchmark problem. It is a hundred small edits. And on Cognition’s FrontierCode test, which checks whether a model can pass hard tasks while holding the bar of a real production codebase, Fable scores highest of any frontier model even at medium effort. You do not need to redline it to get its best work.

So here is the rule I actually use:

Quick tell: if a small ask comes back with a big diff full of changes you did not request, your effort is too high for that task. Drop it a notch.

---

---

Don’t pay genius rates for grunt work

The second habit that dropped my costs the most: I stopped using the smartest model for everything.

Fable is expensive, and it should be. So I let it do the thing only it does well, which is judgment. Architecture, taste, API design, the “is this the right shape” calls, the final review. The grunt work goes somewhere cheaper. This is the grown-up version of the day I swapped my main agent from Opus down to Haiku and it got better. Think of it as casting a role for each job.

The trick is making this automatic so you are not hand-picking a model every time. I put the routing rules straight into my agent’s instructions, so the smart model reads them and delegates on its own. This is one more reason I keep my CLAUDE.md tight and specific. Here is roughly what lives in mine:

## Model routing
Default: high effort. Never max for routine work.
- Judgment, architecture, taste, review  -> best model.
- Bulk mechanical work, log digging, huge files, migrations -> cheaper model.

Rule: judge the output. Price is a tiebreaker. If a cheap model misses
the bar, redo it with a smarter one without asking. Escalating beats
shipping mediocre.

When a task needs a big, specific pile of context, spin a subagent for it
and hand back a result. Do not drag all of it into the main thread.

That last line matters more than it looks. Routing heavy context to a subagent is about quality as much as cost. An agent buried in its own accumulated context gets measurably worse, which I dug into in how to break your AI agent. A cheap subagent reading a giant log and handing back three lines keeps your main thread sharp and cheap. That same discipline is what got my agent to where it costs about 400 dollars a month and nearly pays for itself. If you want to go deeper on running agents lean, I put together an Agent Efficiency Kit.

---

Handing it a big job (agentic runs)

This is where Fable earns its keep, and where the effort and routing habits pay off, because a long run magnifies every bad token.

The shift in my head was this. Stop sending one prompt and babysitting it. Give it a goal with pass conditions and let it work. The model is now good enough to break a big job into pieces, spawn help for the parts that need it, and keep going until the conditions are met. My job moved from typing to defining the goal and guarding the one thing that cannot be undone.

Two tools do the heavy lifting, and they are different. Subagents are for fan-out reads, five files to analyze, five subagents. Workflows are for staged work where a later step depends on an earlier one, like review then verify then merge. Here is a real prompt I used to clean up a pile of stale pull requests:

Investigate every open PR in this repo. Use a workflow that spins up one
reviewer per PR, then a second pass with two judges to stress-test each
verdict. Give me a triage list: ready to merge, needs a small rebase,
already trumped by other work, or good idea but better rewritten.
Link each PR. Do not merge anything yet.

It came back with a clean triage in a few minutes. Once I agreed with the plan, I turned it into a goal:

Goal: work through todo.md top to bottom. For each item, implement it on a
fresh branch, run the checks, open a PR, and merge to staging only after the
automated reviewers pass. Mark the item done in todo.md and commit as you go.
Never touch production. Keep going until every item is done.

Then it ran for hours while I did other things, the way my agent runs its night shifts, and a backlog that had been stuck for weeks landed in a couple of days.

Although I gave it a lot of freedom, one line in that prompt stays non-negotiable: never touch production. The agent can do anything reversible. It can branch, merge to staging, and rewrite whatever it wants. The one step that is hard to undo stays with a human. That boundary is the whole reason you can hand it this much rope. I have handed agents plenty of rope before, and the rope is only safe because it ends somewhere. If you are choosing the tool you leave running unattended, I compared a bunch of them in this harness roundup.

---

Vibe coding: restraint when you’re not reading every line

Vibe coding is the case where this matters most, because the whole point is that you are not reading the diff. You describe what you want, the model builds it, you check the result. That only works if the model stays disciplined, and max effort is the opposite of disciplined.

Four things that make vibe coding with Fable actually hold up:

1. Keep it on high, keep the asks small. Max over-edits, and when you are not reading the code you cannot catch the bloat. A model that changes ten files when you asked for one is dangerous precisely because it looks like progress. Smaller asks give you smaller diffs you can actually reason about.

2. Get a second model to review before you accept. This is the cheapest insurance there is. Have a different, cheaper model read the change and tell you what it does and what looks risky. A second set of eyes you did not have to write, for pennies.

3. Use branches and worktrees so a bad run cannot wreck your main. Risky change goes on its own branch. If it goes sideways, you throw the branch away and nothing else is touched. If you are new to this, I wrote a basics guide to git for AI builders for exactly this reason.

4. Watch the clock, it tells you about your codebase. This one surprised me. How long the model takes to do a thing is a signal:

One more, and it is not optional: vibe-coded apps leak. Fast-built projects ship exposed keys and broken auth all the time, which I learned the hard way and wrote up in this security reality check. Before anything you vibe-coded goes near real users, spend a cheap model on a security pass. It is the best few cents you will spend.

---

Why all of this compounds

There is an old joke among developers, the grug brained developer. Grug not smart, but grug program many year and learn things. Grug’s rule: why use many words when few word do trick.

It reads dumb on purpose, and that is the point. Fable was built for that idea. Anthropic does not sell it as the model that thinks the longest. They sell it as more capable work in fewer turns, runs that finish 25 to 30 percent faster than the last model with less back and forth. Crank it to max and route everything through the priciest model, and you are fighting the grain of the wood.

Here is the part that still surprises me. Holding the model back made me more ambitious, not less. Because a run is cheaper and cleaner, I hand it bigger jobs, leave it running longer, and trust it with more. The restraint is what buys the reach.

The models are good enough now that the ceiling stopped being their intelligence. It is our discipline in using them. The way to get the most out of the smartest tool on my machine turned out to be asking it for less.

---

I write about building with AI agents from a practitioner’s seat, no hype and no affiliate links. If that is useful, subscribe for the weekly dispatch.