Ticketmaster

An interactive coding agent with a ticket-powered background crew.

Most terminal coding agents are a chat window that forgets everything once you close it. Ticketmaster (tm) keeps the chat and adds a work queue. You talk to tm like any other terminal coding agent. When something should happen in the background, it becomes a ticket: a worker leases it, does the work and submits a result with evidence, and then you review it with a keypress. Reject it and your reason is stored on the ticket, so the next attempt sees why the last one failed. The commit that added the review flow puts the rule bluntly: "Human-only; an agent never certifies work."

The tickets screen. T-2 is ready for review with the worker's passing tests. Pressing 1 accepts it, and it moves to Completed (tm ticket reopen T-2 undoes that).

Chat, then delegate

Every clip on this page is the real tm v0.1.0 binary driving a live model on a scratch Python project, with no scripted turns. The repo's showcase notes explain how they were recorded, friction log included.

A chat turn: tm reads calc.py, reproduces the divide-by-zero crash in a shell, and answers with a note about the related tickets.

A task typed into the dispatch input becomes T-3. A background worker picks it up and verifies it with doctest and pytest while the chat carries on.

The event log is the product

All project state lives in an append-only SQLite event log. Tickets, decisions, milestones and the wiki are views rebuilt by replaying it, and a chat session is just a disposable window onto it. "Append-only" isn't a convention here: SQLite triggers abort any UPDATE or DELETE on the events table, and each event's hash chains to the previous one with blake3, so tampering is detectable. A state change and its events commit in the same transaction, so they can't disagree after a crash.

Tickets move through a state machine (Ready, Leased, Running, Submitted, Verifying, Closed and friends) written as a pure, total function: no clock, no side effects, no wildcard match arm, and a unit test that walks every state and trigger pair. Workers hold leases with heartbeats and can run in their own git worktrees.

The same state feeds several front ends: the terminal UI; tm serve, an axum REST and SSE API with a React "project canvas" web client; a VS Code extension; a macOS Swift client; and MCP and ACP bridges, so other agents (Claude Code included) can hand work to tm workers. Underneath sit tree-sitter code intelligence and a provider layer the README counts at 21 backends.

It benchmarks itself, and publishes the losses

cargo xtask bench-cross runs the same fixtures through tm and opencode. The fixtures are real issues from projects like ripgrep, click, requests, cobra, ky and Hugo, and a check script confirms each one's test fails before the reference patch and passes after it. The scoreboards live in the repo, and they aren't flattering. In every recorded trial tm scored at or below opencode, tying at best. The latest pass had tm solving 0 of 3 to opencode's 2 of 3, on about 5.6 times the tokens. The last few days of commits are the tuning loop that came out of those numbers. A benchmark you only publish when you win doesn't tell you much.

How it was built

About 858 commits in two weeks (September 15 to 29, 2026), which Allison directed through a 2,000-line spec, 36 architecture decision records and an agent task list that assigns a model tier to each task. The result is a 27-crate Rust workspace with roughly 4,000 tests.

Status and trying it

v0.1.0 shipped on September 23, 2026 with a prebuilt macOS arm64 binary on the release page. On Linux, build from source:

git clone https://github.com/alliecatowo/ticket-master.git && cd ticket-master
mise install && mise run build
./target/debug/tm init

You'll need one configured model provider, such as ANTHROPIC_API_KEY. The thesis explains the idea behind it, and the decision records explain the rest. Dual-licensed MIT or Apache-2.0.