gc-torch: a terminal view for Gas City

gc-torch is a terminal interface, built by AR Labs, that shows what a Gas City installation is doing, live, from one screen. Gas City is one of Steve Yegge's public agent-orchestration projects, alongside Gas Town: it dispatches coding agents (AI agents that write code) onto units of work and groups that work into larger efforts. We run Gas City as an experiment beside our own tooling, and gc-torch replaces typing a series of status commands and reading snapshots that are stale before the last one prints. It is the sibling of VOX Torch, our terminal view over our own task graph, built on the same stack and rules over a different source.

What it watches

Gas City has its own vocabulary. A city is one installation run by a supervisor process. A rig is a project directory the city orchestrates. A session is a running agent. A bead is a unit of work (Gas City uses Beads, Steve Yegge's open-source issue tracker, for its work items). A convoy groups related beads, and a formula run applies a recipe of steps to work, each step assigned to a session. A pending interaction is a session stopped to ask a person something, such as approving a tool call.

Screen	Shows
Cities	One row per city: running or suspended, health, agents and sessions, open and ready work, pending interactions, unread mail, active runs, and the age of the last meaningful event
City	Tabs for work (convoys and runs with progress, ready beads no run owns), sessions (state, active bead, model, context used) and rigs
Work item	One convoy, run or bead with its children or steps, dependencies and recent events
Session	Header fields, the transcript tail and, while it runs, its live output
Needs you	Everything waiting on a person across all cities, ordered by what only a person can clear
Feed	The event stream, newest first, with routine patrol events collapsed

How it works

flowchart LR
  SUP["Gas City supervisor API"]
  CL["HTTP client"]
  M["Model and derivations"]
  TUI["Terminal screens"]
  D["Plain-text dump"]
  P["Person"]
  SUP --> CL --> M
  M --> TUI --> P
  M --> D

gc-torch reads the supervisor's HTTP API, which is typed, described by an OpenAPI document and streams events, instead of running the gc command-line tool. During research the status command timed out and returned partial results, each command start was a fresh snapshot, and the API is what Gas City's documentation names as the source of truth for events. gc-torch makes no call that changes anything.

It is written in Python with Textual for the terminal interface and httpx for HTTP, packaged with uv, matching VOX Torch so the two can share code later. It stores nothing: it reads, derives and renders.

Whose turn it is is derived, with its basis shown. A pending interaction, unread mail to a person, or a session draining while it still holds work means a person is needed. A bead in progress whose session resolves to a running agent is working; one whose session is gone is marked stalled. A failed run or degraded health needs attention. Every inferred value carries ~, and every derived cell names the fact it came from. When an answer the derivation needs is unavailable, the screen says which request failed instead of reading the absence as a fact.

Noise is summarised, never hidden. More than 90% of Gas City's events come from health-patrol orders firing every 30 to 60 seconds. The feed collapses them into one line per order (rate, last success, last failure) and a key reveals them.

Gas City's supervisor listens only on the local machine, so a city on a remote server is watched either through an SSH port forward or by running gc-torch on that server inside tmux. Every screen also has a plain-text form, so a log, a test or a terminal without a full interface can read the same facts.

How it was built

gc-torch was researched and built largely unattended through our coding pipeline, the route every code change takes (spec, test-first build, second-model review, a person's merge), with a person ruling on review findings. The work was split into three small tasks, each depending on the one before, because small tasks are more likely to land without a person and each produces a reviewable pull request:

1. Tracer: the API client, model, derivations and the plain-text dump, with fixtures recorded from two real cities and tests. Landed.
2. Screens: the Textual application with timer refresh and a headless screenshot tool. Landed after several rounds of independent review on a second model family; the findings fixed included an outage being shown as a city's removal.
3. Live: applying the event stream incrementally, a connection indicator, and the usage screen. Not built.

Design choices made while agents worked unattended were recorded as proposals, to be confirmed or changed by a person.

What exists today

The snapshot client and the six screens are built, tested against recorded fixtures, and merged in a private repository. Live streaming updates and the usage screen are not built. Writes, such as answering a pending interaction or nudging a session, are deliberately out of scope for the first version; whether a terminal view should act at all is an open question it shares with VOX Torch. Whether gc-torch's model should later become a library inside Torch's agents screen is also open.