Show HN: Lessons learned from running Claude Code swarms at scale
12 comments
Nice to see we all building similar things, each in our own ways, which makes them somewhat different.
That's my way to say I too built an orchestrator like this and reached into a similar flow. Personal use only but now I'm considering publishing it somehow.
That's my way to say I too built an orchestrator like this and reached into a similar flow. Personal use only but now I'm considering publishing it somehow.
do you have something I can take a look at - post or git maybe ?
This is interesting. Are you thinking that you'll eventually evolve this into a full control plane for agentic swarms?
I use it as a full control plane for a couple of weeks from cli and from UI completely over last few days. UI now allows to manage the full cycle of agents - create task, monitor task, respond to agents questions, unblock jobs, etc
Nice! Do you still use an IDE at all? Or is it purely in this view now?
Only as a viewer but I don't code in ide
- CLAUDE.md is a terrible abstraction. These files load unconditionally, they often contain descriptions irrelevant to the task at hand, and they stack from your working directory upward. The result is wasted tokens and confusion from injecting irrelevant instructions into the session.
- Skills are bad, but not as bad as CLAUDE.md. They use a progressive disclosure approach: only the skill description goes into the session, and Claude loads the full skill text with a tool when it's needed. That's one level better, but it still doesn't let you scale — you can't create 10K skills, as that would eat your entire usable context. Claude recently introduced a skills budget that silently drops less frequently used skills from the session entirely. You can still invoke them in an interactive session, but the model can't invoke them in a background session.
- Some plugins may be installed more than once. During cleanup I found that a few of mine were installed in multiple locations, consuming double the tokens on duplicated instructions.
- Attaching plugins to every session is a bad idea at scale. You want to be precise about which plugins are actually useful and attach them per task.
- Use a hierarchical knowledge base instead of CLAUDE.md / skills / plugins. It lets you benefit from real progressive disclosure: keep your instructions and tool descriptions in it and let Claude navigate through it quickly and cheaply.
- System tools consume ~15K tokens (7% of the session). You can't manage this — they're just attached, and disabling tools doesn't remove them from the context.
- AskUserQuestion isn't available in background sessions. You need to implement your own tool — MCP- or CLI-based — to give `claude -p` the ability to talk to you.
- You become selective about which model handles each task. Decompose work into harder and simpler subtasks so you can route the simpler ones to weaker, cheaper models and save tokens.
- Your context-switching skill improves over time.
Fleet repo: https://github.com/sermakarevich/fleet