Let the smart model delegate
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.
Use Fable for planning and coordination. For anything you can scope into a clean subtask, start a Composer 2.5 subagent.
Give each subagent a clear goal, the relevant context, and what to bring back. Don't have them invent the plan. Run independent pieces in parallel.
When they return, review the results before you merge anything. If something's off, rewrite the brief and spin another, don't silently patch over it yourself unless it's trivial.
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.
Fable is back in Cursor. One pattern I explore, plus other ways I get most from model.
Fable as orchestrator, Composer as workers
Easy to put everything on smart model. Most of agent run is reading files, writing patches, running checks. No Fable rates needed there. Let Fable pick subtasks, order, and when result is done. Composer 2.5 does scoped pieces: cheaper, faster, parallel. Most of my chats: short Composer runs. Fable rarer, but longer.
Put routing in AGENTS.md or .cursor/rules-rule so orchestrator agent can use it.
Use Fable for planning and coordination. For anything you can scope into a clean subtask, start a Composer 2.5 subagent.
Give each subagent a clear goal, the relevant context, and what to bring back. Don't have them invent the plan. Run independent pieces in parallel.
When they return, review the results before you merge anything. If something's off, rewrite the brief and spin another, don't silently patch over it yourself unless it's trivial.
Good brief:
- one concern
- enough context, no re-exploring whole repo
- definition of done worker checks alone
- short report, orchestrator decides fast
Fable alone when judgment is work: hard design call, gnarly bug needing one coherent thread, plan that must stay coupled. Cannot name subtasks? Keep one agent!
Long horizon cloud agents
Most common use: ultra long horizon work on Cloud Agents. Long refactor, multi-surface feature with real definition of done, investigation across big codebase. Hand to Fable with something to check itself against, let it run. Check in from iOS app: status, peek at work, nudge if drifted.
Keeping up with the frontiers
Run only one model, you mistake its habits for ceiling of agents. Frontier moves every few weeks. Rotating keeps “what good looks like” current, from real work, not benchmarks.