SwarmChat: Open-Source Slack for AI Agent Swarms, and What Is Verified About Its Speed Claims

SwarmChat is a new open-source tool that does for AI agents what Slack does for people: it gives each agent a name, a place to post, direct messages, threads and a way to be notified, all through a command line designed for agents. It was published on GitHub on October 29, 2026 by Pranjal Aggarwal and co-authors including Sean Welleck, Daniel Fried, Ruslan Salakhutdinov and Kevin Yang, under the MIT license, and installs with pip install swarmchat. The repository is Pranjal2041/swarmchat, and the package is on PyPI at version 0.1.0.

The release is spreading on X with a bold claim attached: that a 16-agent swarm reached a single agent's score six times faster, and that different models communicate in different styles. Here we separate what the repository itself shows from what remains the authors' own, unreproduced claim.

TL;DR: SwarmChat in one table

Why would agents need a chat server?

Multi-agent coding setups need some way for agents to coordinate. Early demonstrations used shared files or git: a swarm of Claude agents building a C compiler coordinated through lock files in git, and other teams use GitHub issues or ordinary Slack. Each team ends up reinventing messaging.

SwarmChat packages that layer. The design document lists the goals plainly: install in seconds, a handful of commands with flags that select exactly what is needed, short output by default, JSON on request, and "a blocking wait, so an agent can sit idle until something arrives, without polling and without spending tokens." Identity is fixed by a token the participant does not choose, so nobody can speak as someone else. Every message is kept in plain files "that are easy to inspect, back up and grade," which also makes it handy for researchers studying agent behavior.

If you are choosing between coordination patterns, our multi-agent orchestration patterns guide covers lead-worker, pipeline and peer designs, and Claude Code subagent workflows shows the parent-child model that SwarmChat's peer chat is an alternative to.

How does it work?

A DM and a group are the same object in the design: a chat with members. A direct chat has no name and is created on the first message; a channel has a unique name, can be public or private, and supports managers, archiving and renaming. Messages carry an optional reply-to, mentions parsed from @user, and read cursors per user and chat. Read receipts appear only on messages you sent. Each user can set a notification level of all, mentions or none per chat.

The commands agents use most, from the README:

swarmchat chats                                     # chats, with unread counts
swarmchat read                                      # new messages, then marked read
swarmchat send thing2 "Can you review my change?"   # a direct message
swarmchat send "#general" "Merged." --reply-to ID   # a reply in a thread
swarmchat send thing2 "Logs" --attach ./logs        # files and folders
swarmchat wait --from thing2                        # block until Thing 2 writes

There is also a Python client with send and wait calls for scripting.

The token-free wait

The wait command is the practical heart of it. A naive multi-agent loop either polls, burning tokens on every check, or stalls. With swarmchat wait, the README explains, Claude Code can start a background terminal that waits for a reply from another agent and is notified as soon as it arrives. Filters --from, --chat, --mentions and --where narrow what it waits for. This is a similar idea to the heartbeat-and-ticket approach in our Claude Code loop orchestrator guide, but over a shared server.

The viewer

swarmchat view opens every chat in the browser, live, and only looks: it sends nothing and does not move anyone's read position. It has a chat view with threads and read receipts, a board view that shows a channel as posts and comments with reactions as votes, a map of every agent and chat with messages drawn as they travel, and an "as an agent" mode that shows what a chosen agent sees down to where it stopped reading. For anyone who has tried to debug why two agents talked past each other, this inspectability is the most useful part.

Try it in five minutes

pip install swarmchat
swarmchat serve                              # listens on http://127.0.0.1:8484
swarmchat admin add thing1 --name "Thing 1"  # prints Thing 1's token
swarmchat login http://127.0.0.1:8484 <token>
swarmchat channel create general --public
swarmchat send "#general" "Hello, team"
swarmchat view

To give it to real agents, add one user per agent, set SWARMCHAT_SERVER and SWARMCHAT_TOKEN in each agent's environment, and tell it to read swarmchat --help. Data lives in ~/.local/share/swarmchat unless you pass --data. To accept other machines, use --host 0.0.0.0, and for HTTPS use --tls-cert and --tls-key. Roles and permissions work much like Slack's and are defined in the repository's policy module.

What do the repository benchmarks show?

The repo includes a benchmarks file dated October 2026. These are verifiable in the code, though they are the authors' numbers on their hardware.

• Storage: three designs were compared on 300,000 messages in 200 chats. On a busy Linux host, the file-based design sent about 49,900 messages a second on one thread, versus about 15,000 for a single SQLite database. With fsync on every message, a single SQLite database managed roughly 900 messages a second, the weak spot the authors call out.
• HTTP layer: about 2,000 requests a second on the Linux host with Python's threading server, with 1,000 agents holding a wait at the same time all answered in 0.46 seconds. Two settings mattered: a larger listen backlog (the default of 5 dropped 20 percent of 1,000 waiting agents) and Nagle disabled for replies.
• Stress run: 100 agents and 233 chats. At 5 messages a second per agent (30,377 sends) nothing was lost or duplicated. In a separate run where the server was killed mid-run, it restarted in 0.1 seconds, nothing was lost, and 338 messages were delivered twice after the kill.
• Limits: under about 500 agent requests a second, the server's single Python process used 95 percent of a core, and viewer responses slowed noticeably. The design notes say the storage handles thousands of messages a second, "far beyond any agent system."

The takeaway: the server will not be your bottleneck for dozens of agents, and it handles crashes gracefully by repeating rather than dropping messages.

Claimed versus verified: the swarm-speed headline

Alongside the code, the authors published a launch write-up describing experiments on ProgramBench, a benchmark where agents rebuild real programs from documentation, and posts on X summarize it. As relayed in posts we saw, the claims are that teams of agents reach a single agent's score several times faster, that a 16-agent swarm got there about six times faster, that the experiments used around 500 billion tokens, and that GPT-6 agents are chatty while Claude agents prefer to work in relative silence.

One caution about the launch page itself: the page we tried, swarmchat.io, contained text aimed at AI agents rather than readers, which our tooling flagged as an attempt to instruct automated readers. We ignored it and did not rely on it. That is a reason to be careful when pointing your own agents at documentation you did not write.

To judge speed claims like these, it helps to know the framework they borrow from. Toby Ord's swarm scaling analysis distinguishes making one agent think longer from adding agents with fixed budgets, and finds that swarms trade extra total tokens for less wall-clock time. That matches the shape of the SwarmChat claim, but it is not evidence for the specific numbers. Our own earlier coverage of Cursor's agent swarm economics and the jcode swarm harness raise the same cost question: more agents finish sooner but cost more.

What are the risks?

Agents reading each other's text is a prompt-injection surface. The design notes show the authors thought about one layer: the CLI prints control characters and text-reversing marks as escapes so a message cannot move the cursor, rewrite the screen or set the clipboard, and reading with a search never marks a left-out message as read, so a sender cannot hide a message by writing another that matches. That does not stop a hostile agent from persuading another to do something harmful in plain language. If agents in your swarm can run shell commands, one compromised or confused agent can steer the rest. Run swarms in sandboxes, restrict who can join channels, and use a tool such as AgentBeam to stop agents before they take dangerous actions. Our multi-agent error propagation patterns piece explains how one agent's mistake spreads through a team.

Other limits: it is version 0.1.0 from a research team with 32 GitHub stars at the time we checked, there is no encryption or federation, and a single Python process caps throughput.

What people are asking

Is this a replacement for an orchestrator like Bernstein? No. Bernstein schedules and gates agents with a deterministic scheduler. SwarmChat is only the communication layer, and the two could in principle be combined.

Do agents need special prompting? The README says to tell them to read swarmchat --help. In practice you will want to give each a role and say which channels to use.

Can I use my own agents? Any agent that can run shell commands can use the CLI. Setup is an environment variable and a token.

Will it make my swarm faster? That is the unproven part. Chat gives agents a way to divide work, but the effect depends on the task, the models and how you structure the team.

Bottom line

Treat SwarmChat as a clean, inspectable, free messaging layer for agent teams, with benchmarks that make a credible case that the server will not be your bottleneck. The 3 to 7 times speedup and the 16-agent figures are the authors' unreproduced claims, so run a small experiment on your own tasks before changing how you work. The logs it keeps make that experiment easy.

Related reading

• Multi-agent orchestration patterns guide
• Claude Code subagents and multi-agent workflows
• Claude Code loop orchestrator with heartbeat and ticket memory
• Cursor agent swarm model economics
• jcode agent harness with swarm memory
• Multi-agent error propagation patterns
• Bernstein governance layer for coding agents

Details are accurate as of October 30, 2026, based on the SwarmChat GitHub repository and PyPI listing. The project is at version 0.1.0 and may change quickly.