Teknium announced a smart fix to one of the more annoying scaling bottlenecks in Hermes Agent today. The gateway’s database calls now run off the main event loop, meaning your concurrent kanban runs and multi-agent sessions don’t have to wait for a blocking SQLite write to finish before the rest of the agent keeps working.
Here is what changed and why it matters if you run Hermes in production.
The Problem: One Event Loop, Blocking Everything
Hermes Agent’s gateway runs a single asyncio event loop that serves every platform session, every watcher, and every heartbeat. That is normal for an async Python app. What was not normal was that SessionDB — the database layer — was synchronous, and its calls ran directly on that loop.
A held SQLite write lock, a checkpoint, or a slow filesystem operation could freeze the loop for the call’s full duration. That does not just slow down one session. It starves every conversation the gateway is handling at that moment and every platform heartbeat trying to keep the connection alive. It was the kind of bug you only notice under load — and then you notice it hard.
PR #54876 by contributor yoniebans identified the root cause and laid out the fix. Today, Teknium cherry-picked that work onto current main under #55159, and it is live in the latest build.
The Fix: Hermes Agent’s AsyncSessionDB Worker Thread Facade
The solution is called AsyncSessionDB. It is a generic facade that wraps every SessionDB method and offloads it via asyncio.to_thread to a worker thread. The call still takes just as long to run, but it no longer freezes everything else while it does.
The gateway’s loop-side database calls — roughly 43 call sites across run.py, slash_commands.py, and the platform base class — now all go through the async facade. The existing SessionDB internals, the single-writer model, and the serialization layer are completely unchanged. AsyncSessionDB is a seam, not a rewrite.
Proof: 1053 Milliseconds, Zero Frozen Ticks
The validation is worth calling out. Teknium tested with a real held SQLite write lock timed at 1,053 milliseconds.
Without the fix, that call froze exactly zero loop ticks. The event loop was dead for over a second. With AsyncSessionDB in place, all 105 loop ticks stayed alive during the same write. The loop continued serving sessions, handling heartbeats, and processing messages like nothing was happening.
Concurrency safety was tested too — 1,000 concurrent resource claims each produced exactly one winner, and 300 concurrent idempotent database creates each produced exactly one row. No duplicates, no race conditions.
There is also an AST guard in the test suite that fails CI if any raw non-awaited SessionDB call accidentally lands back on the event loop. Mutation testing confirmed that planting one raw call triggers the guard and names the exact offending line.
What This Means If You Run Hermes
If you are running kanban workflows with multiple agents, or any setup where the gateway handles many concurrent sessions, this fix directly removes a scaling ceiling you may not have known was there. The gateway could always handle the load on paper, but a single slow database write could cascade into visible stalls across unrelated sessions.
This does not change your deployment or your workflow. Update to the latest build and the fix is in place. Teknium’s post on X sums it up: Hermes Agent now has no problem with scaling huge multi-agent kanban runs, large concurrent sessions, and more.
The Broader Picture
This fix lands in the v0.17.0 era of Hermes Agent, which I covered in depth when it shipped with 1,475 commits and 245 contributors. The Reach release was about extending where you can run Hermes and how far its reach goes. Infrastructure fixes like this one are the quieter side of that same effort — making sure the tool works at scale, not just in single-session demos.
Those of you running multi-agent workflows should also check the Mixture of Agents 2.0 update, which lets you combine GPT, Claude, and DeepSeek in one session. AsyncSessionDB removes the DB-level bottleneck so those combined sessions stay snappy under heavy use.
Bottom Line
AsyncSessionDB is a focused, well-tested fix for a real scaling pain point. It does not rewrite the database layer or break existing workflows. It adds a worker thread seam that keeps the event loop alive during slow database calls, which is exactly the kind of infrastructure improvement you do not notice until it is gone. Now it is gone.
