Self-hosted · Windows app · LangGraph · any model, via OpenRouter

An autonomous coding agent
that has to prove its work.

Persei was created out of a need for a truly autonomous AI developer you can trust with your repositories. Simply provide a goal in plain English, and the agent independently plans the solution, writes the code, and executes your project’s local test suite. To ensure absolute production safety, a secondary model reviews the code before it ever reaches the main branch. Persei runs locally on your own machine, giving you full control to plug in any model via OpenRouter.

  1. 1Planwrite_todos
  2. 2Buildsandboxed
  3. 3Verifyreal test suite
  4. 4Review gate2nd model
  5. 5Shipon green CI
Model configuration — the build pipeline roles, each with its own pinned model and live pricing

How a task runs

It’s a loop. The agent does the work, the gate decides whether that work earns a merge, and the gate is allowed to send it back as many times as it takes.

work

It builds in a box that can only see one repo

The agent works inside a throwaway Docker container with just the one repository mounted. A bad shell command can't wander into your other projects or your secrets. When it needs help it hands off to two helpers: one that can only read and investigate, and one that writes tests and has to actually run them before it's allowed to say it's done.

verify_and_ship

Saying “done” doesn't count

I don't trust the agent's word, so the gate re-runs your project's real typecheck, lint and tests itself, the same commands you'd run. Only a pass with an actual diff becomes a commit, on the task's own branch. If the agent left items on its todo list, the commit is held and the task goes back to finish them.

review

A second model reviews it, then you do

A different model reviews the branch against the exact point it forked from, runs the checks again in its own sandbox, and says READY or NEEDS_FIXES with findings. Then it waits for your look. What merges is the exact commit that was reviewed, and main only moves when GitHub Actions is green on it too.

“The agent saying done doesn’t mean it’s done.”

The console

Everything happens in one dashboard. You watch tasks and planning live, and if you open it halfway through a task you see what already happened instead of a blank page. It installs on your phone too.

The dashboard — spend, outcomes and per-repo cost, with planning sessions and tasks grouped by category in the sidebar
Planning sessions and tasks share one sidebar, grouped by kind, filterable by repo, with anything waiting on you pinned at the top. Spend, outcomes and fix cycles are up front, and the review gate’s cost is counted separately from the agent’s. Your remaining credit turns red under 15%, so you see it coming.
Analytics — per-role model usage with call counts, tokens, latency, cost and cache rate

See where the money actually went

Every role's real usage, straight from the router's own per-call ledger: calls, tokens, latency, cost, and how much came from cache. If a role is burning money, you see it here instead of finding out from the bill.

The commit reviewer's role, showing how many probed models meet its requirements

Models get tested before you pin them

The reviewer needs strict tool calling and a forced response shape, and most models can't do both. Each role only lists the models that actually passed its probes, so you find out on this page, not four minutes into a task.

Support roles — classifier, summarizer, vision and cartographer, each with capability badges

Cheap jobs get cheap models

Classifying a task or summarising a log doesn't need the model that writes your code, and paying coder prices for it is just waste. Every support role is pinned on its own and says what it actually needs.

Users — per-project access control and adding a user

People see the projects they need

An account is scoped to the projects you give it, and everything follows that: tasks, planning, analytics. You see everything; someone you add for one repo can't start work on another.

New in 0.9

The biggest release so far. Most of it came from actually running it every day on my own projects and fixing whatever got in my way.

A real Windows app

One installer. It sets up WSL and Docker if you don't have them, asks for your keys in a window, pulls the release and signs you in.

It keeps itself updated

The app and the stack update on their own, but only when the agent is idle, and never by grabbing your window mid-task.

Signed releases

Every release builds from a tag on a green main, pushes its images once by digest, and signs the list the app pulls from. I approve each one before it ships.

Catching problems before they become problems

The review gate got tougher. If a review didn't actually check the code, it doesn't pass. A task waiting its turn behind other reviews keeps its place instead of timing out, and your approval carries through a rebase that changed nothing.

Less busywork from GitHub

Dependabot alerts on the same package become one task, not eleven, and a task whose alert another fix already closed just says so and stops.

A “Needs you” list

Anything escalated or waiting on your merge approval sits in its own group at the top of the sidebar until it's done.

Planning Chat

Before something gets built, you can talk it through. Planning is its own agent with web search, a real browser and read-only access to your projects, but no way to change anything. When the plan is right, one click hands it to the build pipeline, and what planning cost is carried onto the task.

It picks the model per turn: an everyday one, a stronger one when the question gets hard, and a frontend seat for UI work so the plan is written by the model that will build it. Once a session steps up, a short follow-up won’t quietly drop it back down.

Starting a planning session — choosing the repository and the model route
  • Memory that builds upFinished tasks turn into per-project memory, and past work is found by meaning as well as keywords. A cartographer keeps a map of each codebase current.
  • A dollar cap per turnPlanning used to run uncapped. Then it spent $7 on a single 157-call turn. It has a cap now.
  • Map first, then look aroundIt reads the codebase map before it starts listing folders. One read instead of a dozen.

What the model can’t get around

This thing writes and runs code against your repos. The guardrails aren’t an afterthought, they’re most of the work.

A budget cap on every task

Checked after every model call, on the main agent and every helper, so a loop that goes sideways costs a number you picked, not whatever it wants.

The agent can't push to git

Its shell has no SSH key, no git credentials and no token, so a push from there has nothing to log in with. Only the gate pushes, after review, using a fine-grained GitHub token you create for just the repositories it should touch, handed to that one push and never to the agent.

Work can come straight from GitHub

The inbox picks up Dependabot PRs, security and code-scanning alerts, review comments and failing checks. Propose sends you an approve link; Auto just starts it. Either way it goes through the review gate and waits for your merge approval.

It asks instead of guessing

When it hits something gated, or it's genuinely unsure, the question shows up in the task stream, and your answer goes right back into the paused run.

The server decides what runs

Projects can only come from folders you allowed, checked after symlinks resolve. The commands the gate runs are the ones the server proposed, so nobody can slip a new one in through a request.

Nothing is a dead end

Escalated, stopped, out of budget or cut off by a restart, the whole state is saved, so resume picks up the same run instead of starting over.

Run it yourself

Windows and Linux both get an app. On Linux you can also run it straight on the host or as a Docker bundle. Every path ends at the same dashboard.

windows 10 / 11

The Windows app

Download the installer and run it. If you don’t have WSL 2 and Docker Desktop, it installs them for you (Windows will ask permission, and may want a restart). Then it asks for your OpenRouter key and where your projects live, pulls the release, and opens the dashboard. From then on it updates itself.

  1. Download the installer and run it
  2. Let it set up Docker if it asks
  3. Enter your OpenRouter key and projects folder
  4. Pick your password and sign in

Windows 10 or 11, 64-bit · an OpenRouter API key

appimage / .deb

The Linux app

Same app, same setup. The first time you run it, it installs itself into your app menu. If Docker isn’t there it installs it (on Arch-based distros like CachyOS too), asking for your password once, and then just carries on: no logging out. Your projects stay owned by you, not root. It updates itself from then on.

curl -fsSL https://perseiagent.ai/install-linux.sh | sh
  1. Run that, or download the AppImage below and run it once
  2. Let it set up Docker if it asks
  3. Enter your OpenRouter key and projects folder
  4. Pick your password and sign in, and find it in your app menu after that

64-bit Linux with a desktop · an OpenRouter API key

./install.sh

Linux, on the host

This is how I run it. The installer takes a fresh clone to a running agent: prerequisites, secrets, database, sandbox image and dashboard. It asks three questions and figures out the rest. --dry-run shows everything it would do without doing it.

git clone https://github.com/DJG3DK/persei.git
cd persei && ./install.sh

Linux · Python 3.12+ · Node 24+ · Docker · PostgreSQL 14+ · an OpenRouter API key

docker compose

Linux, as a bundle

Agent, database, router and the review gate as one stack, if you’d rather only install Docker. Put your OpenRouter key and projects folder in .env, start it, and open localhost:8100. The one thing it can’t do is restart your own app after a merge; that needs the host install.

git clone https://github.com/DJG3DK/persei.git && cd persei
cp docker/.env.example .env
docker compose up -d

Docker · an OpenRouter API key

Mac: not yet. It’s on the list, and the newsletter is where I’ll say when it’s ready. You don’t need a domain for any of this either: the agent listens on localhost, and an SSH tunnel is enough to reach it from somewhere else.

What changed, and what’s next

Every release comes with a changelog that says what changed and why. The newsletter is that, plus what I’m building next and what turned out to be a bad idea. I only send it when there’s something worth reading, and I never send anything else to this list.

I keep your name and email to send you the newsletter, nothing else. Never sold, never shared.