Steve Yegge’s latest project, Gas Town, reads like a field report from the edge of AI-assisted coding in 2026: what happens after a single CLI coding agent stops feeling “wide” and starts feeling cramped. Gas Town is a Go-based orchestrator built to manage large fleets of Claude Code-style agent sessions—not just one or two, but “20–30 at once” in sustained use—while providing a structure for dispatching work, tracking it, and getting changes merged without descending into branch chaos.
Yegge frames it as the next step after the current wave of Claude Code lookalikes: not another agent, but orchestration. Gas Town is also deliberately opinionated and, by its author’s own warning, early: the codebase is only weeks old, “100% vibe coded,” and expensive to run at scale.
A tmux-first, agent-orchestrated IDE
Gas Town’s primary UI is tmux, used to host and navigate a stable of long-running agent sessions. The goal isn’t to replace Claude Code so much as to industrialize it—turning a set of ephemeral sessions into something closer to a coordinated system with roles, work queues, and durable state.
That “durable state” comes from Beads, a Git-backed issue tracker where work items are stored as JSONL and committed alongside project repos. In Gas Town, Beads isn’t a sidecar; it’s the data plane for orchestration, messaging, and identity.
Roles, rigs, and the “Town”
Gas Town models work across two scopes:
- The Town: the HQ repo/config plus the
gtbinary that orchestrates everything. - Rigs: individual Git repos under Gas Town management.
Workers are Claude-style agents prompted into specific roles. Yegge defines seven primary roles plus a human “Overseer”:
- Mayor: the main concierge/chief-of-staff agent.
- Polecats: ephemeral swarm workers that produce MRs and then get decommissioned.
- Refinery: the merge-focused agent that resolves the Merge Queue (MQ) problem by landing changes one at a time.
- Witness: patrol agent that watches polecats/refineries and helps keep convoys moving.
- Deacon: a daemon-beacon patrol agent, pinged every few minutes to keep the town running.
- Dogs (and Boot the Dog): helpers that absorb maintenance and long-running tasks so the Deacon doesn’t stall.
- Crew: long-lived, named per-rig agents for iterative work (design, back-and-forth planning, etc.).
A notable architectural choice: agents are persistent identities in Beads, while sessions are disposable. Gas Town leans hard on the “pets vs cattle” split, but applies it to work and identity rather than compute.
MEOW: workflows as durable graphs
Underneath the roleplay is a workflow system Yegge calls the MEOW stack:
- Beads: atomic work units.
- Epics: Beads with children and optional dependencies.
- Molecules: chained Beads forming workflows.
- Protomolecules: reusable workflow templates instantiated into molecules.
- Formulas: TOML “source form” cooked into protomolecules and then instantiated into workflows (including very large ones).
The point of MEOW is to express work as something agents can execute step-by-step with explicit acceptance criteria—so progress survives restarts, context exhaustion, and interruptions.
GUPP, nudges, and “seances”
The system’s core operating rule is GUPP (Gastown Universal Propulsion Principle): if there is work on an agent’s hook, it must run it. Work gets placed on hooks via gt sling.
In practice, Yegge says politeness and tool friction can keep sessions from automatically resuming, so Gas Town includes a real-time messaging workaround: gt nudge, which uses tmux notifications to kick a worker into checking mail/hook state.
That hack also enables a stranger feature: gt seance, which uses Claude Code’s /resume to spin up a subprocess session and let a current worker interrogate a predecessor session about missing context or prior handoffs.
Wisps, patrol loops, and convoys
Gas Town distinguishes between durable project work and high-velocity orchestration noise. For the latter it uses Wisps—ephemeral Beads that exist in the database but aren’t persisted to Git, then get “burned” at the end of a run (optionally squashed into a digest).
Long-running workers (notably Refinery/Witness/Deacon) operate via patrols: looping workflows with exponential backoff that wake when mutating gt/bd commands occur.
At the top of the “getting things done” stack is the Convoy: a work-order wrapper that groups tracked issues so swarms can attack a larger deliverable while Gas Town reports progress in a more legible unit than a stream of unrelated bead IDs.
A Kubernetes-shaped system that optimizes for “done”
Yegge explicitly compares Gas Town’s shape to Kubernetes—control plane vs execution nodes, reconciliation against a source of truth—but argues the optimization target is different: Kubernetes asks “is it running?” while Gas Town asks “is it done?”. He also draws a looser conceptual comparison to Temporal, positioning Gas Town’s durability idea as “Nondeterministic Idempotence”: the path may vary, but the workflow eventually completes because the steps, identity, and state are persistent in Git-backed Beads.
Constraints, prerequisites, and what didn’t ship
Gas Town is pitched at users already operating with multi-agent CLI workflows. Yegge includes an “8 stages” evolution chart and recommends being at least at the “10+ agents, hand-managed” stage before attempting Gas Town.
He also flags practical constraints: instability due to youth, operational overhead (“hands-on-the-wheel”), and high cost from token burn and multiple Claude accounts.
Finally, several items are explicitly called out as not making the New Year’s cut: federation/remote workers, a GUI (beyond tmux), richer plugin functionality, the proposed Mol Mall marketplace for formulas/molecules, and additional large benchmark runs.
