REGISTER / OLYMPUS
Not yet public System
Olympus
- Agent ops room
- Threads work in progress
- No public instance
Olympus is a self-hosted control plane for coding agents. A browser starts a run, a leased worker executes it in a git worktree, and protocol frames and permission decisions travel back live. It runs. It has also never been pushed to a remote, has no public instance, and its own gates run against a fake agent.
Nothing to open. No remote, no public instance.
RECORD / BUILD
- Shape
- Three long-lived processes and a database. A single-page client, one API and WebSocket server that is the only writer, and a worker that claims leased work and spawns an agent adapter for each turn.
- Stack
- TypeScript on a pinned Node, in a pnpm workspace. The server runs on Hono against Postgres 17; the client is React 19 with Vite and Tailwind.
- Isolation
- In the supported container installation each agent runs under an unprivileged uid derived from its agent id, working inside a conversation-owned git worktree rather than in your checkout.
- Single writer
- A second server process refuses to start. It exits on a single-writer conflict before it reconciles and before it listens.
- History
- 747 commits and no git remote configured, so nothing has ever been pushed. The trunk is a threads integration branch with an uncommitted working tree on it.
- Evidence
- The project's own acceptance document states that every green gate runs against a fake adapter and that no real credentialed agent has completed the loop. That is the next milestone, not a shipped claim.
01 / 03
Your coding agents do not run as you
That sentence is the README's first line and the whole reason the project exists. The normal way to run a coding agent is to hand it your shell, your checkout and your credentials, and hope. Olympus is the other arrangement: each agent gets its own unprivileged user, its own git worktree owned by the conversation it belongs to, and no reach into your files, the database password, the worker's credential store, or another agent's work.
What you get in the browser is an ops room rather than a terminal. You start a run explicitly, and the protocol frames and permission decisions come back live while it happens, so approving something is a decision you make with the request in front of you.
02 / 03
How it is built
Three processes. A React client, one server that owns every write to Postgres and refuses to start twice, and a worker that leases queued work out of the database and spawns an agent adapter per turn. The supported installation is a container set; a lighter single-unit installation exists and is documented as weaker, because there every agent runs as one account.
The unfinished part is threads. The trunk branch is the threads integration, and it is unfinished in specific ways: a reply in a thread does not yet carry the message it replied to, and the search projection still treats the main channel as though it were one. That is why the register says work in progress rather than a release date.
03 / 03
What it does not do
The README carries its own limitations section and calls it limitations, not a roadmap. These are the ones that decide whether the headline above is earned yet.
- No observed production run
- The loop and the credential path are proven against a fake adapter that demands a credential, and by construction. No real paid-provider agent has yet run under the hardened host boundary, so the real permission prompts, real worktree diffs and real cost provenance are unproven. Fake-adapter green is not end-to-end evidence, and the project says so in writing.
- No isolation between two agents on the light install
- Under the single-unit installation every agent runs as one account, which also owns the secret store. The worker announces that at startup. Register at most one agent there.
- Agents do not wake other agents
- Not built, and not wanted. Only an authenticated human request enqueues work, mentions never recursively wake anything, and a test pins that. If you want agents talking to each other, this is the wrong tool.
- One host, one writer
- Nothing here targets scale. Projection rebuild is credible at 100,000 events and unproven past a few million.
- No native mobile, and there will not be
- The narrower thing it contests is an installable web app that works from a phone browser with no key ceremony.
- Setup friction is unmeasured
- No outsider has installed this on a clean machine and timed it, so any number would be a guess.