Full Control – Gas Town Orchestrates Ten or More Coding Agents
Many simultaneously acting agents often cause more chaos than benefit. The Gas Town tool orchestrates in the style of Mad Max.
(Image: Orange Dragon Studio/Shutterstock.com)
- Ingo Eichhorst
Mad Max as a role model for software development? The new Gas Town framework from developer and blogger Steve Yegge orchestrates more than ten coding agents simultaneously with an architecture inspired by the post-apocalyptic film series. The approach: not perfect individual agents, but controlled chaos with agent roles such as mayor, guardian, and refinery, all based on the Mad Max films (see table at the end of the article). Gas Town is not for the faint of heart or the light of wallet.
Yegge emphasizes that the system is still in alpha stage and requires considerable prior knowledge of coding agents to handle the chaos in the city of coding agents. Furthermore, due to the strong scaling, you quickly need a second or third Claude Max subscription from Anthropic, which costs $100 or $200 per month depending on the variant.
Gas Town is part of a whole group of applications currently being hotly debated by the community, whose goal is to coordinate coding agents. These orchestrators include, for example, Ralph, Loom, or AutoClaude. Yegge released the framework on January 1, 2026, after only seventeen days of development. However, the concept incorporates over a year of experimental experience. He wrote it using AI agents in Go.
From Chaos to Order
Yegge starts from the idea that it has always been the task of engineers to transform complex chaos into manageable structures. The tool tackles one failure mode after another with different concepts. The author speaks of non-deterministic idempotence, two terms that seem contradictory at first glance but come together through the framework's control structures. The parallel work of three to five coding and other AI agents can lead to chaotic system states. What happens, for example, when multiple agents work on the same or similar tasks? Who takes care of merge conflicts? How can duplicate work be prevented? Gas Town uses a wide variety of concepts to bring order to the chaos (see the following figure).
A Mayor's Workday in Gas Town
A typical day in Gas Town begins with the human developer (Overseer) and the main agent, the Mayor, defining the tasks for the day in natural language. The Mayor breaks down these tasks into smaller subtasks and stores them in the task manager (Beads). Once the preparations are complete, he bundles tasks into a work order, the Convoy, and sends them to one of the repositories, Rigs. If Gas Town has access to valid GitHub authentication, the Mayor can easily clone repositories and initialize them for use with Gas Town.
The division of tasks addresses the problem of declining quality of coding agent responses as their context window fills up. For Claude LLMs, this is currently 200,000 tokens. When the limit is reached, the coding agent compresses the dialogues to make space. In practice, even a context window filled to sixty percent leads to a noticeable reduction in output quality.
In the Rig, worker agents (Polecats) become active and start processing tasks. The more tasks there are, the more Polecats spring into action. They create their own work environment with Git worktrees and independently handle the implementation.
They can communicate with each other via Mailboxes and Handoffs. The Mailbox system is inspired by Erlang and is used for communication between long-lived agents, such as the Mayor and the Deacon. Handoffs, on the other hand, work synchronously and are used to transfer the work state to a new worker instance when the context exceeds the critical fill level described above.
Since things occasionally go wrong in Gas Town, the Mayor employs the Deacon, who periodically analyzes the overall system, cleans up zombie processes, restarts stuck sessions, and keeps the most important system functions alive. Unlike the Deacon, who patrols at the system level, the Witness monitors individual agents within a Rig. Any agent he catches slacking, he coldly murders and replaces.
Videos by heise
Merge Conflicts: The Refinery Sorts Them Out
With multiple agents, there are many parallel changes, duplicate work, and countless merge conflicts. Furthermore, more and more developers report that the joy in their job has decreased since they only review code from AI agents.
To overcome these problems, Gas Town has a Refinery. It checks all agent work results and cleans up. It combats merge conflicts and poor code quality primarily through quality criteria that can be set up via configurable review presets and a project-specific CLAUDE.md.
After all tasks are completed, the Mayor proudly reports the successful completion of the Convoy task group to the developer.
Agents in Gas Town are interchangeable instances, comparable to the concept of Cattle instead of Pets in infrastructure orchestration with virtual machines or containers, for example with Kubernetes. Beyond that, the framework has much in common with Kubernetes: there is a Control Plane (Mayor and Deacon) that manages a Data Plane (Polecats and Witnesses). The worker agents (Polecats) are interchangeable: if they stop working or get stuck, they are replaced by a new instance without losing the context from the last session.
Sweeps: Garbage Collection for Technical Debt
When developers blindly produce code with agents, technical debt accumulates over time. This also appears as misconceptions (Heresies) in the agents' inner monologue, and human developers can track and understand them. The cause of the errors is often the limited context window, due to which agents lose sight of what happened in the last session. Previously chosen approaches are forgotten, and agents sometimes choose foreign design methods that violate architectural consistency. In a larger codebase, for example, three to four different logging libraries can appear.
To counter this, careful human reviews are required, which in turn eats into the productivity gains from multiple agents. Gas Town chooses a different strategy based on sampling, Sweeps: systematic correction waves that curb architectural drift and bad practices without developers having to consider all misconceptions or analyze all lines of code individually. A sixty-minute review sweep results in concrete tasks for task management (Beads), which thus enter the context of the involved agents. This steers future decisions in the direction that human developers consider correct.
To start a Sweep, developers have the Mayor create a Git worktree via a persistent workspace (~/gas-town/<rig>/crew/<developer-name>/rig/) and view the work results of a Convoy there as usual in the IDE or terminal. Instead of making changes themselves, they instruct the Mayor to create correction tasks. These change the behavior of the agents and lead to a further increase in code quality. Gradually, trust in the agent swarm increases, and the effort for Sweeps decreases. Sweeps represent a kind of garbage collection for technical debt. In addition, developers should not forgo common control methods such as rule files (AGENT.md or CLAUDE.md) and static quality gates such as fitness functions or static code analysis.
