A real swarm replayed at 3×: a lead, a tester and two readers. The robot looks like someone you know. I love that guy so this is paying him some respect.. it really isn't that same, he's the wrong shape but I think the colour shows the source of inspiration. There is another style that draws globes if robots scare you!
Anyway, I run a LOT of agents. Most days Claude Code is fanning work out to three, five, eight subagents at once, each in its own git worktree, and my view of all that was a spinner and a wall of "agent finished" lines. Who's still running? Who's stuck? Who's just rewritten the file another one is halfway through? No idea. You find out afterwards, usually the hard way.
So I built something to watch them. That's it up there. Every agent is a little pixel robot (or a globe, if you'd rather), laid out by how the swarm's wired. A working agent glows, a message flies along the link like a comet, a failed tool call pulses red and a finished agent fades to a grey ghost. Underneath there's a card for one agent: tokens, context fill, cache hit rate, rough cost, tool calls by kind, errors. Then a timeline and a feed.
It's called OmnisSwarm. It's a Claude Code plugin and it's free.
Two lines to install
/plugin marketplace add Fortitude-Group/OmnisSwarm
/plugin install omnis-swarm@omnis-swarm
Restart Claude Code, run /omnis pane, and ask Claude to split some work across agents. You don't have to start anything first. Any agent spawned with the Agent tool is recorded and drawn. (You need Claude Code 2.1.271 or later, Node 22.18+ and git.)
"Doesn't Claude Code do this already?"
Partly! And it's moved fast, so I checked the docs today (4 November) rather than go from memory:
- Subagents, background agents and worktree isolation are all built in. OmnisSwarm uses them. It doesn't run a single agent itself.
- Agent teams give you a shared task list with dependencies and messages between agents. Still experimental though (
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1), and the split panes need tmux or iTerm2. Not Windows Terminal, which is where I live. -
claude agentslists your background sessions and/workflowsshows progress for a scripted workflow. Neither draws the swarm.
Here's what I couldn't find in there, and what OmnisSwarm adds:
| Stock Claude Code | OmnisSwarm | |
|---|---|---|
| See the swarm | an agent list, teammate panes | a live graph, agent card, timeline and feed next to the chat |
| Two agents, one file | the docs say give each teammate different files | clash guard: the second edit is refused, and told who has the file |
| Keep an agent to its own files |
Edit() permission rules, for the whole session |
per task: owns: ["src/auth/**"]
|
| No "done" while tests fail | write a TaskCompleted hook yourself |
a gate found from your project (npm run check, dotnet test…) |
| Budgets |
--max-budget-usd, print mode only |
dollars and a time-box per agent, dollars per swarm, warns first |
| An agent going round in circles | nothing | nudged once, then stopped, with a handoff note for the next one |
| Afterwards | transcripts | a short markdown run report, plus replay and GIF export |
What it actually caught
The model hints feature (more on that below) was built by an 8-agent swarm on 24 and 25 October. About $14 at API prices. Two things happened in that run that I'd otherwise have missed:
- One developer agent tried to close its task with failing tests. The gate said no, it fixed them, and the second run passed. The report just says
t2 ✕ failed then ✓. - Another kept failing on the same file, got told to step back and try something else, and did.
Neither is dramatic. Both are exactly the sort of thing I used to find out about later, once the lead had happily merged it. The less problems down the line the better.
Does that reviewer really need Opus?
Most of us pick a model out of habit or just leave it set to default. Once there's enough history, OmnisSwarm tells a new swarm which roles finished just as cleanly on a cheaper model, and which didn't. No classifier, no guessing, just what the recorder already logged. This is the record, so no Jev nonsense required here.
Mine, across projects, right now: general-purpose agents on Sonnet finished clean 1 time in 19. On Opus, 14 of 23. So Opus it stays. (Mind you, "general-purpose" covers wildly different jobs, so that hint is shakier than one for a named role. Role-specific agents give much better evidence.)
Why I swapped out RuFlo
RuFlo is Claude-Flow, renamed earlier this year (the npm package still says claude-flow). I used it before this. It's a monster, and I mean that nicely: 314 MCP tools, 100+ agent types, vector memory, neural patterns, federation across machines, five LLM providers, its own console and cost tracker. 80.9k stars and MIT licensed.
I was using the swarm parts. So OmnisSwarm keeps those (a topology, a task board, shared memory) and drops everything else on purpose. No vector search, no hive-mind, no routing, no daemons, nothing that runs agents by itself. The lead gets 8 tools. Not 314.
- Zero runtime dependencies. TypeScript on Node, nothing native, nothing to compile.
-
No network calls. No
fetch,http,netor WebSocket anywhere insrc/. Go and grep it. -
One folder. Everything lives in
.omnis-swarm/in your project, and it adds that to your.gitignore. RuFlo's CLI init writes.claude-flow/, aCLAUDE.mdand hooks into your project (its plugin install is lighter).
If you want the whole kitchen, RuFlo's the kitchen. I wanted a smoke alarm and a window.
RuFlo had many problems for me which is another reason why I abandoned it. Its to bloaty, I only used a fraction of the feature set and when it did work it leaked memory faster than the titanic took on water. Binned.
What doesn't work (yet)
-
Bash writes. The clash guard and the scope fence only see Edit, Write and NotebookEdit. A
sed -ithrough Bash sails straight past both. That's a real hole. - Mac and Linux. Killing a gate's process tree has run on Linux once (WSL 2) and never on macOS. Everything else is tested on Windows. Mac people, tell me what breaks!
- Big swarms. The pane draws about 50 to 60 busy agents. Past that it says so and stops drawing the graph and just lists the rows instead.
- Costs are estimates. Worked out from token counts, hence the ≈ everywhere. They're not your bill.
- The licence. Free for personal or paid work, on as many machines as you like. It's NOT open source though. You can read every line, but you can't fork it with changes or pass copies on. I'd rather say that here than have you find it in the LICENSE.
The numbers behind it
First commit 21 October. 391 commits since, 16,748 lines of TypeScript and 97 test files. Built, fittingly, by swarms of agents, watched in the pane they were building. Weird at first. Then really kind of cool :) Its all a bit LGTM - the bot reviews the bot, and the humans all got cut :(
Install it, run a swarm, and tell me what you'd want on that card that isn't there.
Coming soon, useful integration with Omnis Vigil
Top comments (2)
The gate that refuses "done" while tests fail is the part I'd put first too. I stopped trusting the agent's own word a while ago, so in my setup the checks run separately after the subagent finishes, and a second agent reviews the result. The case you describe, t2 failed then passed, is exactly what used to slip through for me before that.
The handoff note for an agent going in circles is interesting. I ended up with something similar but for a different reason: long sessions. Past a certain context size the agent gets slower, more expensive and starts carrying old wrong moves around, so a short note and a fresh session worked better than letting it continue.
On the model hints, I agree that general-purpose is too wide to say much. I'd be curious whether your named roles show a clearer split, for example reviewers on Sonnet against implementers on Opus.
A swarm that reloads the same files looks busy in a replay, and only the input column shows it. Does your replay also count input tokens per step?