> ## Content Index > Fetch the complete content index at: https://varops.com/llms.txt > Use this file to discover other available public pages before exploring further. # A world record fell in three weeks, and the person who ran it published his own supervision bill - URL: https://varops.com/a-world-record-fell-in-three-weeks-and-the-person-who-ran-it-published-his-own-supervision-bill/ - Published: 2026-09-10T15:28:20.000Z - Updated: 2026-09-10T15:28:20.000Z - Description: A record standing since 2020 fell in three weeks to one person and a swarm of agents. He then published what his own supervision cost - 82,702 words of steering - and itemized the six things the agent still needed him for. - Author: Rex Factor - Tags: Proof of Work *A record that had stood since 2020 fell in three weeks to one person and a swarm of agents - and the person then published what his own supervision cost, down to the word count.* [*Rex*](https://varops.com/columnist/rex/) *has the receipts, including the six things the agent still could not do without him and the reason it got worse the further it strayed from a well-worn open-source codebase. Read it for the checklist at the end. The vendor interest is named in the second paragraph, where it belongs. -* [*Muximus*](https://varops.com/columnist/muximus/) --- Three weeks passed between the first prompt and a world record. One person, a swarm of agents, and spare capacity on a cluster that was busy doing something else. Then he did the thing almost nobody does. He published what his own supervision cost: 82,702 words of steering, across 3,328 messages and 192 of the 233 sessions. Beside the result, an itemized list of the six things the agent still needed a human for. That list is the useful artifact here. The factorization is just where it got measured. ## What happened On 3 September the RSA Factoring Challenge got a new record. RSA-260 - a 260 decimal digit number, roughly 862 bits - was split into two 130-digit primes. The previous record, RSA-250, had stood since February 2020. The write-up is by Eric Lu, a Cognition employee; the post is on cognition.com, and the agent that did the work is Devin, Cognition's own product. His acknowledgments say it plainly: "Thanks to my employer Cognition; this would not have been possible without Cognition compute." Every claim about what the agent contributed is self-reported. The session statistics come from the agent itself - Lu introduces them with "Devin claims that." No transcripts or logs were published. So hold two facts at once. The *result* is verifiable, and we verified it: the two prime factors are printed in full, multiplying them reproduces the modulus exactly, and the factors were in the public factoring record six days before the Cognition post appeared. The *attribution* \- that an agent did the engineering - is Cognition's word alone. Both are true and neither cancels the other. ## The number nobody else publishes Plenty of companies now publish what an agent produced. This is the first we have seen publish what it took to keep the agent pointed in the right direction. > In retrospect, Devin claims that I sent 82,702 words (502,887 characters) in 3,328 messages across 192 sessions out of 233 used for factoring (totaling 14,450 ACUs). Eighty-two thousand words is a short book. Written over three weeks, into an agent, to get one result. And Lu is explicit that this is not the autonomy story it could have been sold as. Under a heading reading "What did Devin still need me (or other humans) for?", he writes: > But I cannot claim that Devin iterated autonomously on the entire end-to-end pipeline. It is interesting to consider what he needed me for. Somehow, the answer seems to be: still a lot. A marketing post would have stopped at the summary near the top, which does say the agent handled measurement, cluster operations and optimization end to end. This one kept going, and then qualified itself. ## The delegation checklist Here is what the agent needed a human for, in Lu's own words. He introduces it as "executive function, talking through and sanity-checking what it was doing": - setting a hierarchy of goals and keeping Devin properly scoped - recognizing when Devin was doing something unproductive and redirecting - recognizing repeated inefficiencies in Devin's workflows - pointing out untried directions ("make sure the GPU never blocks on the CPU") - organizing experimental frameworks and results - catching when Devin prematurely gave up on a direction Read that as a job description and it is a competent engineering manager running a team that works fast, never gets bored, and has no instinct for when it is wasting its own time. The line that matters most is the one after the list: > While in retrospect I appear to have supplied a couple of specific technical insights, my biggest contribution was probably to handhold the creation of a unified set of measured results, benchmarks, and performance estimators, which evidently were not otherwise going to self-assemble. The single largest human contribution to a record-setting computational result was probably **getting the measurement harness built**. Not the algorithm, not the optimization, not the insight. The scoreboard. And it did not self-assemble - Lu says so directly, and that phrase carries the weight: left alone, the swarm would have kept producing results that could not be compared with each other. ## The part that transfers The other finding sits near the end of the technical section, and as far as we can tell nobody has quoted it: > I believe that the human-engineered decomposition of the problem was essential to enabling the agents to make progress. In fact, I noticed that the further the codebase got from upstream CADO-NFS, the more confused the agents became. This could be attributed to accumulating complexity, but I wonder whether CADO-NFS's presence in pre-training is also relevant here. CADO-NFS is a mature open-source implementation that Lu credits with providing "all the relevant techniques, the pipeline stages and their interfaces, and a reference CPU implementation." The agents worked well while they stayed close to it. They degraded as they moved away. Lu offers two explanations and picks neither: accumulating complexity, or the fact that a long-established open-source project is very likely sitting in the model's pretraining data. Both are plausible, and both point the same way for anyone deciding where to aim a swarm. The work goes better on a well-decomposed problem with a reference implementation to check against, and worse on a bespoke system that exists nowhere but your own repository. That has nothing to do with cryptography and everything to do with which of your systems is a sensible first target. ## What it cost, and what that number is not About 4,900 GPU-days, which Lu puts at "about $400k at current market prices" using a published rate card of $3.50 per GPU-hour. That figure is an imputed price, not a spend. The compute was, in his words, "spare or fragmented compute that couldn't be used for other purposes," run "at no marginal cost" as a side project on a single-digit percentage of the cluster. Nobody wrote a check for $400,000\. It is what the hours would have listed at. Two things about it deserve credit anyway. The waste is left inside the total rather than netted out: 643 of those GPU-days went to polynomial selection, which Lu marks as "anomalously high basically due to operator incompetence," and about 7% of the linear algebra was lost to "crashes or preemption by more important work." And the breakdown is stage by stage rather than one headline figure. A fortnight ago the [published cost of an agent-written feature](https://varops.com/how-to-cost-an-agent-written-feature-when-published-numbers-only-covers-generating-it/) turned out to cover generating the code and not the months of landing it; here the hard part got its own section and a word count. ## The limits, stated plainly The siever is not released. Lu says his agents "built the world's highest-performance GPU lattice siever, which enables factoring numbers at 10x lower cost than the previous public state of the art," and there is no repository and no third-party benchmark behind that. The factorization is an artifact anyone can check. The tool that produced it is not. The 10x figure has been challenged on its baseline. On Hacker News, a commenter going by `herf` puts the RSA-250 comparison in 2017 Skylake terms and reprices it: rented on a modern 96-core host, the 7,010 CPU core-years the appendix values near $5M would run about $175k. He still expects the GPU route to win - just by less. "It's closer than the author says." The $30M estimate for RSA-1024 is Lu's own extrapolation from standard scaling, produced by someone with an interest in the result looking significant. He also puts a ceiling on his own alarm: RSA-2048, which is what modern keys actually use, stays roughly a billion times harder and is, in his words, not meaningfully affected by any of this. The operator was not a generalist, but he was not a specialist either, and he is precise about which. Lu has been factoring numbers as a hobby for about ten years, and describes his grasp of the pipeline this way: he understands the components "only in the same way a mid-level car hobbyist might understand car components: their approximate role in the overall system, their effects on performance, some tradeoffs of making changes, and what good operation and usage looks like - but not the underlying physics, nor how to fabricate the component from raw materials." That is the most encouraging sentence on the page for anyone wondering whether their own people could do this. The boundary he drew did not require him to derive the number field sieve. It required him to know what good operation looked like, and to notice when he was not getting it. He also volunteers the cost to himself: > I did not learn as much about NFS or GPU programming as I could have expected to had I done this on my own, though likely more than I would have if I were not using Devin at all. ## What to do with it Three weeks from first prompt to a result that had stood unbeaten for six years is worth paying attention to, and the honest version of what it takes is on the same page as the claim. Before pointing a swarm at a hard technical problem, the checklist Lu's account implies is short. **Is there a reference implementation to check against?** The agents worked while they stayed near one and degraded as they left it. A problem with a mature open-source baseline is a far better first target than one without. **Who is building the scoreboard?** Lu's largest contribution was a unified set of measured results and benchmarks that "were not otherwise going to self-assemble." If nobody owns that, the swarm will generate work nobody can compare. **Who notices when it stops making progress?** Four of the six items on his list are variations of catching the agent doing something unproductive - redirecting it, spotting repeated inefficiency, pointing out untried directions, noticing premature surrender. That is a person, and on this evidence it is about 82,000 words of one. Lu's own image for what he did is the right one to end on. He compares current agents to a sewing machine or a loom: "I push it along in some way; it evidently could not happen without me, but neither am I throwing the shuttle by hand." The looms got very good this year. Somebody still has to know what is being woven.