Does coding work go better in a throwaway cloud box per ticket than in a local session, and where does the quality gap actually sit?

Hypothesis

Most code tickets need nothing from the owner except a clear brief and a review. If every ticket gets its own disposable cloud box that clones the repo, runs the tests and opens a pull request, then the number of tickets in flight is limited by review, not by how many local sessions one person can watch. We wanted to learn how fast that is, what it costs in quality, and whether a box is better or worse than a local session for the same brief.

What we built

• Dispatch layer. BB, a self-hosted agent server on a GPU workstation, starts one thread per ticket. Each thread gets its own Modal sandbox with the repo cloned, Node, git, the GitHub CLI and the coding agents installed. Archiving the thread deletes the box, which is the cost switch.
• An orchestrator that decides. The Claude session on the Mac picks tickets, writes the brief, launches runs, gets an independent review, merges and archives. Grilling and prototype tickets stay in a session with a human, because boxes lack that workflow.
• Scoped keys. A GitHub App installed on the owner's own repositories mints a one-hour token for one repository per run. No per-repository personal tokens.
• A launch script. One call spawns a box, waits for the result, prints it and archives the thread. Parallel is several of these in the background.
• Two box types. Modal is the default. Containers on the local workstation are the occasional free option, with weaker isolation.
• A scorecard. Every ticket is scored on the same six points: minutes to pull request, box test result, defects found after the box and by whom, fix rounds, environment-caused failures, and what the box could not check.

Learnings

• Speed. Round one launched five tickets 20 seconds apart. Five pull requests were open 6 minutes after the first launch. Box time was 1.5, 2.0, 2.3, 5.0 and 5.0 minutes (four on Modal, one on the local workstation). The earlier Cloudroom runs took about 25 minutes per ticket, and a first single-box run on a different repository took 19.
• Boxes write good code and run CI well. A box turned a diagram-board ticket into 187 passing unit tests and 297 passing browser tests, plus a byte-identical render check of the old boards, with no help beyond the brief. The misses were in judging the change, not writing it.
• Independent review found a real defect in 3 of 4 early box pull requests. Examples: four input folders left unwatched by a registry rebuild, a curl without --fail, and a stray date on a live board that could block saves. A box only reviews its own diff. We keep both an independent reviewer and the hosted code review.
• Same model, same bug, so the gap is review. In an A/B run of one brief (local worktree against box), local took 6 minutes and the box 12. Both passed their tests. The reviewer of the local pull request proved a keyboard-focus loss when a button disables itself. The reviewer of the box pull request said merge, yet it had the same pattern. One reviewer is not proof.
• Idle does not mean done. The first box in the A/B run went idle and lost all its work. After a /clear of the launching session, two pull requests were opened but their threads stayed idle and their boxes kept running until the next session archived them by hand. Launch with nohup and list all machines after any session reset.
• Siblings from one main all conflict. Views built in parallel from one branch touched the same two hook points, so each merge forced a rebase of the next. A conflict-only rebase was not mechanical: both rebases broke a test from the other view. The second rebase exposed two real bugs. Budget one rebase box per sibling and review again after every rebase. Briefs that only add new files ran in parallel and rebased with zero conflicts.
• Boxes have blind spots. No live data, no credentials, no code-graph tool, no Mac hooks, no other repositories. Six tests in one box failed that passed 255 of 255 locally, so every "fails on main too" claim from a box needs a local re-run. A box with one core also could not reproduce a flaky browser test that fails on a slower runner.
• A dry run must use the real shape. A live dry run passed on a tiny synthetic board and failed on the real one, where 32 long labels broke a width check. A small demo proves the plumbing, not the data.
• Cloudroom facts, for the comparison. A hosted cloud thread cannot be cleared (HTTP 409), so a clean reset is a new thread. Headless Chrome there needs --no-sandbox. Merging a base pull request with branch deletion closes the pull requests stacked on it.
• Auto-mode classifiers block merges. On the workstation, gh pr merge was blocked until a per-repository allow rule was added, and reads of production were blocked until allowed.

Open: the live dry run of the second board migration is not yet done, and the count of box pull requests that land with zero fix rounds is still small.

Log

• 2026-10-27: Round one, five tickets, five pull requests in 6 minutes, several merged after independent review. Then a series of diagram-board tickets, rebases, the local-versus-box A/B, and a decision to keep box runs Modal-first with an independent review on every pull request.
• 2026-10-26: First tests on a hosted cloud-agent service for coding lanes, about 25 minutes per ticket. This set the baseline for the comparison.