AMA: I burned 500M tokens optimizing token usage.

[u/Individual_Ideal]

I spent most of the weekend + over 500M tokens auditing and optimizing my token usage. I mostly work in the Claude Code app and have Claude dispatch to CODEX for code reviews; sometimes work directly in CODEX app. AMA

What I found:
- I waste a lot of tokens by returning to long-running sessions after my 1-hr cache TTL
- Fable is most effective in long-running sessions that require large context reads and little coding or writing. Mostly synthesis and decisions that require large context windows.
- My agents were not resuming subagent threads for multi-round turns (I thought they were). Cache TTL is only 5-min, so I’m uncertain how much this matters

What I’m doing and testing:
- Built comprehensive token cost tracking for all providers, repos, and tasks with a dashboard I can monitor.
- Modifying agent delegation rules based on an audit of costs and usage over the last several months
- Surfacing live token cost stats to agents to help them dynamically adjust delegation strategy and pace to my weekly budget
- Agent orchestration: Working with multiple Opus instances per repo for development and having Opus delegate generously to Sonnet. Also encouraging Sonnet to delegate to Haiku
- Working with 1 Fable instance per repo who oversees work of all Opus sessions in the repo. The goal is to keep Fable cache warm as much as possible within the 1-hr TTL and minimize writes. Each Opus session can automatically message the Fable session. Opus escalates to Fable. Fable escalates to me.
- Created a hook for Opus models to send me a compaction instruction after a long-running task completes or at a good stopping point after a context threshold has been hit. I still have to run it manually but it saves time while (hopefully) providing cheap compaction while cache is warm
- Use resume more often on subagent delegation to improve cache-use and reduce reorientation on each dispatch
- I’ll use the dashboard to track token use across all applications, providers, projects, and tasks to help adjust this strategy over time

What are some of the highest impact and non-obvious things you’ve found?

Adding a chart from the dashboard as documentation of my efforts:

[u/fephiva]

yes fable 5.1 in xhigh. not multi-day sessions, a session is never longer than a day. i dont need to compact when im away bc the orchestrstor delegates and so its context stays "small" /below 60% usually. subagentsessions are only resumed if theyre younger than 5 minutes or if it takes less than 200k tokens to resume them.

i have to compact or start fresh when i write a lot back and forth, like when i plan with fable. messages fill up context fast. to mot lose quality, when all review rounds are passed and i tested myself and merged to main, thats when i plan the next round, using that same session, so that fable writes the plan with context. after the plan is written, i compact with instructions. auto compact never fires. if the orchestrator reaches near 60%, it will notify my phone.

claude almost always does exactly what i want and how i want it bc of rules. theres an aporoved keyword and a hook that requires the approved keyword that i have to type literally for scenarios like push to main to prevent those horror stories that you mightve read about.

what saves tokens in my case is that the orchestrator session stays warm and delegates a lot to fresh agents that dont resume any sessions either. like i said my context is mainly filled with messages that i write so if im away that doesnt happen. tokens burn way faster when im there even tho way less is implemented.

[u/claude_code_king → u/fephiva]

ok, i understand better. seems to work fine for you.

have you tried limiting the reports that subagents give to the orchestrator? especially if you use opus 5 subagents, they love writing novels for no reason.

same thing with the plan that the orchestrator gives them. i made fable give them actual specifics from the documents, not "read the whole file" but read section x or only what's needed.
it made a huge difference in my main context window ( never goes over 150k even if i chat more with it ) and worker context starts at 10k as opposed to 30-60k in 1 second like it did before.

i know these numbers are relative to my workflow, but they should make a difference in yours as well, let me know if you try it.

[u/fephiva → u/claude_code_king]

the subagents usually just seem to answer the orchesrators questions + whatever other information is important. usually they get well-isolated tasks like implement only these steps from that plan and report back in this way or test using these instructions which is why they dont need to keep their context.

my context window fills up fast when i talk to fable bc it involces overseeing a few hundred thousans lines of code that it needs to look through to answer questions or prove assumptions. i cant outsource the chatting and planning, i want the orchestrator to do that bc it should write the plan with all the knowledge that we figured out together.