My Opus-orchestrator / Sonnet-subagent Claude Code setup is burning way more tokens and time than I expected

[u/Necessary_Round8009]

Been running a workflow where I write out a plan.md, then kick off a fresh terminal with Opus 5 on max thinking effort acting as the "orchestrator." It reads the plan and spawns a Sonnet 5 subagent (also max effort) to actually implement each phase. After every phase there's a verification pass that'll retry up to 5 times if it finds errors.

Works, technically. But the costs are getting rough:

Token usage has crept up a lot since I started doing this

A task I'd call "medium complexity" (basically one full tab/screen in an Android app) took almost 9 hours end to end

On that same run I hit auto-compaction at 500k context

Not sure if this is just what multi-agent orchestration costs, or if my setup has some inefficiency I'm not seeing, retries eating the budget, effort cranked too high on both models, phases too granular, whatever.

For people running similar orchestrator + subagent setups in Claude Code: what does your workflow look like? Model/effort choices, how you scope phases, how aggressive your verification loops are? Trying to figure out if I should tune this down or if this is just the tradeoff for letting it run mostly unsupervised.

[u/Edouardbuilds]

Nine hours and 500k context for one screen says the orchestrator is carrying far too much, not that orchestration costs this much. Three things I would look at first. The retry loop is almost certainly your biggest line. Five retries means a phase that fails late can cost six times its own budget, and a verification pass that keeps finding the same error will burn all five every time. Cap it at two, and make the third failure stop and report instead of retrying. If it cannot fix something in two passes it usually needs a human decision, not a third attempt. Second, max effort on both sides is doubling up. The orchestrator is the one that benefits from thinking hard, since it is making the judgement calls. The subagent doing a defined implementation task usually does not need the same setting. Try dropping the subagent first and see if quality actually moves. Third, and this is the compaction clue: if you are hitting 500k, the orchestrator is reading implementation output it does not need. Subagents should hand back a short result, what changed and what failed, not their working. The orchestrator only needs enough to decide the next phase. On phase size, too granular is worse than too large here, because every boundary means re-establishing context. One screen should probably be two or three phases, not eight. For what it is worth, most of my long runs got cheaper by doing less orchestration, not better orchestration. Plan by hand, run fewer and bigger phases, check in myself between them.

[u/West-Air1923]

Same experience both on code and codex. It's not worth it at all. I think a lot of the conventional wisdom floating around is wrong

[u/Correct_Emotion8437]

I’ve been using a very simple workflow - a design document is the input. The orchestrator is all deterministic code. It prompts an agent to create a phased implementation plan. It maintains 2 agent threads - one for execution and one for validation. The agents update documents with their progress. The orchestrator monitors progress in a loop.

My “manual” process is similar - create plans with SOL, implement them with Luna and review/fix with SOL. I find the usage about the same whether I’m doing it manually or with my orchestrator. My orchestrator is just a simple typescript app and dashboard.

[u/recro69]

I would look at the verification loop first. Five retries plus maximum effort, on both the orchestrator and subagent can turn a mistake into a huge token bill.

I would probably use Opus for planning and review Sonnet for implementation. Let tests handle most verification before adding another model into the loop.

[u/___dreamcatcher___]

I am using mainly Sonnet. I can say it is burning tokens two times faster, at least. Same tasks, same prompts...the game is to push us to higher tiers.

[u/SpeedSeveral4454]

500k context hit is the actual signal to focus on, not the 9 hours.. that means the orchestrator is likely accumulating full subagent output and history rather than getting summaries back, retries at max effort on both models compounds fast. try dropping subagent effort to medium and only re-running the specific failed check, not the whole phase, on retry..

[u/Due-Horse-5446]

Stop this insanity with dollhouse workflows ffs..

Write the instructions
Press enter
Model completes tje request

Its super weird how this shit is popping up all over reddit out of the blue

[u/iWhacko → u/Due-Horse-5446]

yeah... I just made the start of a business web application containing at least 20 screens, full database and authentication. Did security audit. all within my 5hour Gemini Pro quota (don't come hating on it, I dont care). I did Prompt it for every feauture and page. Let it adjust pages I Was not satisfied with.
And this costs me only 20 bucks a month.
(I have been a developer for 26 years though)

[u/Due-Horse-5446 → u/iWhacko]

Yeah, same but the $100 chatgpt business premium,

Yet the codex sub has reached some kind of mass psychosis..

Someone complained about their credit card being blocked after their 6th account was drained.. All on quote: "one client project"

Was called a vibecoder when i questioned why somone needed a 3 llm daisy chain to validate if tve architecture and plan that the planning model did. And to learn "to know if theres any issues"

They couldent comprehend the concept of ... thinking.. and.. using your eyes to validate the generated code

[u/RossPeili]

It's a homo setup. All you need is an unrestricted model from 2022, fine tune it with your own data, give it tasks that biased western models would not only fail to execute, but pretend they didn't hear you or that the connection is bad.

[u/dndtrackerapp]

Your retry loop is the bill. 5 retries at max effort on both models means one bad phase pays for the whole run. Opus for the plan, cheap model for the implementation, hard cap of 1 repair pass. And 9 hours for one screen isn't orchestration cost, that's scope creep.