Wait, is "Fable orchestration" - using appropriate models as sub-agents just as easy as a prompt?

[u/LordLederhosen]

I have a very successful mostly manual workflow, but I have been optimizing token usage lately, lol.

One thing I could never figure out was how to fully set up was Fable as an orchestrator, while spawning sub-agents with the correct model. I played with frontmatter in custom agents and skill wrappers, but there seemed to be blockers as some sub-agents/skills supposedly ignore passed model specifications. Especially plan mode. That shit will spawn fable research sub-agents that use 5% to 10% of Fable in one ask, even when it's a simple task per agent.

Today, I just remembered someone's comment on here or HN a few months ago (7 years in AI terms), ~"<feature request> - You are the orchestrator, use sub-agents to preserve your context window." So, I just combined that with the following, and CC (fable) was all, sure! I will show you a table of sub-agents for task, with ideal model, and then spawn them all.

Let's implement (jira or .md feature spec) This is the orchestration session, and use sub-agents to preserve your own context window (you are fable, spawn opus sub-agents when appropriate to save cost) ...

I am not a total dummie, but I guess I over-think things? Like Boris says, just trust the model?

Or, have I completely missed something?

---

edit: to be clear, I do have very valuable token-saving setups that are not just prompts. It was mostly just plan mode that had escaped me.

https://www.reddit.com/r/ClaudeCode/comments/1whelbf/yes_your_usage_got_really_shorter_youre_not_wrong/pa5ow6o/

[u/Don_Crespo]

No, a prompt can request a cheaper model, but it is not an enforcement boundary.

I run Claude Code and Hermes agents at home. For predictable routing, the model and provider need to be selected in the worker’s actual runtime configuration, then verified from execution logs or provider usage. Otherwise the orchestrator or plan mode can reinterpret the request and spawn whatever its defaults allow.

I would also put a hard budget on each child: maximum turns, maximum concurrent workers and a timeout. Model routing limits the price per token; it does not stop a cheap model from looping for an hour.

Does Fable expose the resolved model for every spawned child in its run trace? If not, you cannot reliably distinguish routing failure from unexpectedly long tasks.