Gas City: inside the software factory with 100 coding agents

A hundred coding agents in parallel, fifty pull requests a day, a billion tokens a day. That's not a thought experiment — it's running right now on a single server in Atlanta. What Gas City shows about multi-agent engineering is more interesting than the toolkit itself.

From Gas Town to Gas City

Earlier this year Steve Yegge — a well-known developer-tools veteran — published a Medium post about Gas Town, an open source orchestration layer that lets 20 to 30 AI coding agents work on the same codebase at the same time. The post went viral. Last week its successor Gas City was announced, rebuilt as a proper toolkit by Chris Sells (ex-Google, previously grew Flutter to 3M developers) and Julian Knutsen (former technical lead at Block).

Knutsen runs Gas City in production on a single server in Atlanta with about a hundred agents, together merging roughly fifty pull requests per day — the output of a small team — burning roughly a billion tokens per day. That's about one fifth of the entire English-language Wikipedia corpus. Per day.

Mike Taylor's call (Every's head of tech consulting) after a workshop in New York: 🟨 — "Learn from the ideas. Skip the toolkit for now." What we care about are those ideas, because they map directly to the architecture questions we hit with clients the moment agents start really running in parallel.

Three ideas worth internalising

1. Dark factory vs. light factory

Split your process into two zones. Light factory = the steps where humans and agents are at the table together: planning, design, final review. Everything visible, everything steerable. Dark factory = the steps where the agent works on its own in the background, with nobody watching. Bug triage, refactor passes, test generation, formatting, dependency bumps.

The trick: you start with almost everything in the light and shift more of it into the dark as trust in the agents grows. Same mindset as the move from manual to automated tests, but for agent actions. For our clients that translates to: make it explicit up front which actions don't need a human in the loop and which do — and revisit that list every sprint.

2. One pet, many cattle (the "mayor" and "polecats")

This is the strongest idea in Gas City. Instead of managing a hundred agents individually, you talk to one persistent supervisor agent (Gas City calls it the mayor) that understands your intent and holds context. The mayor then delegates to anonymous, disposable workers (the polecats) that do one job and shut down.

Why does that work? Because the workers carry no history and don't pollute context. And because you as a human never have to track a hundred things at once — you have one conversation with the mayor, not a hundred parallel chats. The same pattern shows up in Claude Code's sub-agents, in Cursor's background agents and in OpenAI's recently released Symphony. It's slowly becoming the default way to structure multi-agent systems.

3. Multiple models on every code review

Send the same diff to Claude, Codex and Kimi — at the same time. Three different models catch different bugs than one model run three times. For us that's an immediately usable pattern: a review step that runs a PR through two or three different models costs very little compared to the developer time you get back. We're already building this into a few n8n flows and into OpenClaw's PR-review chain.

Where Gas City itself falls short

The toolkit is still rough. Mike Taylor flagged a few concrete pain points:

• No agent memory across tasks. Every task spins up a fresh session that doesn't know what earlier agents did. Result: agents re-read context that a sibling agent just produced. Wasted cycles, and you miss connections a single session would have caught.
• It costs what it costs. A six-step job is roughly six times the cost of one Claude session. At a billion tokens per day you're not talking coffee money.
• Setup is heavy. A room full of experienced engineers took a full day to get it running, even with Sells and Knutsen on the call.
• Beads (the task tracker) is agent-first, not human-first. It runs as a CLI, not a visual dashboard. So teams in production pair it with Jira or Linear — tasks in two places, double work.
• It overestimates how much hand-holding modern models still need. Many of the review loops and mid-task check-ins Gas City builds in to prevent drift are unnecessary with Claude 4.5 or GPT-5.2.
• The jargon works against it. Beads, polecats, refineries, mayor — fun thematically, but every new teammate starts with a dictionary.

When is this relevant for you?

Our take matches Taylor's: if you're already running more than 10 Claude Code sessions in parallel and willing to read source code, Gas City is worth a look. For everyone below that bar: take the ideas, skip the toolkit.

For most of our clients, OpenAI's Symphony or a thin custom orchestration layer on top of Linear/Jira is more realistic. Symphony is essentially a written ruleset that turns your existing board into the dashboard the agents work from. That maps onto how engineers already work and doesn't require the behaviour change Gas City does.

What this says about the direction of engineering

Three patterns we hold onto, regardless of which toolkit eventually wins:

• One conversation, many executors. The mayor/polecats model is the way to work with more than five agents in parallel without losing control. Anyone building an agent architecture today that treats all agents as peers will redo it in a year.
• Multi-model review is free quality. The delta between one model and three different models on the same diff is bigger than the delta between Sonnet 4.5 and Opus 4.5. Low-hanging fruit we're already patching into client PR flows.
• The dark factory is coming. A growing share of software engineering happens without a human in the loop, and the companies that make explicit early on which work belongs in the dark capture the biggest throughput wins. For clients we coach on agentic engineering, "what moves into the dark" is a standing question at every sprint review.

Gas City isn't the endgame. But as a snapshot of what a well thought-through multi-agent setup actually looks like, it's one of the most honest publicly available right now. A hundred agents on one server isn't marketing — it's somebody trying it, writing it up, and sharing the pain. That's more than you can say of most vendor demos.