Delegatron hands a coding task to several AI models and has them check each other's work.

1. 01

   Plan

   The architect reads your request and breaks it into small tasks, each naming the files it will write, tests included. It also sets the acceptance criteria for the whole job.

2. 02

   Build

   The implementer writes the code and its tests as a patch. Patches go onto a separate branch for the run, never onto yours.

3. 03

   Test

   The patch runs in a sandbox, away from your files. If a new test fails, that settles the argument.

4. 04

   Review

   The reviewer reads the change next to the test results, then approves it or sends it back with a list of what's wrong.

So it's good at new, self-contained code, like services, tools, modules and test suites. It isn't good at fixing bugs in big existing codebases. And whatever it writes, a person should still read it.

1. “3” instead of “Fizz”

   The most common failure was tests that didn't match the code.

   It happened with every model. In one case a correct FizzBuzz was tested for “3” where the answer is “Fizz”. In the run above, the reviewer blamed the code, which was right.

2. 30B 2/5 vs 14B 4/5

   Bigger wasn't better.

   Qwen3-Coder 30B did worse than Qwen2.5-Coder 14B on FizzBuzz and on a FastAPI service, and it took about 45% longer. It also seemed keener to rewrite everything.

3. 6 iterations < 3

   More attempts made it worse.

   We gave Qwen3-Coder 30B six iterations on the chess task instead of three. Its first attempt got closest, at 9 of 11 tests. Later ones went backwards, and the last only passed by swapping the real tests for smoke tests.

4. 10 tokens/s vs 50

   12 GB is a hard limit.

   The 30B model doesn't fit on the card, so much of it lives in system memory and crosses the PCIe bus for every token. It ran at about 10 tokens a second, against about 50 for the 14B models that fit, and ran out of budget on anything non-trivial.

5. 5 s vs 90 s per passing test

   Local was cheaper, but far slower.

   On the FastAPI task the best local model cost about $0.002 per passing test, against $0.008 in the cloud. But it took 90 seconds per passing test against 5, and only got 6 of 8 tests passing, so the run was never approved.

6. 0 approvals, 16 April

   Getting local models to finish at all took a lot of fixing.

   In our 16 April benchmark, not one local model got a task approved, even when every test passed. A day later simple tasks were passing, after a batch of fixes and a switch to Phi-4 as architect and reviewer. Even so, the run above still stalled.

Any model, any role

Run each role on a local model, a cloud model, or mix the two. Local models fit on one 12 GB card.

Hard limits

Delegatron itself caps iterations, spending and time. The models don't get a say.

Evidence order

When the roles disagree, a failing test beats a security check, which beats a reviewer's blocking issue, which beats the director's opinion. A dispute that keeps coming back goes to the director once, for a binding ruling.

Patch checks

Every patch is scanned for leaked secrets, project-rule violations and new dependencies, and its imports are checked. The findings go to the implementer and reviewer. In block mode, a patch with a secret or rule violation is never applied.

Zero-cloud report

Each run lists every model, sandbox and storage call Delegatron made, and flags any that left your network. Package installs inside the Docker sandbox still reach their registries.

Languages

Python, JavaScript and TypeScript, Go, Rust, Java and PHP, each tested in its own sandbox.

Templates

Thirty ready-made ones, for web APIs, command-line tools, audits and test suites.

Interfaces

Use it from the terminal, a REST API with live updates, or the dashboard. In a git repository, every run commits to its own branch.