gascity: Gas City: The Orchestrator That Treats tmux Like a Cloud
A Go SDK for multi-agent coding workflows that makes agent state durable, runtime visible, and reconciliation the core primitive.
- Gas City is really an operations layer for agents, not a prompt wrapper.
- Its biggest trick is making live runtime attachable without hiding state behind an opaque loop.
- Beads turn work into durable history, which makes recovery and replay part of the design rather than an afterthought.
- The project borrows the discipline of cluster reconciliation and applies it to local and distributed coding agents.
Most agent tools optimize for generating output. Gas City optimizes for knowing what is happening. That shift matters when a workflow spans multiple agents, long-running sessions, and a human who needs to step in without resetting the whole machine.
tmux Is the Runtime Surprise
The most unusual choice in Gas City is also the most practical one: it treats tmux as a first-class runtime provider. That means an agent is not a hidden background loop. It is a live session you can attach to, inspect, and recover.
Gas City is an orchestration-builder SDK for multi-agent systems. It extracts the reusable infrastructure from Gas Town into a configurable toolkit with runtime providers, work routing, formulas, orders, health patrol, and a declarative city configuration.
That line from the README is the key. Gas City is not trying to be a chat loop with nicer packaging. It is trying to be the substrate underneath agent work, where runtime choice, work routing, and health all live at the same level.
Gas City Solves the Observability Problem
Most orchestration systems hide the ugly parts. They track state somewhere, but not in a way a human can hold onto during a failure. Gas City does the opposite. It makes execution visible through terminal sessions and makes work durable through beads.
That combination changes the debugging model. Instead of asking what the agent was prompted to do, you can ask what session exists, what bead it is consuming, and what state the controller believes should exist right now.
From Gas Town to a Primitive-First SDK
Gas City reads like an extraction. The project takes the reusable machinery from Gas Town and packages it as primitives: runtime providers, beads, controller loops, and declarative city configuration. That is a meaningful shift. It turns an opinionated system into something builders can compose.
Gas Town is Steve Yegge’s framework for orchestrating a fleet of coding agents. It shines when most of your work is pure code: lots of independent tasks, clear specs, and you mostly know what you want and don’t care how you get there. It falls apart when the work is heavily human-in-the-loop or ambiguous.
That critique helps explain why Gas City exists. If Gas Town is the full city, Gas City is the toolkit for building better districts, better utilities, and better control surfaces without inheriting the whole monolith.
The Controller Loop Is the Real Product
The core behavior is a reconciliation loop. The controller computes what should be running, checks what is actually running, and takes action until those two states converge. That is the same operational instinct that makes systems like Kubernetes resilient.
desired := buildDesiredState(cityConfig, pendingBeads)
actual := inspectRunningSessions(runtime)
if !statesMatch(desired, actual) {
reconcileSessionBeads(desired, actual)
}The code is simple on purpose. The power is not in a complex scheduler. It is in the repeated comparison between intention and reality.
Beads Turn Work Into Durable State
Beads are the atomic unit of the system. Work beads carry tasks. Session beads represent running agent sessions. Because the state is durable, a crash does not erase the system's memory. The controller can reconstruct what matters and keep moving.
That is where the Dolt-backed angle becomes interesting. The point is not storage for storage's sake. The point is versioned, inspectable orchestration. The history of work becomes part of the product, not an accident of logging.
| Dimension | Gas City | Gas Town | Typical agent framework |
|---|---|---|---|
| Core abstraction | Primitives for orchestration | Opinionated workspace system | Agents, tools, prompts |
| State model | Durable beads with reconciliation | Coupled to the larger workspace | Often ephemeral or hidden |
| Human visibility | Attachable tmux sessions | Helpful but more opinionated | Usually indirect logs |
| Runtime targets | tmux, subprocess, Kubernetes | Broader system defaults | Mostly framework-level |
This is why Gas City feels less like a wrapper and more like a control plane. It is interested in the lifecycle of work, not just the generation of answers.
Why This Feels More Like Kubernetes Than an Agent Wrapper
The mental model is familiar if you have worked on infrastructure. Desired state. Actual state. Reconciliation. Wake signals. Locking. A runtime provider that can be swapped depending on where the work belongs. Gas City borrows that discipline and applies it to local and distributed agent execution.
That choice also explains the project’s tone. It does not promise magic autonomy. It promises operational clarity.
The Trade-Offs
Gas City is powerful, but it is not minimal. If you want a single prompt chain, this is the wrong tool. If you want to think in controllers, sessions, and durable work units, the extra structure is the point.
That trade-off is the same one infrastructure teams know well. More explicit control means more things to understand, but also more things you can observe, recover, and extend.
Message passing between agents is the most compelling “agent thing” I’ve seen in a long time. Not “AI wrote code faster.” Coordination. Distributed work.
That is the deeper story here too. Gas City is betting that coordination is the real product category. The code generation is just the visible output.
What Gas City Suggests About the Next Agent Stack
The next useful agent tools will not only be smarter. They will be easier to operate. They will expose runtime, state, and recovery as first-class concepts instead of hiding them behind a cheerful interface.
Gas City is an argument for that future. If agents are going to do real work, they need real infrastructure.