Skip to content

Zimmer

Self-hostable orchestration for AI coding agents. You give it a task and a repo; it hands you back a pull request to approve, or a specific question about why it couldn't.

Zimmer is open-source, standards-built, and made for a single circle of trust — you, or a couple, or business partners. You stay in control of what runs and what merges; Zimmer handles the toil of getting an agent from a prompt to a verified PR.

It isn't a bet on one vendor

The agent harness is a registry behind a contract — Claude Code and Codex both ship today, and you pick the model per session (Claude or OpenAI). MCP servers are a JSON entry, not a code change. Nothing in the design assumes whose agent wins, which is the point: nobody knows yet, and the orchestration layer outlives the answer.

Bounded on purpose

There is largely one way to do each thing in Zimmer: a session is an isolated clone, its context comes from the catalog, and its lifecycle is one state machine. The top-level architecture is meant to stay stable, so by default you don’t need to know how any of it is implemented — and when something does break, you drill down into a part you can name.

The failure mode this avoids is the usual one for a hand-rolled agent rig: a self-learning agent let loose on a machine, accreting layers of glue that nobody understands, breaking regularly, with no obvious road back. Zimmer would rather be a system you can hold in your head.

A boring stack on one cheap box

Rails 8, PostgreSQL, Redis, GoodJob, Hotwire. It’s a Docker image that Kamal ships to any Linux host you can SSH into, and a single small droplet runs the whole thing. No per-seat bill, no exotic infra to keep alive, nothing you haven’t operated before.

You sign in — you don't paste keys

The goal is to juggle as few long-lived secrets as possible. Claude and Codex authenticate against your own account over OAuth, gh uses the device flow, and MCP servers register themselves and refresh their own tokens — dynamic client registration, PKCE, automatic refresh.

Which matters on the bad day. Agents read and write a lot of text, and sooner or later a credential lands somewhere it shouldn’t — a log line, a transcript, a pasted diff. If it was a long-lived API key, you get to choose between a permanent exposure and spending the next five hours manually rotating every copy of it. If it was a short-lived token the runtime already rotates, it expires on its own and you re-auth in a browser.

It follows you off the laptop

Install Zimmer as a PWA and it web-pushes your phone when a session finishes, fails, or stops to ask you something. Agent work that takes an hour shouldn’t need you to sit and watch it for an hour.

Built for work that outlives your attention

Pinned sessions and categories, a filter bar that opens on the sessions waiting for you, live PR and CI status on each session, search across full transcripts, opt-in heartbeats that nudge an idle agent, and goals that spell out what “done” actually requires.

The honest exception

Cloning works against any git remote, but the PR, CI, and review-comment automation is GitHub-specific today — it shells out to gh. If you live on GitLab, that half of Zimmer isn’t there for you yet.

Three ways in, shortest first. Pick the one that matches what you want right now.

New to the idea? Read What Zimmer is first, then come back.

It runs a real agent, headless

A session is a real Claude Code or Codex process running against a real clone of a real repo. It commits, it pushes, it opens a PR, and it hands the result back for you to approve.

It has a lifecycle

waiting → running → needs_input → archived. Every session sits in one of those states, and the state machine decides the next move.

It wires the context

Skills, MCP servers, agent roots, hooks, plugins, and references are resolved from a catalog by AIR and injected into the clone before the agent starts.

Once you’ve seen it run, these explain why it’s shaped the way it is.