Swapping an Agent's API Layer for a tmux and CLI Engine
A private fork of the Hermes agent that drives models through tmux and CLI subscriptions instead of pay-per-token APIs, keeping the learning loop intact.
Hermes, the self-improving agent from Nous Research, does something I care about: it runs a closed learning loop. It creates skills from experience, improves them during use, searches its own past conversations, and builds a model of who it is talking to across sessions. The catch, for me, was the provider layer. Out of the box it expects a model endpoint you pay for per token. My fork replaces that layer with a tmux plus CLI engine.
Why Rip Out the Provider Layer
I already run a fleet of CLI coding tools on subscriptions: claude, codex, gemini. Those are flat-rate seats, not metered APIs. An agent that loops on itself, curates memory, and reruns skills is exactly the kind of workload that generates a lot of tokens, and metering that against a per-token API gets expensive fast. Driving the same work through CLI sessions I already pay for turns a variable cost into a fixed one.
The design goal was to keep everything Hermes does well and change only how it talks to a model. The upstream agent is built around model portability already, with a hermes model switch and no code changes to move between providers. My change extends that idea one step further: the "provider" becomes a terminal multiplexer holding live CLI sessions, and the agent talks to those instead of to an HTTP endpoint.
What Stays and What Changes
The parts worth preserving are the ones that make Hermes more than a chat wrapper. The agent-curated memory with periodic nudges, the autonomous skill creation after complex tasks, the FTS5 session search with summarization for cross-session recall, all of that sits above the provider layer and comes through untouched. So does the multi-platform gateway, which lets a single process answer from Telegram, Discord, Slack, and the CLI at once.
What changes is the substrate underneath. Instead of a request going out to a token-metered API, it goes to a tmux pane running a CLI engine on a subscription. The upstream MIT license is preserved, which is the part that makes this fork legitimate to keep and build on.
The Takeaway
The reusable idea here is that an agent's intelligence and its billing model are separable concerns. Hermes was already designed so the model backend could be swapped, and that clean seam is what let me substitute a tmux and CLI engine for an API without touching the learning loop. When a project draws that line clearly, you can retarget its most expensive dependency, and the interesting behavior survives the swap.
Have something that needs building, or stabilizing?
These notes are the work log. The paid work runs through Moonshine Labs, my product and engineering studio. Tell us what you're building, or grab a call.
Work with us →