Compare · Tier A
CodeHerder vs Gas City / Gasworks
Steve Yegge's programmable agent-orchestration platform: a durable, Git-backed issue tracker plus TOML formulas that compile into multi-stage agent workflows.
What Gas City / Gasworks actually ships
- Beads, a Git-backed durable work-unit tracker where every item, including mail and agent identity, is a Bead
- Programmable formulas: TOML workflow definitions compiled into sequential-stage, dependency-graph, fan-out, loop, and error-policy pipelines
- A review-and-gap-check pass after each run, comparing the result against the plan and filling what's missing
- Gasworks, a managed multi-operator layer with shared workflows and live visibility across operators, SaaS or self-hosted
Where it's strong
- Open source (MIT) and self-hostable, with a real, shipped fan-out-and-review pattern
- Arguably the more programmable orchestration engine of the two: a team that wants to author its own workflow graph from scratch has real room to do that here
How CodeHerder differs
- CodeHerder ships as a configured product; Gas City hands you the primitives to build your own factory
- CodeHerder pairs its workflow engine with cost and budget attribution, a device herd spanning multiple machines, and organizational (initiative → epic → story) structure, none of which Gas City publishes
Gas City is 'build your own software factory.' CodeHerder is 'here is your software factory.'
Capability snapshot
CodeHerder vs Gas City / Gasworks, capability by capability
Every row traces to the same source as the full matrix, where the full legend lives. In short: "not published" means no public evidence was found, not that the feature is absent. Verified as of 2026-08-08.
| Capability | CodeHerder | Gas City / Gasworks |
|---|---|---|
| Concurrent agents | Published | Published |
| Multi-vendor harnesses | Published | Published |
| Customer-owned machines | Published | Published |
| Multi-machine routing | Published | Partial [5] |
| Automatic work assignment | Published | Published |
| Capability-based routing | Published | Partial (configurable) |
| Atomic claiming | Published | Partial (work queue) |
| Dependencies | Published | Published |
| Custom workflows | Published | Published (fully programmable) |
| Server-enforced gates | Published | Published |
| Agent handoffs | Published | Published |
| Persistent shared memory | Published | Published (packs/state) |
| Live terminal / view | Published | Published |
| Human takeover / steer | Published | Published |
| Cost per task | Published | Not published (as of 2026-08-08) |
| Cost per stage/model | Published | Not published (as of 2026-08-08) |
| Hard $ cap | Published | Not published (as of 2026-08-08) |
| Schedules | Published | Published |
| Webhooks / API / CLI | Published | Published |
| Self-host full platform | Published (Enterprise) | Published (OSS) |
- Gas City is self-hostable and OSS, which implies multi-machine capability, but no source found describes an explicit cross-machine routing mechanism the way Orchestratia's multi-server dashboard or Warp Oz's fleet model do.
Sources
Verified against Gas City / Gasworks's own site as of 2026-08-08.
- Gas City's documentation site
- Gas City's Gasworks page
Round up your herd.
Bring every human and every agent onto one table. Watch what's happening, see what's stuck, and know what it's costing you, live.
Already have a workspace? Sign in