waitbus
A workstation-local event bus: your AI coding agents wait on events instead of polling — and hear each other fail.
Transcript
Your Claude Code and your Cursor can't hear each other — even side by side on the same machine. So they wait the wasteful way: polling, eighty times, learning nothing. waitbus replaces all of it with one call that sleeps until the event lands.
Whatever you're waiting on — GitHub, your tests, Docker, a file, or your own plugin, which waitbus makes easy to write, for Slack, Jenkins, anything — waitbus collapses them all into a single wait.
And because every tool on the box shares one local bus, when one agent fails, every other tool hears it the instant it happens — even across vendors. Each one runs its own handler. waitbus just delivers the event.
A local nervous system for your coding agents. Try it in one command: uvx waitbus demo.
- 01
- 02
How waitbus works: from event source to a waiting agent, over MCP
The architecture end to end — how an event gets from a source to a waiting agent in single-digit milliseconds, how an agent actually talks to the bus over MCP, and the decisions behind the build with what each one cost. - 03
The numbers and the trust trail: benchmarking waitbus honestly
Two kinds of trust in one place — the benchmark methodology that makes the speed numbers survive a skeptic (Coordinated Omission, a bimodal p99, costs published as losses), and the supply-chain trail that lets you trust the artifact you install (SLSA provenance, sigstore, reproducible builds, and an honest list of the gaps). - 04
The first file an agent reads
Coding agents read your library before they use it, and they start with the code — `__init__.py`, the type hints, the tool schemas — not your docs site. Here is how I made waitbus speak to that reader, and the one piece of documentation I deliberately did not ship.