KeelenFor people who run Claude Code or Codex every day
Claude Code or Codex on your repo, unattended. A test born green never merges.
Updated 3 September 2026
Keelen runs a bounded loop against a GitHub repository on your own Claude, Codex, GLM, or Kimi key. You write a request in plain English. A planning pass turns it into tasks with acceptance criteria, and dev runs implement them one at a time in single use VMs that are destroyed when the run ends. Every finished task arrives as a pull request. Five checks stand between that pull request and your main branch, and the loop may not weaken any of them to get to green.
The five checks, in the order they run
New tests are applied without the implementation and must fail. Tests born green are rejected. This is the check people argue with, and it is the one that makes unattended work possible: a test that cannot fail proves nothing about the code.
An independent adversarial review of the diff, by a model that shares no context with the run that wrote it.
Your own test suite, on a clean checkout.
Nothing merges over a red required CI check.
A review window before gated auto merge. Or replace the merge entirely, per project: manual merge (Keelen opens the pull request, you click merge) or branch only (a branch, no pull request).
What happens at 3am
Failures are classified into 30 kinds. Infrastructure failures and provider quota failures never count against your work. A real dead end becomes one plain English decision card and the project pauses instead of burning quota. Lessons and steering rules persist across runs, so a correction you make once holds.
Why not cron and Claude Code
For one repo you check every morning, that is a fine setup, and it is cheaper. Keelen is the part after the code is written: the failing test proof, a second model's review with no shared context, the clean checkout run, the CI gate, and recovery when something breaks while you are asleep. It also holds the roadmap, so it picks the next task without you. If you want none of that, use cron.
What it runs in
Every iteration runs in its own single use, non root VM, destroyed when the run ends. Network egress is deny by default through a proxy that allows roughly twenty hosts. The GitHub token for a run is scoped to one repository for about an hour and cannot modify CI workflows. Credentials are encrypted at rest under rotating keys.
Receipts
Keelen's own repository runs on the loop, with the same checks. The demo is 50 seconds and unstaged: an agent adds the MCP server, signs up, connects a repository, and the first pull request lands.
50 seconds, unstaged
How it works
Install the GitHub App
On one repository.
Connect a key
Claude via Claude Code, Codex, GLM 5.3, or Kimi K3. The engine is a per project setting.
Write a request
In plain English.
Read the pull request
The first one typically lands within minutes.
Not for you if
- Your repo has no tests and you will not add any. Unattended work cannot be verified, so do not run it unattended.
- You want to chat with it or watch it type. Keelen has no editor, no chat panel, and no autocomplete.
- You need someone accountable: on call, owning the outcome, with a contract and a deadline. That is a hire. A loop supplies throughput.
- The project changes direction every week. A standing roadmap suits work with a known direction.
Start it on a repo you do not care about
Set the project to branch only and watch what it does before it goes near anything real.
Flat tiers from $29 a month plus your own model usage, no markup on tokens. 14 day trial, no card.