Gas Town

Gastown is an open-source multi-agent workspace manager for teams and solo builders who use Claude Code, Codex, GitHub Copilot, Gemini, Cursor, and similar coding agents. It turns a local development workspace into a small operating system for agent work: one primary coordinator, named the Mayor in the project docs, plans work while worker agents handle focused tasks in separate project contexts. The goal is simple: keep agent work from becoming a mess once more than one coding assistant is involved. The project is built around persistent work state. Instead of relying on an agent's current chat memory, Gastown stores coordination data in git-backed hooks and Beads ledgers. Rigs wrap repositories, crew workspaces give humans a stable place to work, and polecats represent worker agents with durable identity across short-lived sessions. Convoys group related work items so a larger feature or migration can be assigned, tracked, recovered, and inspected after sessions end. Gastown is useful when one agent is not enough. A builder can ask the coordinator to break a project into tickets, hand off pieces to worker agents, monitor progress, and recover stalled work. The README describes support for 20 to 30 agents, mailboxes, handoffs, session discovery, lifecycle monitors, and a dashboard for watching the system. It also supports different runtimes, so Claude Code can be the default while Codex, Copilot, Gemini, and Cursor fit into the same workspace pattern. The project is best treated as advanced local AI infrastructure, not a hosted SaaS. Setup requires a local machine, git, tmux, the target coding-agent CLIs, and comfort with terminal workflows. Pricing is free from the Gastown project itself under an open-source model; users still pay for any model or agent runtime they connect. For teams already pushing Claude Code or Codex into multi-agent delivery, Gastown gives them a stronger coordination layer than ad hoc terminal tabs and sticky notes. A practical Gastown rollout starts with one project and a small set of tasks. Keep the Mayor as the planning surface, create a crew workspace for hands-on review, then add worker agents only when the work can be split cleanly. Because state lives outside the chat session, the workflow is better suited to long refactors, dependency migrations, test repair, and multi-step feature delivery than to quick one-off prompts. Teams should still review code, run tests, and treat agent output as draft work. This is an early-stage builder tool, so the right adoption pattern is cautious. Read the README, install in a disposable workspace first, and verify the commands before pointing it at valuable repositories or production workspaces. The project is valuable because it exposes a concrete workflow that developers can inspect and adapt. It is not a replacement for human code review, source control hygiene, or security checks. Teams should keep logs, review generated artifacts, and document which agent or plugin performed each important action.