Benchmark·October 2026
ESCAPES
327 bugs that passed code review and tests, reached real users, and were fixed. We rewound 33 open-source products to the code before each fix and asked one question: how many could have been caught before a user hit them?
Escapes caught before the user reported them
One scan per product, on its code as of 1 July 2026. 235 of the 327 bugs were already in that code and were reported by users in the weeks after. The share of those 235 each system had already found.
01What escapes
The bugs
Every one of these bugs got through a project's own review and test suite. That is not a failure of review: most of them cannot be seen in a diff. They need a real data shape, a second user, a partner's outage or a month to pass. That is the layer ESCAPES measures.
Each bug is labelled by what it takes to see it. Per row: the share caught by the best model reading the code, Claude Fable 5.1 through Claude Code, and by breken running the product.
02How it was measured
- The bugs: reported by a real user on the product's public tracker, fixed by a merged pull request between 1 July and 19 October 2026 (after every tested model's training cutoff), and present in the code when the user hit them.
- The run: the product's code and docs as of 1 July 2026, nothing later. The system reports the bugs it expects users to hit.
- Why 1 July: the first day after the training cutoff of every model tested, so none of them had seen these bugs or their fixes. One scan on that day is what a customer would get. 235 of the 327 bugs were already in the code by then; those are the ones scored. The other 92 arrived later.
- A catch: the finding describes the failure the user later reported. Wherever possible it is proven by running: its reproduction fails before the fix and passes after.
- Checking: an independent judge model, one that no system on the board runs on, grades the rest. People check every match, every near miss and a 20% sample.
- Reference lines: frontier AI models reading the code through their own coding agents (Claude Code, Codex CLI), with the same budget, to show what reading alone finds. Static rules (Semgrep) as the floor.
- The score: escapes caught, as a share of the 235. Beside it a weighted score, as in RECON: a catch earns one point, a false alarm loses one.
The full dataset rules, the exact prompt the agents get, the judge and every metric definition are in section 07.
03Catching them first
breken caught 76 of the 235 escapes, 61 of them proven by running. The 3 frontier models reading the code caught 28 to 37; static rules caught 9.
A catch earns one point and a false alarm loses one, divided by the 235 bugs. Below zero, a system raised more false alarms than bugs it caught.
Caught: escapes caught, of the 235. Beyond 1 file: caught among the 166 that need the product running. Proven: catches with a reproduction that fails before the fix and passes after; the rest judged, then confirmed by a person. False alarms: total, then per product. Unreported: real defects no user had reported yet. Precision: real findings ÷ all findings. Head start: median days between the scan and the user's report, over caught bugs.
04Four escapes
Three catches and one miss.
A storage sync CLI: a connection dropped mid-transferCaught 63 days before the user
A collaborative editor: two editors and a reconnectCaught 29 days before the user
A miss: billing for streamed tool calls in an AI gatewayNot caught
05What it means
- Most escapes are invisible in code. 71% need the product running with real data, users, failures or time.
- They sit for months. A median 152 days in the code before a user found them.
- Running finds what reading cannot, with proof. 61 of breken's 76 catches come with a reproduction that fails when run.
- Head start is weeks, not hours. A median 44 days before the user's report.
Where review and breken fit
These bugs passed the first two layers by design: they were not in the diff. Review and breken are not alternatives; each covers what the other cannot see.
06Open benchmark
- The 327 bugs, their user reports, fixes and pinned commits, the harness, the judge prompts and every label are public.
- Any system can be submitted: one run record per product scan. We match, judge, check and publish it on the same page, with its agreement rate.
- A new version every quarter, mined from fixes merged after the newest model cutoff. Versions are never re-scored.
Limits
- breken built the benchmark and ran every system. The prompt, the caps, the judge prompts and every label are public, and a vendor's own submission replaces our run of their system.
- Only bugs linked to a fix are included, so this under-counts what users hit.
- “What the bug needs” is labelled by people from the user report and the fix; borderline cases are listed in the dataset.
- 18 bugs ship no test, so a catch on them is judged and hand-confirmed, never proven by running.
- 31 bugs were reported before 1 July, so they were public when the models were trained. They are marked and not scored.
- Each result is a single run under the same spend cap; run-to-run variation is published with the data. Cost and wall time are recorded, not scored.
- No browser-agent products in this version. Only 2 bugs are multi-user.
Judge promptssha256 f712b742f4cd2feabb6ec9e305293889666b62fec4cf277a689870c9bf364ab9
Frozenv1 · 2026-10-19 11:28 UTC · 327 bugs · 33 products · 309 executable · 235 live at snapshot
07Full methodology
Everything behind the numbers above, for anyone who wants to check or reproduce them.
How the dataset was built
The six rules
What is in the dataset
Live at 1 July: the bug was already in the code at the snapshot and was reported after it, so a scan on 1 July could have caught it. These 235 are the bugs scored on this page.
By kind of failure
A bug can carry several classes; the table counts its main one. Classes are keyword guesses: a hand check of 20 corrected 4.
All 33 products
None of these products appears in any list breken develops, tunes or measures on. All 33 are now on the held-out lists our development guards read.
What a bug record holds
// one entry, shape only { "id": "<owner>/<product>#<issue>", "direction": "A", "language": "Go", "issue": { "url": "…/issues/<n>", "createdAt": "<date>", "authorAssociation": "NONE", "userWords": "<what the user saw>", "signal": { "reactions": 0, "comments": 6 } }, "fix": { "url": "…/pull/<n>", "mergedAt": "<date>", "howLinked": "closing reference" }, "preFixSha": "<the fix's first parent>", "fixSha": "<the fix commit>", "introducedAt": "<date>", "sites": [ { "path": "src/…/update.ts", "lines": [118, 131] } ], "tests": [ "src/…/update.test.ts" ], "snapshot": { "live": true }, "class": ["broken-flow"], "severity": "medium", "executable": true }
The systems and what they are given
Every system runs under the same spend cap per product. breken reports only what it would show a customer; the coding agents are asked for at most 10 findings per product; static rules return every hit. Code-review bots see a diff, not a product, so pointing one at the change that introduced a bug is an aimed run: published apart, never on the leaderboard.
What a system is given
Two run modes
This page shows snapshot runs: one scan on 1 July, measured against what users reported in the months after.
The prompt the agents get
Sent to Claude Code and Codex CLI as a fresh session: no memory, no project instructions, no tools beyond what the CLI ships. The product name and the commit are the only things filled in.
You are testing <owner/product> at the commit checked out in the current directory. kind A: It is a product that people or programs use (a web app, an API or an MCP server). kind B: It is an SDK, CLI or toolkit that people use to act on other things. Find bugs that real users would run into in normal use: wrong results, broken flows, lost data, wrong access, crashes, or (for a library or CLI) wrong output or failures for valid use. You may read the code and docs, build it, run its tests and run it. Report at most 10 bugs, best first. For each one, if you can, give a reproduction: a shell command (and any new test file's full content) that FAILS on this commit because of the bug and would pass once it is fixed. Answer with JSON only: {"findings":[{"id":"f1","title":"one sentence","failure":"what the user or caller sees go wrong", "steps":"how a user gets there", "reproduction":{"command":"...","files":{"path":"content"},"setup":"install command, if needed"}, "files":["the source files at fault"]}]}
Finding contract
{
"id": "f-012",
"title": "Refund after a partial capture returns the full authorised amount",
"failure": "The ledger refunds the authorised total, not the captured part",
"steps": ["create an order", "capture part of it", "refund"],
"reproduction": { "command": "npm test -- refunds.partial",
"files": { "test/refunds.partial.test.ts": "…" }, "setup": "npm ci" },
"files": ["src/payments/refund.ts"],
"location": { "path": "src/payments/refund.ts", "line": 88 }
}Grading and metrics
A finding counts as a catch only if it names the same user-visible failure the user later reported. Three rungs decide it, in order. The higher rung wins.
Metrics
What is not a match
Leakage controls
Commands
# build (read-only GitHub access; writes only to the sealed directory) node bench/escapes/build.mjs --phase mine node bench/escapes/build.mjs --phase verify node bench/escapes/build.mjs --phase assemble --max-per-product 12 --min-per-product 5 node bench/escapes/freeze.mjs # run a system node bench/escapes/arms/run.mjs --arm breken --label v1 --mode snapshot --cap-usd <usd> node bench/escapes/arms/run.mjs --arm plain-llm --label v1 --mode snapshot --cap-usd <usd> node bench/escapes/arms/run.mjs --arm static --label v1 --mode snapshot # match and score node bench/escapes/match.mjs --label v1 node bench/escapes/score.mjs --label v1 --judge --model-env judge.env --cap-usd <usd> node bench/escapes/score.mjs --label v1