Gas City 1.4: The View From The Factory Floor

Welcome to Gas City 1.4! The 1.3 release was focused on architectural changes, improving formulas and packs. In contrast, 1.4 is focused on making several aspects of using Gas City better. If I had to boil it down to one phrase: it’s the quality of life update. Now, finding packs has a dedicated website, there is a much better window to watch your factory through, and you can even watch the factory the maintainers use to build Gas City itself.

For those new to Gas City, it’s an open platform for building your own software factories. AI has gotten to the point where it can run effectively with autonomous agents. Think of them as little AI workers running in parallel to create features and fix bugs. Gas City orchestrates these agents, allowing the dispatching of work to be as simple as prompting. Using the Bead system, you can see tasks created, and taken care of, in real time as the software factory completes its work.

Because I enjoy using Gas City so much, I’ve started contracting for Gas City, Inc.. To start off my contract work, I needed a way to track my time and generate invoices, so I have been using 1.4 to create a website called Meter. A couple of hours after setting up the new version of the gc CLI, I was able to clock in my time using my new Meter app.

The Pack Registry

To get Gas City working just the way I wanted, I created a pack. In Gas City, packs are reusable units of configuration that provide the actual functionality to the software factory. Think of them as installable engineering judgment. Developers have already created plenty of useful additions (or core functions, in the case of the Gas City team), and packs allow you to leverage that. Before, when you needed something other than the core packs automatically imported with Gas City, you had to know where to find the right pack in the right place on GitHub. No more!

Now, Gas City has a public pack registry, a package manager for packs: registry.gascity.com. It gives the community a place to contribute packs, gives the rest of us a place to discover them, and shows the actual CLI command needed to install each one.

The new registry website at registry.gascity.com: pack search, registry stats, and a wall of featured packs, all in one place.

gc pack registry search --all lists every pack the registry knows about, right in the terminal.

The website doesn’t replace the CLI plumbing; it makes that plumbing much easier to use. The site helps you find the pack and gives you the correct gc command to run. The gc CLI imports the pack, resolves the version, installs the pack into your city, and writes the lock information that makes the build reproducible.

As far as Gas City is concerned, a registry is just a TOML file that lists a set of packs. Here’s the TOML file for the public registry hosted for the core Gas City packs. If you’d like to host your own registry, either publicly on the internet or privately for your team, you can and the gc CLI will use it like the built-in registry. Out of the box, 1.4 comes with the core pack registry named “main” so you don’t have to type the URL:

$ gc pack registry list
Name   Source
main   https://raw.githubusercontent.com/gastownhall/gascity-packs/main/registry.toml

$ gc pack registry refresh
main: refreshed 15 pack(s)

$ gc pack registry search 'planning and implementation'
Registry  Name                  Latest        Description
main      gascity               0.1.6         Gas City planning and implementation workflow pack.

list shows which registry your machine knows about, refresh downloads their current contents into a local cache, and search searches that cache.

show takes the pack details:

$ gc pack registry show gascity
Pack:        main:gascity
Description: Gas City planning and implementation workflow pack.
Source:      https://github.com/gastownhall/gascity-packs/tree/main/gascity
Source kind: git
Latest:      0.1.6
Import commands:
  This version or later: gc import add https://github.com/gastownhall/gascity-packs/tree/main/gascity --name gascity --version '>=0.1.6'
  Exactly this version:  gc import add https://github.com/gastownhall/gascity-packs/tree/main/gascity --name gascity --version 0.1.6

The gascity pack is the one you get by default when you create a new city with gc init. In addition to the registry for core packs, a registry is hosted for the community, allowing them to maintain packs in their own git repos while still enabling the entire community to easily discover them. If I want its community packs to show up in CLI searches too, I can configure it once:

$ gc pack registry add community https://registry.gascity.com/registry.toml
Added pack registry "community".

$ gc pack registry search cacc-twin-team --registry community
Registry  Name                  Latest        Description
community cacc-twin-team        0.1.1         Claude Fable mayor + GPT-5.6 Sol workers for the standard gascity roles.

That is the connection between a “configured registry” and registry.gascity.com: the website is the public marketplace, its registry.toml is a catalog the CLI can cache and search, and the import commands shown on the details page do the actual installation.

For my cacc-twin-team pack, the exact-version command shown by the website is:

gc import add https://github.com/wespd/cacc-twin-team/tree/644e108835906675a1e62bfb6f9fa5caaa8d31bf \
  --name cacc-twin-team \
  --version '0.1.1'
gc import install

On a clean 1.4 city, that produced:

Added import "cacc-twin-team" from https://github.com/wespd/cacc-twin-team/tree/644e108835906675a1e62bfb6f9fa5caaa8d31bf
Installed 4 remote import(s)

The city gets cacc-twin-team 0.1.1 from the exact accepted commit instead of whatever happens to be on the repo later. Zero-config imports are pleasant; lockfile guarantees are what let me trust them.

If everyone else is doing it…

Now, some people will be content with using packs others have created. However, if you’re already a Gas City power user, you might want to publish your own pack. Why not share in the fun?

In my own work, I’ve noticed that in broad planning Claude Fable is excellent, but when it comes to actually implementing code, GPT-5.6 Sol costs less with the same quality. So, I took the default gascity pack for the agent structure and made patches to it so the Mayor would run on Fable, while everything else ran on GPT. I called it cacc-twin-team.

There are two main ways to submit a pack: through the website, and through the CLI. The website can scan GitHub repositories where the Gas City Registry Verifier is installed, and it also has a manual form. The CLI uses the [pack].version in pack.toml and requires the checkout to be clean, with the current HEAD pushed to its upstream branch. A semver tag isn’t required for publishing, but is needed for users to be able to install it.

Here is the 1.4 CLI flow:

# After updating [pack].version in pack.toml:
git add pack.toml
git commit -m "bump pack version to 0.1.1"

# Add the semver tag for the pack to be installable
git tag v0.1.1
git push origin main --tags

gc pack registry login
gc pack registry whoami
gc pack registry publish . --dry-run
gc pack registry publish .

login stores a revocable registry token, and whoami verifies which account will submit the request. Before actually publishing, --dry-run shows exactly what will be sent. I ran it against the accepted cacc-twin-team checkout with the Homebrew 1.4.0 release:

Registry: https://registry.gascity.com
Repository: https://github.com/wespd/cacc-twin-team
Commit: 644e108835906675a1e62bfb6f9fa5caaa8d31bf
Pack path: .
Pack: cacc-twin-team 0.1.1
Ref: main
Description: Claude Fable mayor + GPT-5.6 Sol workers for the standard gascity roles.
Dry run: publish request was not submitted.

I got my ID and after a bit of a wait, lo and behold, my pack was human-reviewed and accepted at version 0.1.1.

My published pack, cacc-twin-team, as the registry CLI sees it: a Claude Fable mayor with GPT-5.6 Sol workers for the standard gascity roles.

gc pack registry publish . --dry-run shows exactly what will be submitted before anything leaves your machine.

For a closer look at how a simple pack works, reference the repo for my pack: github.com/wespd/cacc-twin-team — and the Shareable Packs guide that walks through the whole publishing flow.

Peeking behind the curtain

The pack registry ensured that setting up the city ran smoothly when I was creating my app. The dashboard ensured that actually running it was too. Before, when using 1.3, I would check agent sessions and beads constantly, worried that something had somehow gone awry. As such, the gc dashboard command was a welcome way to keep track of my factory without constantly typing in commands and hopping into tmux sessions — and while the command itself isn’t new, 1.4 gives it a serious upgrade.

The rebuilt dashboard's Home view for my meter-factory: model calls, active sessions, tokens per minute, and burn rate, served straight from the gc binary.

A finished do-work run end to end: five nodes down the stage ladder on the left, and on the right the agent's own session transcript — the tool call it made and the structured result it returned.

The dashboard IS the supervisor now — rebuilt and served straight from the gc binary (no separate server), with a new runs view. The command is still:

gc dashboard

It opens the supervisor’s dashboard in your browser and prints the URL. There isn’t a second dashboard service to install or remember to start.

The bigger change is that runs are now at the center of both the dashboard and the API. 1.3 let you do complex multi-agent work; 1.4 allows you to see it in a convenient form factor. Open a run and you can follow the formula’s stage ladder, then drill into each agent to see the request it received and its response. You can also see the live token rate and estimated burn rate, so “Is it doing anything?” and “What is this costing?” don’t require another hunt.

The API moved with the dashboard. Session and run reads now use typed, paginated APIs backed by warm projections instead of a collection of ad hoc wire shapes. That may not matter if you only use the UI, but it matters a lot if you’re building tools around the city: the screen and your code are finally asking the same model what happened.

gc sling also prints a deep link straight to the run it creates, which can be canceled through the dashboard.

$ gc sling meter/gc.run-operator gap-analysis --formula \
    --var subject_path=~/time-tracker/plans/invoice-export/implementation-summary.md \
    --var context_path=~/time-tracker/plans/invoice-export
Started workflow me-cmb (formula "gap-analysis") → meter/gc.run-operator
Dashboard: http://127.0.0.1:8372/city/meter-factory/runs/me-cmb

Asking the mayor to sling a formula, and getting back the run ID, what it will touch, and a dashboard link straight to the run it just created.

Following that link: the gap-analysis run me-ar7 with its four nodes down the stage ladder, every one of them done.

Watch THE factory run: Maintainer City

Since Gas City is made with Gas City, it also has a dashboard. If you’d like to see what a real 24/7 software factory looks like, you can watch the official Gas City software factory running in real-time! Opening factory.gascity.com, you can see Maintainer City, the actual factory used to manage work across the github.com/gastownhall repositories.

You can see the formula stage ladder, move into the agent sessions that did the work, and read the requests and responses behind the result. Hopefully, this will help pull back the curtain on full-scale software factories, and give insight into what is possible with Gas City.

factory.gascity.com: the Home view of maintainer-city, the factory that builds Gas City itself.

The Agents view of the production city: live agents up top, workers and available agents below.

There is also a bridge back to GitHub. When Maintainer City starts a formula for new work on a pull request or issue, it adds a Track progress link to the live run. This means that you can move from the conversation on GitHub to the same formula state and agent evidence the maintainers see.

The hook is new, so you won’t find those links throughout old PR and issue history. Look at ongoing work from the point where the feature was connected. For example, this Gas City review-queue comment links directly to the run that handled the pull request. No more wondering whether the automation swallowed your work!

The review-queue comment Maintainer City leaves on a pull request, with a Track progress link straight to the run handling it.

What that link opens: run gcg-6480 on the public factory floor, its stage ladder from preflight through cleanup, and every step's state.

Built by a community

I would be remiss to talk about a release this large without talking about the people who built it. Another big community cycle — 46 contributors, 13 of them first-time contributors 🎉 Thank you all.

Three contributions show just how much ground that covers. Christopher Scott added the Herdr provider. William Bernting added multiple default sling targets. Saren exposed workflow context in claim results. Those are three very different parts of daily Gas City use: where agents run, how work gets sent, and what an agent knows when it picks that work up.

The registry opens another way to contribute. You can improve Gas City itself, or publish the workflows you’ve already worked out as packs for everyone else to use. Gas City is a big tent and everyone is welcome!

Also new in 1.4

The registry, the dashboard, and Maintainer City are the parts of 1.4 that I notice first. However, there is quite a bit more underneath them:

Formulas v2 got production controls. Retry, fan-out, drain, scope, artifacts, and finalization all got stronger, along with better live status and event evidence. Why care? Because once a formula is doing real work, “try again” and “clean up when you’re done” can’t be hopeful suggestions.
Session lifecycle moved to the worker boundary. Pool demand, wake, resume, drain, close, and orphan recovery now reason from persisted session and work identity instead of provider-specific shortcuts. This means that pooled work shouldn’t get stranded just because capacity drained, restarted, or was reused.
The beads-backed storage path got much more resilient. Native and CLI-backed stores now share transactional lifecycle behavior, bounded cached reads, store-aware routing, and explicit degraded results across city and rig scopes. In other words, when a store is under load or partially unavailable, Gas City has a much better chance of telling the truth instead of silently doing the wrong thing.
More runtimes use the same lifecycle. Provider routing, ACP/automatic runtime selection, Herdr-backed sessions, and Kubernetes, subprocess, and tmux execution all meet at the same session lifecycle and worker boundary. This makes changing where an agent runs much less likely to change what Gas City thinks an agent is.
Usage and cost are attached to the work. Model, compute, and lifecycle facts feed local history and OpenTelemetry metrics. Long-lived sessions keep their token and cost rates current instead of freezing at the initial claim. This is what makes those new dashboard gauges useful instead of decorative.
Command metrics have privacy controls. Release builds disclose the small set of data collected before the first eligible command is recorded, and gc metrics status, gc metrics example, gc metrics on, and gc metrics off expose the controls. DO_NOT_TRACK=1 and GC_DISABLE_USAGE_METRICS=1 opt out at the environment level.
Private imports and hosted login got easier. Private Git pack sources can use host-scoped credentials, while gc login and gc whoami support hosted authentication. gc init --template empty creates a bare bootable city, the built-in model choices include GPT-5.6, and the CLI learned bare city names, configurable session waits and nudge intervals, multiple default sling targets, and better event paging. Small things individually, but very much in keeping with the QOL theme.

The full 1.4 release notes have the internal fixes, specialized controls, validation record, and complete contributor list.

Breaking Changes

If you use Homebrew, the official release is:

brew install gascity

$ which -a gc
/opt/homebrew/bin/gc

$ gc version
1.4.0

On an Apple Silicon Mac, /opt/homebrew/bin/gc should be the first result. An old source build in ~/.local/bin or ~/go/bin can otherwise shadow the release you just installed.

I would be remiss to not say this before you worry about any of the potential issues: after upgrading, run the following once in every existing city and before starting its orchestrator:

gc doctor --fix

Also, an old macOS supervisor may still be running after the binary changes, so you’ll want to restart it safely like so:

gc supervisor stop --wait
gc start

This is best practice after a Gas City update, but it is particularly important in 1.4 because the doctor handles the safe mechanical migrations. Anyhow, let’s go over the day-to-day things to watch.

Every graph-owning scope needs one store-scoped control-dispatcher. A rig-owned graph without a matching dispatcher now fails before instantiation, rather than quietly falling through to a dispatcher that can’t read the rig’s work. If you own a custom rig graph, add the dispatcher in that scope.
A stale bundled-pack cache may need to be reseeded. If an older gc was installed at a different path, run gc import install in the city and restart the supervisor.
A stale registered city can block gc start. Run gc doctor --fix in that city too, or use gc unregister if the city should no longer be registered.
The standalone dashboard server is gone. Keep using gc dashboard, but update bookmarks, scripts, or reverse proxies that pointed directly at the old server.

What’s next?

Since 1.0, the goal has remained constant. You shouldn’t have to babysit your agents. The improving nature of both LLMs and Gas City is increasingly making this possible. The goal is to allow you to just make software; to that end, the pack registry allows you to not worry about inventing functional workflows, and instead leverage the workflows others have already created.

I used Gas City 1.4 to build Meter, then used Meter while I kept testing Gas City. The registry made it easier to find and share the way I wanted the factory to work. The dashboard let me start with the run instead of wondering which tmux pane had the answer. Maintainer City shows what that looks like at full scale.

Tune in next time for a pretty big new feature. I don’t want to give it away — but trust me, you’ll want to subscribe to the blog to make sure you don’t miss it!

Have thoughts about this post? Join the Gas Town Hall Discord!