OpenAI's agent pipeline generated 948 Linux kernel patches for $1.2M. The published numbers stop exactly where the hard part begins: how many were accepted, how many duplicated work already in flight, and what they cost the maintainers who had to read them.
The pipeline is a five-stage agent loop: scout code for audit targets, scan for candidate findings, reproduce each in a KASAN virtual machine, decide whether it is exploitable, then write a patch, with a human researcher reviewing before anything is reported. The run is real work, not a demo — 2,308 deduplicated candidates, 1,724 reproductions, 1,169 working local-privilege-escalation exploits, and after variant analysis 948 distinct patches. The whole run cost $1,213,430 in API credits, about $1,279 per patch.
That last number is the one everybody quoted. It is also the one that measures generation, not repair.
The post is careful: the system "bundled a root cause analysis, a minimal crashing proof-of-concept, a candidate patch, and a full exploit to assist human researchers". A candidate patch is a proposal a maintainer has to read. The post says human researchers reviewed outputs and that OpenAI has "already sent out hundreds of reports and patches for critical vulnerabilities" — hundreds out of 948, with no figure for how many were merged, rejected, or found to duplicate work already in flight.
OpenAI's own takeaway hints at the top of that funnel: "Automated triage should take the rapid patching cycle into account. Revalidating findings against the latest code... helps avoid duplicate or obsolete reports." During the 10-day run, 61 LPEs were fixed upstream by others, 43 had staging patches, 299 were being discussed. A patch generated against a mid-October tree competes with all of that.
In an early run the exploitation stage reported 200 successful LPE exploits. Human review found that 20 of them reached root through a different 0-day than the one assigned. That is a 10% error rate in the pipeline's own success criterion, caught only by manual inspection — and the fix was to constrain the task and add an independent check.
Read that against the headline. If a tenth of "successful exploits" were aimed at the wrong bug, then the honest floor for "948 patches that fix their assigned vulnerability" is not 948 until someone verifies it. The post never says it did, at that scale.
Multiplying 948 by Pwn2Own's historical $20,000–$70,000 per Linux kernel LPE gives $18.9M–$66.3M, "16x to 55x our pipeline's cost". That comparison quietly assumes every patch is a payable, previously-unknown, non-duplicate bug. Pwn2Own pays for a working exploit against a hardened, fully-patched target under contest conditions; a candidate patch against a commit from two weeks ago is a different asset.
The kernelCTF section is the more honest number in the post, and it is the one to keep: 21 LPE exploits against a hardened kernel for $32,936, versus 26 confirmed 0-day LPEs accepted by the program in all of 2026. Even there the payout is conditional — "if the 21 vulnerabilities were accepted". That condition is the whole ballgame, and it is unresolved in the text.
Three numbers would turn this from a capability demo into an economics result: patches merged upstream, patches rejected or superseded, and reviewer hours spent. The first two are public — every kernel commit and every maintainer reply is on the record — so they can be produced later, and probably will be. The third is the one nobody measures: 948 reports is a flood for a subsystem whose reviewers are, in the post's own words, "working hard to rapidly discover and fix vulnerabilities".
This matters beyond Linux. If frontier models can generate patches faster than humans can adjudicate them, then the binding constraint moves from finding bugs to reviewing patches, and a pipeline optimised for generation will look successful while making the queue worse. The right metric for the next run is not patches per dollar. It is accepted patches per maintainer hour.
Two things survive the scepticism. Reproduction rate: 74.7% of static findings turned into working crashes under KASAN, with only 3.1% attributed to impossible conditions — that is a real reduction in triage noise, and it is the stage everyone else skips. And novelty: agents reportedly used 10 exploitation techniques that were new to third-party kernel exploitation experts, including new page-grooming and data-only primitives. If that holds up under expert review, it is a bigger claim than the patch count.
The pipeline also found a QEMU TCG bug while trying to analyse syscall entry — a reminder that the testing infrastructure is part of the attack surface.
If you run a security team, the useful signal here is cost per validated vulnerability, not per patch: $1,279 is cheap enough that "we cannot afford to audit legacy code" stops being an excuse, and expensive enough that you should measure acceptance before scaling the run. If you publish this kind of work, publish the acceptance column. A patch nobody merged is a document, and the difference between 948 documents and 948 fixes is the entire result.
Sources: OpenAI, "A thousand fewer paths to root" (4 Nov 2026) — all figures above are quoted from that post; no independent measurement was run for this note. The 10% wrong-path figure, the merge status of the patches, and the maintainer cost are as published: the first is stated, the second is not, the third is not.