Gas Town: The AI Programmer Orchestrator for 2026

Core Question: In the era of AI-assisted programming, when we run dozens of Claude Code or similar AI coding agents simultaneously in a development environment, how do we avoid chaos and ensure they collaborate efficiently rather than interfering with one another?

Answer: Gas Town is a brand-new IDE concept designed specifically for 2026. It is not just a code editor, but an orchestrator for AI agents. By leveraging an architecture similar to Kubernetes, it solves the “yak shaving” tedium of managing numerous concurrent AI instances, allowing you to manage a team of super-intelligent developers focused on core creativity and architecture.

What is Gas Town?

If you are a seasoned developer, you have likely experienced the power of using AI coding assistants like Claude Code or its clones (such as Codex, Gemini CLI, Amazon Q Developer CLI, etc.). However, when you attempt to run 10, 20, or even 30 of these instances simultaneously to accelerate development, chaos ensues: task progress becomes hard to track, context is easily lost, and code merging becomes a nightmare.

Gas Town was born to address this. Its core goal is to solve these management hassles, allowing you to focus on “what your Claude Codes are working on” rather than “how to keep them running.”

This is not merely an upgrade to personal productivity tools; it is a new workflow paradigm. As predicted in the earlier article Revenge of the Junior Developer, the future of programming is not about solitary work but about lashing multiple AI agents together like camels into a war chariot. Gas Town is the cockpit of that chariot. It makes the simultaneous, sustainable, and productive use of 20–30 agents a reality.

Figure 2: The 8 Stages of Dev Evolution To AI
Image Credit: Nano Banana via Medium

Why Do You Need Gas Town? More Than Just “Kubernetes for Agents”

Core Question: What critical link is missing from current AI coding tools that necessitates building a complex system like Gas Town?

Answer: Existing tools are isolated “agent instances” lacking a unified orchestration layer. The industry is currently blindly mimicking the CLI form factor of 2025, while Gas Town provides the underlying architecture for massive parallel work.

In the current state of the industry, most companies and developers are chasing the 2025 CLI form factor, producing various lookalike clones. It is like a bunch of kids playing soccer, only staring at the ball in front of them without thinking about the overall tactics of the game. Gas Town is the product of the next stage—it focuses on AI workflows and “Kubernetes for agents.”

The author describes Gas Town as a “self-sustaining machine” that had to have components added until it could maintain itself. While this looks complex (some say it looks like Kubernetes and Temporal had an ugly baby together), it is necessary. Gas Town’s complexity stems from the need to handle all the edge cases that arise from real-world, large-scale AI collaboration.

It can even solve problems that academia currently deems impossible for LLMs, such as the MAKER problem (a variant of the Towers of Hanoi). By generating million-step “Wisps” (temporary workflows), Gas Town can easily handle complex tasks that exceed standard LLM context limits, proving the power of its orchestration capabilities.

The Danger Zone: Gas Town Applicability and Barriers

Core Question: Is Gas Town suitable for you right now? Or are you ready to embrace this chaotic yet efficient development model?

Answer: Unless you are already an advanced player in AI programming, at the stage of “manually juggling 10+ agents simultaneously,” Gas Town is not for you. It is complex, expensive, in its early stages, and requires you to accept the philosophy of “Vibe Coding.”

Before diving into the technical details, we must clarify that Gas Town is not for everyone. Here are several key limiting factors:

1. Extremely High Operational Barrier

You need to evaluate your position on the AI-Assisted Programming Evolution Map:

  • Stage 1-5: If you are still using a single agent in the IDE sidebar or just starting to try CLI single-agent mode, Gas Town is too early for you.
  • Stage 6-7: If you are already accustomed to using 3–5 parallel instances or even trying to manually manage 10+ agents, you might be ready to try Gas Town.
  • Stage 8: This is the target audience for Gas Town—those who are already building their own orchestrators.

Gas Town is like an industrial factory manned by super-intelligent chimpanzees. If you are not an experienced “chimpanzee wrangler,” they could instantly destroy your codebase, work environment, or even your customers. This chaos is a feature, not a bug.

2. High Cost

Gas Town burns cash. You will need multiple Claude Code accounts to bypass single-account limits, and as you scale, costs will rise linearly. If you need to worry about where your API budget dollars go, this system is not for you.

3. Strong Tech Stack Dependencies

  • Tmux: Gas Town currently uses Tmux as its primary UI. You must learn basic Tmux operations.
  • Beads: Gas Town is built on top of Beads, a Git-backed universal data plane. You cannot use Gas Town without Beads; they are deeply integrated.

Reflection: Accepting Chaos, Embracing “Vibe Coding”

When using Gas Town, you must accept a work style known as “Vibe Coding.” This means work is fluid, like slopping shiny fish into wooden barrels at the docks. Some fish fall out, some escape, but overall, your throughput is massive. Some bugs might get fixed 2 or 3 times, and designs might need redoing, but that doesn’t matter because you are relentlessly moving forward at the speed of thought.

Figure 3: Vibe Coding Chaos
Image Credit: Nano Banana via Medium

Architecture Breakdown: The Seven Roles of Gas Town

Core Question: How does Gas Town organize these AI agents to collaborate, and what specific roles do they play?

Answer: Through a carefully defined system of roles, each agent has a clear responsibility, similar to the functional division in traditional software engineering, from the Mayor to the Workers.

The core of Gas Town lies in its role definitions. It introduces seven major Agent roles, plus your role as the “Overseer” (the eighth role). Each role has specific duties and a lifecycle.

1. Core Concepts: Towns and Rigs

  • Town: Your headquarters directory (e.g., ~/gt). All project Rigs live under the Town. The Town manages agents across all your Rigs.
  • Rig: Every Git repository placed under Gas Town management is called a Rig.

2. Role Breakdown and Use Cases

Figure 5: Gas Town's Worker Roles
Image Credit: Gas Town GitHub

  • 👤 The Overseer: That’s you. You are the boss, with your own inbox, capable of sending mail and instructions to any role.
  • 🎩 The Mayor: This is the agent you talk to most. It is your concierge and chief of staff. Most work Convoys are kicked off by the Mayor, and notifications of completion are received here.

    • Use Case: When you have a grand feature idea, you tell the Mayor, who breaks it down and distributes it to other agents.
  • 😺 Polecats: Gas Town is a work-swarming engine. Polecats are ephemeral, per-Rig workers that spin up on demand. They often work in swarms to produce Merge Requests (MRs), hand them off to the Merge Queue, and are fully decommissioned after the merge.

    • Use Case: When you need to quickly fix a batch of similar bugs or generate boilerplate code, you can spin up a swarm of Polecats to handle them in parallel.
  • 🏭 The Refinery: When swarming agents start working, you hit the Merge Queue (MQ) problem. The Refinery is the engineer agent responsible for intelligently merging all changes, one at a time, into main. No work is lost, though it can escalate.

    • Use Case: When 10 Polecats finish their MRs simultaneously and the base branch has changed, the Refinery handles the complex rebasing and conflict resolution.
  • 🦉 The Witness: Once you spin up enough Polecats, you need an agent just to watch over them and help them get unstuck. Gas Town’s propulsion is effective but flaky, and sometimes you need to hustle the Polecats to get their MRs submitted.

    • Use Case: When a Polecat stops responding because it lost context, the Witness steps in to help it resubmit or notify the Refinery.
  • 🐺 The Deacon: The deacon is the daemon beacon. It runs a “patrol” (a well-defined workflow) in a loop. A daemon pings the Deacon every few minutes, and it propagates this signal downward to ensure Gas Town stays working.
  • 🐶 Dogs: The Deacon’s personal crew. Unlike Polecats, Dogs are Town-level workers. They handle maintenance (cleaning up stale branches) and occasional handyman work for the Deacon.
  • 🐕 Boot the Dog: A special Dog awakened every 5 minutes just to check on the Deacon. Boot decides if the Deacon needs a heartbeat, a nudge, a restart, or to be left alone.
  • 👷 The Crew: The agents you will use most personally, after the Mayor. The Crew are per-Rig coding agents who work for the Overseer and are not managed by the Witness. You choose their names, and they have long-lived identities.

    • Use Case: For design work requiring a lot of back-and-forth, you might collaborate with a specific Crew member for a long time rather than using ephemeral Polecats.

The MEOW Stack: Gas Town’s Data and Workflow Engine

Core Question: How does Gas Town persist and track work to ensure that even if an agent crashes, the task is not lost?

Answer: Through a technology stack called MEOW, all work is abstracted into persistent, composable molecules, using Git as the single source of truth.

Gas Town is not just scripts; it is built on top of a stack the author calls MEOW. This feels more like a discovery than an invention.

Figure 9: The Molecular Expression of Work (MEOW)
Image Credit: Gas Town GitHub

1. Beads: The Atomic Unit of Work

It all starts with Beads. A Bead is a special kind of issue-tracker issue, with an ID, description, status, and assignee. They are stored in JSON (one issue per line) and tracked in Git along with your project repo. In Gas Town, Town mail, messaging, and orchestration all use Beads.

2. Epics: Top-Down Planning

Epics are Beads with children, which can in turn be Epics themselves. This gives you a lot of flexibility to build top-down plans. The children of epics are parallel by default, but you can put in explicit dependencies between them to force sequencing.

3. Molecules: Workflow Chains

The author had this idea on December 17th: break agent work up into sequenced small tasks that they must check off, like a TODO list. Molecules are workflows chained with Beads. They can have arbitrary shapes and can be stitched together at runtime.

4. Formulas: Source Code for Workflows

To better compose molecules, the author introduced Formulas (in TOML format). Formulas are the source form of workflows, which are “cooked” into protomolecules and then instantiated into Wisps or Molecules in the Beads database.

Use Case:
Suppose you have a 20-step release process for Beads. In the past, agents would struggle because of long wait states (waiting for GitHub Actions, CI, artifacts). They would skip steps. Now, you create a Formula defining those 20 steps and their dependencies. When a release task starts, it instantiates as a Molecule, and the agent must check off those Beads one by one. If the agent crashes at step 5, a new agent upon restart will automatically continue from step 5, not the beginning.

5. Wisps: Ephemeral Orchestration Beads

Wisps are a special kind of Bead. They exist in the database and get hash IDs, acting like regular Beads. But they are not written to the JSONL file, and thus not persisted to Git. At the end of their run, Wisps are “burned” (destroyed).

Use Case:
Refinery, Witness, and Deacon (Patrol agents) create Wisp molecules for every single patrol run. This ensures that workflows complete transactionally, without polluting Git with orchestration noise.

Driving Mechanisms: GUPP and Nondeterministic Idempotence

Core Question: How do AI agents automatically resume work after a restart or crash, rather than stopping to wait for user input?

Answer: Through the Gas Town Universal Propulsion Principle (GUPP) and Nondeterministic Idempotence (NDI), agents are forced to execute tasks on their hook, and workflow state is persisted.

Gas Town Universal Propulsion Principle (GUPP)

The core of GUPP is simple: If there is work on your hook, YOU MUST RUN IT.

In Gas Town, all workers have persistent identities in Beads (and thus in Git). Every worker has its own Hook, a special pinned Bead where you hang molecules (Gas Town workflows).

When you use the gt sling command to assign work to a worker, it goes on their hook. Theoretically, the agent should check its hook and start working immediately on startup without waiting.

The GUPP Nudge: Getting Around Politeness

In practice, however, Claude Code is miserably polite. It will often wait for user input—anything—before checking its mail and hook. To solve this, Gas Town introduced the Nudge.

The system will send a Nudge (via the gt nudge command) roughly 30 to 60 seconds after an agent starts. This simulates user typing, forcing the agent to break its silence, check its mail and hook, and take action.

Nondeterministic Idempotence (NDI)

Gas Town operates on a principle called Nondeterministic Idempotence. It is similar to Temporal’s deterministic durable replay but achieved through completely different machinery.

Figure 11: Nondeterministic Idempotence
Image Credit: Gas Town GitHub

Because work is expressed as Molecules, and each step is executed by a super-intelligent AI, workflows are durable.

  1. The agent is persistent (Bead identity).
  2. The hook is persistent.
  3. The molecule is persistent.

So even if Claude Code crashes or runs out of context, as soon as another session starts up for this agent role, it will immediately continue working on that step (via GUPP or a Nudge). The agent may make non-deterministic mistakes along the way, but can self-correct, because the molecule’s acceptance criteria are well-defined.

Reflection: This mechanism leverages the strengths of AI (understanding intent and self-correction) to cover for its weaknesses (instability and unpredictability), which is more suitable for the LLM era than traditional deterministic workflow engines.

The Hands-On Experience: Convoys and the Tmux Workflow

Core Question: As a user, what does a day look like in Gas Town? How do I interact with these agents?

Answer: You track progress via Convoys, switch between Tmux windows, give orders to the Mayor, and have Polecats and Crew execute the work.

Mail and Messaging

Gas Town uses a two-level Beads structure:

  • Rig-level work: Project work (features, fixes), done mostly by Polecats and Crew.
  • Town-level work: Orchestration, including patrols and releases.

Sling: The Primitive of Work Assignment

gt sling is the fundamental primitive for slinging work in Gas Town. If you tell the Mayor, “Our tmux sessions are showing the wrong number of rigs — file it and sling it,” the Mayor will file a Bead and sling it to a Polecat.

Convoys: The Ticketing System

Everything in Gas Town rolls up into a Convoy. A Convoy is a special Bead that wraps a bunch of work into a unit you track for delivery.

Figure 14: Convoy CLI display
Image Credit: Gas Town GitHub

It is confusing to hear “issue wy-a7je4 just finished.” Even if you see the title, it may not reflect the larger block of work. Convoys wrap every single unit of slung work into a ticketing unit. They show up in a dashboard with expanding trees, so you can see its individual tracked issues.

Use Case:
You are developing a massive refactoring feature. You create a Convoy and tell the Mayor to start a swarm to attack it. Dozens of Polecats start working on different files and modules in parallel, generating MRs. The Witness monitors them, the Refinery merges them. Eventually, you see the whole Convoy marked as “Landed” on your dashboard.

Tmux: The Main Console

While Gas Town will eventually have a Web UI or Emacs UI, for now, it relies on Tmux. Tmux is shockingly powerful and easier to learn than you think. You only need a few commands:

  • C-b s: List sessions, snoop them, switch to one.
  • C-b n/p: Cycle to next/previous worker in the group (e.g., next Crew member).
  • C-b [: Enter copy mode to scroll back.
  • C-b a: Brings up the activity feed view.

Figure 4: Mayor tmux status line
Image Credit: Gas Town GitHub

Handoff: Seamless Session Recycling

The core inner-loop workflow in Gas Town is the handoff, gt handoff (or just say “let’s hand off”). Your worker will optionally send itself work, then restart its session for you, right there in tmux. Thanks to GUPP, the agent will continue working automatically if it’s hooked.

Seance:
Gas Town even has a gt seance feature that allows a worker to communicate directly with its predecessor in its role (e.g., the current Mayor talking to the last Mayor). They do this with Claude Code’s /resume feature. The new agent spins up a subprocess, finds the old conversation, and asks, “Where is my stuff?” This solves the awkwardness of context transfer during session swaps.

Comparison and Future: Gas Town vs. Kubernetes & Temporal

Core Question: How does Gas Town fundamentally differ from existing orchestration systems like K8s or Temporal?

Answer: K8s asks “Is it running?”, Temporal relies on “deterministic replay,” while Gas Town asks “Is it done?” and relies on “non-deterministic self-correction.”

Comparison with Kubernetes

Gas Town does look a bit like Kubernetes, unintentionally. Both coordinate unreliable workers toward a goal. Both have a control plane watching over execution nodes, each with a local agent monitoring ephemeral workers. Both use a source of truth that the whole system reconciles against. These are apparently the natural shapes that emerge when you need to herd cats at scale.

The big difference is:

  • Kubernetes asks, “Is it running?” It optimizes for uptime—keep N replicas alive, maintain the desired state forever. Pods are anonymous cattle.
  • Gas Town asks, “Is it done?” It optimizes for completion—finish this work, land the convoy, then nuke the worker and move on. Polecats are credited workers whose completions accumulate. Gas Town proceeds toward a terminal goal.

Figure 16: Kubernetes/Gas Town comparison
Image Credit: Gas Town GitHub

Comparison with Temporal

Gas Town achieves durability and guaranteed execution similar to Temporal, but through completely different machinery. It doesn’t rely on deterministic replay, but rather on the self-correcting ability of super-intelligent AI agents and persistent workflow definitions.

Summary and Outlook

Gas Town is the author’s fourth complete, functioning orchestrator of 2025. While the codebase is under 3 weeks old (as of the writing of the source text), containing 75,000 lines of Go code and 2,000 commits, it has already shown astonishing potential.

What made the cut:

  • Self-handoffs work seamlessly.
  • Slinging and Convoys work.
  • The entire MEOW stack is operational.
  • Deacon, Witness, and Refinery patrols run automatically.
  • The Crew are great replacements for raw Claude Code.
  • The tmux UI works surprisingly well.

What didn’t make the New Year’s cut:

  • Federation: Support for remote workers on hyperscalers.
  • GUI: A better web or Emacs UI.
  • Plugins: Full functionality implemented as plugins on molecule steps.
  • The Mol Mall: A marketplace for molecules.

Reflection: The author spent the year traveling, loudly telling everyone from Temporal to Anthropic that “Orchestrators are next!” and “It will be like Kubernetes for agents,” but was mostly met with blank stares. So, in August, he started building his own. Now, he sits at home creating the future rather than walking around predicting it. Gas Town is a bold provocation to current AI dev tools and a serious exploration of how programming should be done in the future.

Figure 17: Happy New Year!
Image Credit: Gas Town GitHub

Practical Summary / Action Checklist

If you decide to try Gas Town, here are the key steps you need to prepare:

  1. Assess Your Status: Confirm you are at least at Stage 6 or 7 of AI-assisted programming (able to juggle 3-5 or more agents manually).
  2. Prepare Accounts: Get multiple AI service provider accounts (like Claude Code) to handle the high token consumption.
  3. Learn Tmux: Familiarize yourself with basic Tmux commands (session switching, window navigation).
  4. Install Beads: Understand and install Beads as the data plane for Gas Town.
  5. Configure Gas Town:

    • Initialize your Town (e.g., ~/gt).
    • Add your project Rigs.
  6. Start Roles: Fire up the Mayor, Crew, and the daemon.
  7. Try Sling: Don’t write code directly. Try creating Beads and using gt sling to toss tasks to Polecats.
  8. Monitor Convoys: Watch your task Convoys land on the dashboard.

One-Page Summary

Component Function Key Concepts
Gas Town 2026 AI Programming IDE / Orchestrator Manages large-scale AI agent swarms
MEOW Stack Data & Workflow Engine Beads, Epics, Molecules, Formulas, Wisps
GUPP Driving Principle If hook has work, must run; uses Nudge to wake
Town / Rig Architecture Layer Town = HQ; Rig = Project Repo
The Mayor Primary Interface The agent you converse with most
Polecats Temporary Workers Parallel task execution, ephemeral
Refinery Merge Expert Intelligent conflict resolution for MQ
Witness Overseer Ensures Polecats don’t stall
Convoy Tracking Unit Wraps task groups for visibility
NDI Execution Guarantee Non-deterministic but persistent/recoverable workflows

FAQ

Is Gas Town currently a stable, production-ready tool?
No. It is extremely new (the codebase is only weeks old) and described by the author as “uncut rough” or “fresh off the boat,” full of strong opinions and “vibe coded” logic. Using it requires a high tolerance for risk and chaos.

Do I have to use Tmux?
Yes, currently Tmux is the primary user interface. While better GUIs (Web or Emacs) are planned for the future, Tmux is currently the most effective way to interact with dozens of agents.

Does Gas Town support AI models other than Claude Code?
Gas Town is designed with “Claude Code” as a stand-in for a class of CLI agents. Theoretically, any AI coding tool following a similar interface (Codex, Gemini CLI, etc.) can be used as the “cattle” for Gas Town to herd.

How does the cost of using Gas Town calculate?
Cost scales linearly with the number of agents you run and the tokens consumed. Since Gas Town tends to run 20–30 agents simultaneously, it is very expensive and typically requires multiple API accounts to avoid single-account limits.

What is “Vibe Coding”?
This is the work philosophy championed by Gas Town. Instead of seeking perfect code and zero bugs, you seek maximum throughput. Accept the chaos and repetition, let the AI generate furiously, and you keep the good parts.

What is the biggest difference between Gas Town and Kubernetes?
Although the architecture is similar, the goal is different. Kubernetes aims to keep services running forever; Gas Town aims to finish tasks as quickly as possible. Kubernetes is about “existence,” Gas Town is about “completion.”

Can I write my own plugins for Gas Town?
Yes, Gas Town has the infrastructure for a plugin system. Plugins are essentially specific steps in an agent’s workflow that can be executed by the Deacon or other roles. The author plans to launch a “Mol Mall” in the future to share these plugins.