Was ist Gas City?

Gas City ist ein Open Source Orchestration SDK für Multi Agent Coding Workflows. Es löst die wiederverwendbare Infrastruktur aus Gas Town heraus und macht sie als konfigurierbares Toolkit nutzbar, mit dem Teams eigene Orchestrierungen für KI Coding Agents bauen.

Statt fest verdrahteter Rollen setzt Gas City auf wenige Primitive und eine deklarative Konfiguration in einer city.toml. Darüber laufen mehrere Runtime Provider, ein Beads gestütztes Work Tracking über Dolt sowie Formulas und Orders, die Arbeit als Graph über viele Agents verteilen. Die Macher sprechen bewusst von einer Software Factory: einem System, das Software kontinuierlich baut, prüft, testet und betreibt, statt einzelne Agent Sessions von Hand zu betreuen.

Gas City orchestriert dabei gängige Terminal Agents wie Claude Code, Codex, Gemini CLI und OpenCode. Das Projekt steht unter MIT Lizenz, ist in Go geschrieben und self hostable, der Orchestrierungs Layer läuft also auf eigener Infrastruktur.

Never Code Alone arbeitet täglich mit Terminal Agents wie Claude Code und OpenCode und begleitet Teams bei parallelen Multi Agent Workflows. Aus diesen Projekten kennen wir genau die Frage, an der Gas City ansetzt: ab wann lohnt sich echte Orchestrierung, und wann bleibt ein einzelner Agent im Terminal die bessere Wahl. Wir ordnen Werkzeuge wie Gas City und Gas Town praxisnah ein, statt jedem Trend zu folgen.

Konkret helfen wir beim Onboarding ins Team und im 1 zu 1 Mentoring, prüfen KI generierten Code im Codebase Audit und bringen im Weg vom Prototyp zur Produktion Struktur in agentische Setups. Wer den Orchestrierungs Layer datenschutzkonform auf eigenen Servern betreiben will, findet in unserer Self Hosted KI Beratung und der DSGVO Beratung den passenden Rahmen.

Gas City ist der Nachfolger von Gas Town, aber kein simples Rebranding. Wo Gas Town ein wild wachsendes Experiment blieb, positioniert sich Gas City als reifere, enterprise orientierte Plattform zum Bauen eigener Software Factories. Die gesamte Multi Agent Maschinerie wurde aus Gas Town herausgelöst und von Grund auf als SDK neu gebaut.

Wichtig für die Einordnung: Gas Town stammt von Steve Yegge. Gas City hat er nicht selbst geschrieben. Er hat die Vision in einem Blogpost skizziert, gebaut haben es Julian Knutsen und Chris Sells. Yegge ist beteiligt und trägt bei, aber die Urheberschaft liegt bei Knutsen und Sells. Diese Unterscheidung ist relevant, weil beide Projekte oft in einem Atemzug genannt werden.

Technisch sind zwei Dinge neu. Erstens verdrahtet der Orchestrator keine Rollen mehr fest: Was in Gas Town Mayor, Deacon oder Boot hieß, ist in Gas City reine Konfiguration auf Basis weniger Primitive. Zweitens, und das ist der größere Sprung, führt der Orchestrator eine Formula als Graph über viele Agents aus, außerhalb deiner Session. Er zerlegt einen Job in Beads, verteilt die freien Schritte parallel, hängt jeden Schritt an seine Abhängigkeiten und wiederholt Fehler bis zum Abschluss. Einzel Session Formulas aus Gas Town laufen weiter, die verteilte Fleet Orchestrierung ist der Zugewinn.

Das mentale Modell von Gas City besteht aus sechs Bausteinen. Wer sie verstanden hat, kann fast jede Orchestrierung ausdrücken, ohne feste Rollen zu programmieren:

• Agent: eine konfigurierte Instanz eines Coding Agents plus Prompt Template, etwa Claude Code oder OpenCode.
• Bead: die kleinste Arbeitseinheit, dauerhaft und außerhalb jeder Session, versioniert im Git gestützten Beads Store über Dolt.
• Formula: die Methode, wie ein Job erledigt wird. Der Orchestrator führt sie als Graph aus.
• Rig: ein Projektverzeichnis, das bei einer City registriert ist, damit Agents darin arbeiten dürfen.
• Pack: eine teilbare Einheit aus Agents, Formulas und Orders, die sich über die Registry veröffentlichen und importieren lässt.
• Event: der Ereignisstrom, an den sich Waits und Orders hängen, um Abläufe zu steuern.

Eine City ist das Verzeichnis mit Agents, Formulas, Rigs, Orders und lokalen Einstellungen, das der Orchestrator braucht. Ein Order stößt Formulas zeitgesteuert oder per Ereignis an. Ein Controller und Supervisor gleicht dabei laufend den gewünschten mit dem tatsächlichen Zustand ab, ähnlich wie es Gas Town als Analogie zu Kubernetes über Containern beschreibt.

Gas City lässt sich schrittweise einführen. Der Wert wächst mit der Komplexität des Jobs: vom einzelnen Agent, der eine Aufgabe erledigt, bis zur geteilten Factory Konfiguration, die ein ganzes Team nutzt. Die folgende Tabelle zeigt die typische Progression von der einfachsten bis zur ausgereiftesten Stufe.

Gas City wird über Homebrew installiert oder aus der Quelle gebaut. Voraussetzung sind unter anderem tmux, git und jq, standardmäßig kommt der Beads Store über Dolt dazu. Wer ohne Dolt arbeiten will, setzt einen dateibasierten Store per GC_BEADS=file. Der Einstieg braucht nur wenige Befehle:

Als Provider unterstützt Gas City eine ganze Reihe von Terminal Agents, darunter Claude Code, Codex, Gemini, OpenCode sowie Inferenz Backends wie Cerebras. Die Runtime Provider reichen von tmux und Subprocess über exec bis zu Kubernetes. Weil Gas City selbst self hostable ist, lässt sich der Orchestrierungs Layer datenschutzkonform betreiben und mit lokalen Modellen über Ollama koppeln, etwa Qwen3 Coder oder GLM 5.

Gas City ist geeignet für Teams, die mehrere Agents dauerhaft parallel arbeiten lassen und wiederkehrende Abläufe automatisieren wollen: Release Prozesse, Ticket Queues, DevOps Aufgaben oder datengetriebene Pipelines. Seine Stärken liegen in der Nachvollziehbarkeit, weil jeder Schritt als Bead mit Git Historie über Dolt festgehalten wird, und in der Wiederholbarkeit über Formulas und Packs.

Für Solo Entwickler an kleinen Projekten ist das Overhead. Ein einzelner Agent im Terminal genügt dann völlig, und ein strukturiertes Vorgehen wie das GSD Framework bringt oft mehr als eine volle Orchestrierung. Wer parallele Agents nutzt, muss zudem Monitoring und Token Budget im Blick behalten, denn beides steigt mit der Anzahl der Sessions deutlich. Ob sich Gas City für dein Projekt rechnet, klären wir im Beratungsprojekt, ehrlich und am konkreten Use Case.

Aus der Praxis gilt: Orchestrierung ersetzt keine Qualitätssicherung. KI generierter Code braucht weiterhin Tests, Reviews und Sicherheitsprüfungen. Genau hier setzen wir mit Codebase Audit und Security Audit an, und wir helfen Teams, Werkzeuge wie Gas City sauber in ihre Vibe Coding Toolchain einzuordnen.

In NCA Beratungsprojekten sehen wir regelmäßig dasselbe Muster: Teams starten mit einem Agent im Terminal, stoßen bei wachsender Parallelität an Grenzen und suchen dann einen Orchestrierungs Layer. Gas City und Gas Town sind hier zwei ernstzunehmende Kandidaten, aber die eigentliche Arbeit liegt davor: saubere Branch Hygiene, klare Aufgabenschnitte und ein realistischer Blick auf das Token Budget.

Wir begleiten diesen Weg vom Onboarding über das Mentoring bis zum Deployment der fertigen Anwendung. Wenn ein KI Projekt bereits entgleist ist, hilft unsere Projektrettung, und bei sensiblen Codebasen setzen wir auf self hosted KI. Welches Modell dabei ohne US Anbieter passt, zeigt unser Guide zur Modellauswahl. Einen Überblick über alle Leistungen gibt unser Vibe Coding Consulting.

Die wichtigsten Fragen zu Gas City, seiner Rolle neben Gas Town und dem sinnvollen Einsatz in Teams.