Zechner batches commits, 5 to 439 agent runs per second
A durability write queue, not the model, was capping 128 parallel conversations in pi-durable.
Mario Zechner did a round of performance work on pi-durable and says 128 concurrent agent conversations went from topping out at about 5 runs per second in total to 439.
if you're running a coordinator that fans out to dozens of subagents over postgres or whatever, you don't need to shard sessions for throughput anymore
The primer he gives first explains why the number was ever that low. Every step of an agent run is saved to a database before the agent moves on, one save is one commit, and that is what makes the run durable. Crash mid run, resume from the last commit. He puts it at roughly 12 commits per run. A single pi-durable session manages many conversations in parallel, for example subagents, or one conversation per thread in a Slack channel with a shared history prefix.
The session was sending every commit to the database on its own and waiting for it. At 4ms per database round trip, every conversation queued behind every other conversation's commits. With 128 conversations running, Zechner says each run waited about 25 seconds for its turn. After the change it waits 0.28s. His chart of the before and after is log scale.
What the fix actually is
Commits that pile up while one is in flight go out together in the next one. At 128 conversations, one database call carries about 33 commits. Zechner is upfront that this is harder than it sounds, because individual commits may have read and write dependencies on each other, so batching everything indiscriminately does not work.
It is also not purely a network database effect. He reports local SQLite 18 to 58% faster, and Cloudflare Durable Objects reading 40% fewer rows and writing 13% fewer. Memory at rest is unchanged.
For working engineers
The takeaway he draws is about architecture rather than raw speed. If you are running a coordinator that fans out to dozens of subagents over Postgres or something similar, Zechner says you no longer need to shard sessions to get throughput. The remaining ceiling, in his words, is single CPU saturation, because Node, and if you hit that you still need to shard.
The broader point for anyone building fan-out agent systems is where the time was going. Nothing about the model or the tool calls changed here. The cost was per-step durability writes serializing behind each other, which is the kind of bottleneck that looks like slow agents from the outside. Note this is one person's numbers on one runtime he wrote, not a benchmark anyone else has reproduced. Zechner credits @dpetrou for kicking his butt into doing it.
Have the good opinion, not the loud one
One email a day. Under three minutes. What working engineers found out about coding with AI.