http://x.com/i/article/2072636402521583616

Fable is back, here's how I use it in Cursor

Fable is back in Cursor, and here's a pattern I've been exploring and some other ways I've been getting the most out of the model.

Fable as orchestrator, Composer as workers

It's easy to put everything on a smart model. Most of an agent run is reading files, writing patches, and running checks, and you don't need Fable rates for that. Instead, let Fable decide the subtasks, the order, and whether the result is done. Composer 2.5 does the scoped pieces, cheaper and faster, and can run them in parallel. Most of my chats are short Composer runs. Fable shows up less often, but those runs go longer.

You can put the routing in AGENTS.md or a .cursor/rules-rule so the orchestrator agent can use it.

A good brief has:

• one concern

• enough context that the worker doesn't re-explore the whole repo

• a definition of done it can check on its own

• a short report so the orchestrator can decide quickly

Fable alone still makes sense when the judgment is the work, whether that's a hard design call, a gnarly bug that needs one coherent thread, or a plan that has to stay coupled. If you can't name the subtasks, keep it one agent!

Long horizon cloud agents

The use case I reach for most is ultra long horizon work on Cloud Agents. A long refactor, a multi-surface feature with a real definition of done, an investigation across a big codebase. I hand it to Fable, give it something it can check itself against, and let it run. I check in from the iOS app for status, a look at what it's doing, a nudge if it's drifted.

Keeping up with the frontiers

If you only ever run one model, you start mistaking its habits for the ceiling of what agents can do. The frontier also moves every few weeks. Rotating is how I keep "what good looks like" current, from real work rather than benchmarks.