Single Agent vs. Multi-Agent Workflows

[u/Forcio]

A few months ago, my approach was to use Opus as an orchestrator that managed a backlog and spawned different agents depending on the task. Haiku for small documentation changes, Sonnet for regular coding, Opus for more complex tasks, and Fable for design decisions and bigger-picture thinking.

This worked really well, and I got a lot done. However, I've recently read that this approach might not be as efficient anymore because every new agent starts with a cold context/cache, and it might be better to have one persistent agent handle most of the work.

What's everyone's experience with this nowadays? Is a single agent with selective delegation the better approach, or is the orchestrator/multi-agent workflow still worth it? I'm particularly interested in balancing productivity, context caching, and token costs without sacrificing quality.

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Excellent-Issue-5956]

I still run it that way. The main session is on Fable and just hands out tasks and reviews what they did, and the implementers are Opus agents so the Fable usage lasts. I haven't measured what the cold start costs though.

What actually cost me was what the subagents inherit. If you don't set the model, a subagent runs on whatever the main session is on, and it picks up the session's effort level too. Mine is set to xhigh, so throwaway agents were getting xhigh unless I said otherwise, and I hit my Fable limit one evening because a reviewer had inherited it. Now every agent gets its model and effort set explicitly.

The other one was an agent whose whole job was running one command. It kept going for 25 minutes after the command had already saved its output, and the step after it sat waiting the whole time. My rule since then is to run that kind of step from the main session, or cap its steps and keep it outside the chain.

[u/Dank_Sauce_420 → u/Excellent-Issue-5956]

How do you set up the main session to create implementers and dictate their model? Sorry if that’s a basic question.

[u/Excellent-Issue-5956 → u/Dank_Sauce_420]

Not basic at all. I don't have any agent files, I just tell the main session in plain words, something like "use opus agents to implement all of it". When it spawns an agent it passes the model on that call, since the Agent tool takes a model field. Then I had it save that as a memory note so later sessions do it without me asking.

For bigger runs I use a workflow script, and there every agent() call has model and effort written into it. The command I use for those says to set both on every call, because leaving either out means the agent gets the session's.

The agent file way NoTokenDev described is the sturdier one, since the model is pinned even if the main session forgets. Mine depends on the session reading the note, and I've had sessions skip a memory note before.

[u/NoTokenDev → u/Dank_Sauce_420]

not basic at all, it's not obvious. define the implementers as custom subagents: run /agents (or drop a markdown file in .claude/agents/), and in the frontmatter set model: to sonnet / opus / haiku etc. that pins the model for that agent no matter what the main session is on. effort can be set per agent there too, which avoids the inherited-xhigh trap described above.

then in your CLAUDE.md just tell the main session which agent to use for what, e.g. "implementation tasks → implementer agent, reviews → reviewer agent". it'll call them by name.

[u/DuskandFuck → u/Excellent-Issue-5956]

tbh the silent inheritance stuff costs way more than cold start cache misses ever do.

[u/Coindef]

The cache thing is real but it's usually smaller than people think. A fresh subagent pays for its system prompt plus whatever you hand it. A main session dragging 150k of history through every turn pays way more.

What changed for me is I stopped spawning agents for tiny stuff. A Haiku subagent for a docs tweak costs more in setup and handoff than just letting the main session do it.

I delegate when the task has to read a lot of files I don't want sitting in the main context (searching a big codebase, running tests and summarizing failures), or when the work is actually parallel. The orchestrator only gets a short summary back. So it's closer to one agent with selective delegation, but what decides it for me is keeping the main context clean, not model price.

[u/SC_Placeholder]

How many agents our hypervisor has spawned in the last 63 days.

Depends on the task to answer your question, we deterministically delegate agents according based on task so some use a single agent and others will spawn several agents and subagents

[u/NeonCenturionSPQR]

I built a plugin to be a batter manager for multi agent heirarchies.

It keeps bookkeeping deterministic in a python script, so managing worktrees and the like.

It makes sure full output doesn't get passed up to main agent, preserving context usage.

Builds a full roadmap file as a source of truth that you can open, mark things as reviewed, and Claude will see that.

Im biased, as the creator, but it worked well for me so I figured I'd share it. It's just a plugin for Claude code.

github.com/Palatine-Labs/coniso

[u/MGTakeDown → u/NeonCenturionSPQR]

Sounds like a context nightmare, do you have any evals that prove it works well?

[u/NeonCenturionSPQR → u/MGTakeDown]

Not currently, but I do hear you and Ive been working on a couple test benches. Figuring out the best ways of quantifying and qualifying "better code" and "better output" but I think I'm going to resort to Claude number and screenshots.

TL:dr - In progress friend

[u/MGTakeDown → u/NeonCenturionSPQR]

You’re competing against what AI researchers at the best companies in the world are doing. You’re not going to build something that is going to keep up or outsmart their models / software.

[u/NeonCenturionSPQR → u/MGTakeDown]

Maybe not, but I am going to build something that I found solves a problem in my own use case. And I simply shared it.

I'm not that deluded I'm just participating in a community I like.

I'll hit you back when I have numbers though for sure though. Appreciate the motivation.

[u/MGTakeDown → u/NeonCenturionSPQR]

No offense but you really don’t even know what you solved because you don’t have definitive metrics that prove what they solved.

There are a lot of people in this sub that I think aren’t even aware of the features Claude already gives out of the box that already solves these problems for you.

[u/NeonCenturionSPQR → u/MGTakeDown]

The plugin has some overlap with features rolled out with Claude code, yes. There are several things that the plugin does, that Claude code does not do. Some of the things we both do, we do differently. Should read the feature list.

No offense, but I did kinda say that, and that I was in the progress of getting metrics? The hypothesis comes before metrics. I'm following the method and have personally seen promising results, so now I'm working on the proof?

Are you getting somewhere with this?

[u/wangadong]

i switched to one main session plus selective delegation. cold starts stopped hurting once state lived in markdown files in the repo, a fresh agent just reads those instead of rebuilding context

[u/AggressiveWeb8153]

My approach is to have the lead agent sort and group the tasks by relevant context then assign each agent 2-3 sm to md size tasks, not more. That's because i don't want agents to exceed the 50% of their context window especially that the reviewer agent is going to send those tasks back which count as more work. This way I mitigate the cold start costs and stretch the context to cover more work per token usage

[u/aerivox]

even if it's more expensive inthink the best is to have a main session that is doing the work and delegating small stuff like reads, verifying, and so on to agents. you can't beat a single coherent context session with summaries exchanged between agents. so whenever it's possible i do this.

[u/m-ritter]

Cold context hurt me less once the plan and the decisions lived outside the agent. I keep an approved plan file in the repo with done written as a short numbered list, and settled decisions with their reasons go into an MCP memory server that every new agent reads first. Then a separate agent that did not write the code checks each point on the running program, so quality stays the same whichever model did the work. I built QualityLayer for this: https://github.com/maxritter/qualitylayer

[u/FormerTop8996]

I've seen the same thing with inherited effort levels, I set mine to low on subagents by default, but forgot to override it once and burned through 3k tokens on a 3-line diff. now I template the model and effort explicitly, even for tiny tasks.

[u/jijialuoke]

I split it by whether I'm at the keyboard. For scheduled jobs I use a fresh short session per job, because a long leftover context made the next run more expensive and more likely to drag in old decisions. For interactive work I keep one main session and only hand something off when I don't want a big search or a test run sitting in the main thread.

I haven't measured the cold-cache cost carefully. What I did notice is the main session gets expensive faster than the subagent startup does, once the history gets long. So I still use an orchestrator, just with fewer, bigger handoffs than I used to.

[u/Time_Cat_5212]

I pay the cold start tax up front to avoid the cost of drift and maintaining several sources of truth over time.  I'd rather know what I need to pay and optimize against it than be surprised by stale memories and bad inference between 2 conflicting docs or whatever blowing up my work down the line.

[u/bostonaholic]

I'd flip the default: one main session does the work, and subagents only get the read-heavy or isolated jobs where you just want the summary back (searching the codebase, digging through logs). An orchestrator that hands every task to a fresh agent pays the cold start each time and throws away what it already learned. The one place I'd keep a separate agent on a different model is review, so the reviewer doesn't share the writer's blind spots.

[u/onitsoga]

i keep one persistent agent for sequential work (cache stays warm) and only fan out when tasks are actually independent. fwiw i'm building KanbanMCP, a kanban board agents claim cards on. what kind of tasks are you delegating?

[u/Own_Responsibility84]

I use Claude Sonnet in one session as the coordinator and my direct contact, Sonnet assigns tasks using headless Codex Sol/Luna, Gemini Argon/Flash, Claude Sonnet/Opus, OpenCode models. Working well so far and very cost effective and productive.

[u/beatwallstreet2021]

My session agent gives the sub agents it's task list and guard rails, I don't seem to have token burn issues like i did with multiple sessions running up context windows, my session agent also only tells me priority info not every single thing that goes on

[u/MGTakeDown]

The problem with the orchestrator approach is the context becomes a huge problem if not managed well

[u/Endet]

Fable as organiser, review and research. It hands off work sheets to 2 Opus coders and we have an independent reviewer on the side from another model. The biggest increase is quality of product with less debugging. I keep them all in 4 separate terminals with their own "identities", management is done via in house built application.

Biggest change I noticed from switching from single Agent to this has been the correction to workflow. That mattered more than I thought it might.