waskr How it works Control Roadmap Join the waitlist
Self-hosted · One binary

It’s not done until waskr says so.

The judge for your coding agents. It re-runs the checks on every push, sends failures back to the agent, and tells you why.

Your agents, our judge

Join the waitlist See how it works
Pre-V0 Used daily to build waskr itself.
How it works

Label a ticket. Get a judged pull request.

  1. 01 · Triage

    You label an issue

    Only issues a human has given a priority label are eligible.

  2. 02 · Queue

    waskr queues it

    It decides the order and explains why each ticket sits where it does.

  3. 03 · Agent

    An agent works it

    A runner takes a lease, makes a fresh clone and launches your agent, such as Claude Code.

  4. 04 · Gates

    The gates re-run

    The agent pushes a branch. waskr re-runs your gates in a separate fresh checkout.

  5. 05 · Verdict

    A PR with a verdict

    waskr opens the pull request with a waskr/pass label and a verdict comment.

Then you merge it, or waskr does if you’ve switched that on. Every step lands in an append-only SQLite ledger: ticket → lease → attempt → runner and agent → branch → pull request → judgment → merge.

Waitlist

Join the waitlist.

waskr is pre-V0 and running daily on its own repository. Leave your email and we’ll be in touch as it opens to more teams.

For engineering leads running coding agents, platform and DevOps teams who know the Jenkins model, and regulated or air-gapped organisations.

We’ll only use this to contact you about waskr.

Why a judge

“Done” is only a pass a claim.

Agents are interchangeable. Judging their work, and deciding what happens next, is the product. waskr competes on the judge, never on the generator.

  • The agent’s claim is never trusted

    waskr re-runs the gates in its own fresh checkout and ignores the agent’s own “pass”.

  • Empty output is a failure

    Gate output that says nothing is a failure, never a pass.

  • Retries that learn

    A failing gate’s output goes into the next attempt’s prompt, on a new branch named after the ticket and attempt number.

  • A budget, then a human

    After the attempt budget, the ticket is labelled needs-human. Environment failures don’t spend the budget.

You stay in control

You decide what gets touched.

Human triage only

Agents never self-assign. Only tickets a human has given a priority label enter the queue.

P1

Holds

Two labels take a ticket out of the queue straight away.

hold needs-human

A kill switch

Pause and resume from the CLI or a header button. Restarts are safe and nothing runs twice.

Off-by-default auto-merge

waskr never merges by default. When you switch it on, it merges only when every check has passed and the branch is up to date, one per poll.

waskr/pass

Branch protection applies

GitHub’s branch protection still governs every merge. A merge train brings only the front pull request up to date.

Refusals stay contained

A refused command blocks only its own ticket, with a safety net that blocks the whole runner.

See everything

Every position has a reason.

The queue explains why each ticket is where it is: priority tier, then age, then issue number. Read it in the UI or from the terminal.

$ waskr queue --explain
  • Tickets. A page per ticket, with every log one click away.
  • Problems. Issues show up in the UI with the exact fix. Unknown values are never shown as zero.
  • The ledger. Append-only. GitHub wins on shared facts, and the ledger never overwrites what GitHub said earlier.
  • Easy to start. Run waskr init, then waskr serve. No outbound requests until you add a repository.
The waskr Queue page: two tickets an agent is working on, and four in line, each with its tier, its position and the reason for it.
The Queue page. The UI ships inside the binary, alongside a live dashboard, Tickets, Runner, Merging, Problems, Settings and Setup.
What waskr is not

Clear about its edges.

Not a coding agent

It launches your agent from one headless call, such as claude -p. The main node needs no model at all.

Not a hosted SaaS

It runs on your machine, on loopback by default, with operator sign-in. Air-gapped sites included.

Not a CI system

It uses your CI: it re-runs a configured gate command on a runner and reads GitHub Actions results.

Not a sandbox

Isolating untrusted code is the admin’s job. A separate OS user or a container gives a real boundary.

Not an agent mesh

Agents never talk to each other. All coordination goes through the main node.

Not multi-repo or HA

One main node, SQLite, Linux only (x86_64, aarch64), GitHub only.

No merges behind your back

Auto-merge is an explicit, off-by-default setting.

No self-assigned work

Only human-triaged tickets are eligible.

Where it’s going

Less time reviewing. More time deciding.

Today waskr works one repository on one machine. From here it takes on more of the routine work around your agents, and you stay in charge of how far it goes.