On this page
I Really Want 13 Subagents to Chat for Me
I really want to dispatch 13 subagents to chat for me, saving the human main agent’s context window.
It’s a joke, but the joke already contains the whole problem. The moment you send subagents out, it feels like the work has been handed off. Except all 13 threads have to converge somewhere, and that somewhere is me.
One Person Running 1000
One person single-handedly running 1000 subagents; everyone, let’s start writing HTML instead of markdown for docs.
Same absurdity, multiplied. Thirteen was already more than I could collect; 1000 just blows “more than I can collect” up to a scale you can actually see.
Face to Face, No Talking
I want a social agentic AI club: face to face, no talking, my Claude Code argues with your Codex, mutually code-reviewing each other into shreds. Cover charge required.
Third variation. The first two send agents outward; this one gathers the humans and lets the agents attack each other in between. Two people sitting together, neither one opening their mouth, two machines on the table going at it. And I still want to charge for tickets.
The Bottleneck Isn’t the Model
These are three drawings of the same thing. Thirteen agents, 1000 agents, both sides’ agents at one table. The shared assumption is that more agents means faster. But every agent you add generates more things I have to rule on. You can spin up models forever. My context window doesn’t work that way, and the number of calls I can make in an hour works that way even less.
This is a different problem from burning through quota. That time it was subagents breeding recursively, some of them grandfathers by then, and what burned was money. This time what burns is me.
The Multi-Agent Empire: Can You Actually Afford It?
Interesting thread on Reddit recently. An Anthropic engineer named Daisy showed off her setup and got hit with the “out of touch, let them eat tokens” treatment.
Her claim: 30 to 50 prompts is enough to keep dozens of agents working autonomously across 8 to 10 projects. The real question isn’t whether you can start them. It’s whether you can trust them, track them, and carry the cost.
The architecture has three tiers. Two lead agents watch each other, and if one fails the other restarts it. Below them, 8 to 10 project leads, each holding one project’s goal and progress. Below that, 5 to 10 IC agents per project doing the actual work, running on their own for two or three days. The agents talk to each other directly through SendMessage.
Here’s the widest gap: a demo is not something you can reproduce. Internally it’s dozens of agents in parallel, running autonomously for long stretches, recovering each other after failure. For a regular user it’s a subscription quota, token burn that scales with parallelism, and paying a second time whenever something has to be redone. The main complaint in the comments was exactly that: no public cost, no reproducible evidence.
The real problem isn’t starting more agents. It’s keeping them from being wrong together. State: who did what, where things stand now. Verification: who can independently catch another agent’s mistakes. Recovery: how you restart after a failure without repeating it. Cost: whether the tokens, the rework and the human review are worth it. Without those four layers, parallelism just scales up the mess.
The version you can actually copy is: shrink the governance first, then add agents. The main thread only handles goals and sign-off. Each agent owns one clearly bounded scope. Action logs and handoffs get written every time. Critical facts get checked back against a live source. Failures have to fail loudly. Shrink the parallel scope and you can finally see the cost, the error rate, and the real throughput.
So the conclusion is the same one: more agents doesn’t mean more output. Ask three things first. Is the state traceable? Are errors independently verified? Do failures get reported loudly? Answer those and you’ve earned the right to scale. Can’t answer them, and all you’re scaling is token cost and the speed of your mistakes. What’s worth copying isn’t the dozens of agents. It’s one workflow you can trust.
Dedupe and Resolve Conflicts First, Then Send In the Agent Team
The order that actually works: feed in the material first, split it into chunks, run semantic vector comparison to dedupe and surface conflicts (I make the calls). Then hand the cleaned-up material to an agent team — agents that can talk to each other — to argue about structure and ordering, and I do the final pass myself.
The first half is the point. Deduping and conflict resolution happen before dispatch, and that step drives down how much is left for me to rule on. Only then does the agent team mean anything. Flip the order, dispatch a pile of agents first and then go back and deal with the duplicates and contradictions each one dragged home, and you land in the three fantasies above.
The calls stay with me, twice: once in the middle, once at the end. That part doesn’t outsource.
Fable 5.1 Burned a 5-Hour Quota in One Minute
Saw this post first thing in the morning and couldn’t stop laughing. Fable 5.1 had just come out, and someone ran Ultracode with it. It dispatched roughly 300 subagents in one go, and every single one inherited the main agent’s model (meaning all 300 were Fable). The 5-hour quota was gone in one minute, and the weekly quota immediately dropped to 43%.
If you’ve run into this too, the original thread has people sharing fixes — mainly changing the config, adding a hook, and editing the frontmatter. https://www.reddit.com/r/ClaudeAI/comments/1w52pbu/gone_in_60_seconds/