Rohit Ghumare · September 9, 2026 · 10 min read

RSA-260 Fell to an Agent Fleet. The Human Sent 3,328 Messages.

At 01:48:57 UTC on September 3, a job on a GPU cluster printed two 130-digit primes whose product is RSA-260, the largest number from the RSA Factoring Challenge anyone has publicly split. Today Cognition published the full writeup. The first prompt went in on August 13. Nine hours later an agent had a working GPU lattice siever. Three weeks after that, a fleet of agent sessions had spent about 4,900 GPU-days running the general number field sieve to completion. The cryptography is the smaller story. The bigger one is what it took to keep agents productive on one computation for three weeks, and the steering log shows it in unusual detail.

What was actually computed

RSA-260 is a 260-digit semiprime that RSA Laboratories published in 1991 as a public challenge. The previous record, RSA-250, fell in February 2020 to an academic team running CPU clusters. The tool for numbers this size is the general number field sieve (GNFS), and its open-source reference is CADO-NFS. Cognition's run used CADO-NFS as the base, borrowed parts of msieve for polynomial selection, and replaced almost every compute-heavy stage with a GPU version the agents wrote. Per the writeup, only four pieces stayed on CPU: the cado-nfs.py driver, polyselect_ropt, makefb, and dup1.

GNFS runs in five phases, and they have very different shapes. That difference is the key to reading the whole project.

1. Polynomial selection. Search for a pair of polynomials that make the later sieve cheap. The run generated 83,557,723 candidate polynomials, root-optimized 18,333, trial-sieved 22, and kept a degree 6 polynomial. Cost: 643 GPU-days between August 18 and August 21.
2. Sieving. Collect "relations": pairs of small integers for which two related values both factor into small primes. The work splits by a parameter called the special q. Cognition sieved q from 1.0e9 to about 3.91e10 in 632,249 workunits of 60,000 q each, sized so each would take about ten minutes. Cost: 3,813 GPU-days, 189.5 wall-clock hours, August 22 to August 30.
3. Filtering. Remove duplicates and useless relations, then build a matrix. The sieve produced 13,849,985,589 raw relations, of which 8,298,749,059 were unique (40.1% duplicates), plus 3,991,449 free relations.
4. Linear algebra. Find dependencies in a sparse matrix over GF(2) with block Wiedemann. The matrix was 656,182,601 by 656,182,189 with 98,431,741,898 nonzeros. Cost: 467 GPU-days.
5. Square root. Turn a dependency into an actual factor. This is where the final numbers appear.

Add the three measured phases and you get 4,923 GPU-days, which Cognition rounds to 4,900, or 13.5 GPU-years. The writeup prices GPUs at $3.50 per GPU-hour, so 4,900 × 24 × $3.50 is $411,600, the "about $400k at current market prices" in the post. The planner below lets you move the two inputs that sized the expensive phase.

Nine hours to a GPU siever

The project started with a narrow request. Eric Lu, who wrote the post, quotes the opening prompt: "CADO-NFS is FOSS software for performing GNFS. I'd like you to develop a fast GPU lattice siever... You have Modal access keys available that I authorize you to use to spin up a single GPU box for performance testing." The agent worked for two hours, then iterated overnight for seven more, and produced a drop-in replacement for CADO's CPU lattice siever las, called glas.

Sieving is the right place for an agent to start because the task has a hard oracle. A siever either produces valid relations at a measurable rate or it does not. Every candidate change can be checked by running a workunit and counting output. Lu notes that "the intersection of GPU kernel-writing experts and number field theory experts is quite small," and a fast, cheap verifier is exactly what lets an agent substitute iteration for that rare combination of expertise.

Optimization then continued for weeks. The writeup reports per-workunit times falling from 585 to 486 seconds on GB200 nodes, 586 to 504 on GB300, and 628 to 541 on B200. That is roughly a 14 to 17 percent speedup on hardware that was already running, the sort of tuning a team usually does once and moves on from. Here it happened in parallel with the production run, because the sieve is, in Lu's words, "embarrassingly parallel over billions of small work units." A faster siever could be dropped in between workunits without stopping anything.

Sieving scales out, linear algebra does not

The two expensive phases look nothing alike to an operator. Sieving is 632,249 independent jobs. Any GPU of any type can take any workunit, a lost workunit costs ten minutes, and the job queue absorbs heterogeneous hardware without complaint. Divide 3,813 GPU-days by 189.5 hours and the run averaged about 483 GPUs at once.

Linear algebra is one computation. Block Wiedemann runs a Krylov sequence, a long chain of sparse matrix times vector products where step n needs step n minus 1. Cognition ran 2,564,096 iterations per sequence, two sequences, 256 wide each, on MPI grids ranging from 4×2 to 16×4 nodes, for about 48 hours. The post is candid about what that meant on shared capacity: the job "was fatally preempted frequently and we had to develop a somewhat complex placement script to constantly fit the best shape possible to the available compute."

The defense is checkpointing. The run wrote a checkpoint every 8,192 iterations and retained every 32,768th for the later solution step. When a preemption kills the job, the work since the last checkpoint is lost and must be redone. When checkpoints are too sparse you redo a lot. Write them too often and the writes themselves become the overhead. Something else went wrong too: CADO's own consistency check fired about 14 hours into the Krylov phase, and the team re-ran that interval. In parallel, CADO's bwccheck verified every pair of checkpoints, which is the only reason a silent corruption could be caught at all.

Play with the interval and the trade appears quickly. With no checkpoints, a single late preemption throws away most of two days. At 131,072 iterations each preemption costs on average an hour or more of redone work. At 2,048 the redo nearly vanishes but you write over a thousand checkpoints, and if each write is slow the writes cost more than the preemptions they protect against. The run's 8,192 is a middle setting: with writes of a few tens of seconds it keeps both the redo and the write bill small. None of this is new to anyone who has run long MPI jobs. What is new is that an agent session operated this loop, including the placement script that reshaped the job to fit whatever capacity was free.

The square root that overflowed

The last phase looks like the easy one and was not. The post reports that the rational product reached about 1.76e11 bits and that "sqrt overflowed the mpz_t limb counter and aborted." GMP stores the size of a big integer in a fixed-width field. A number this large exceeded it. Devin rebuilt sqrt three times, and the final version used GPU-accelerated NTT multiplication, which finished in 88 minutes. The characters phase around it took 12 hours.

Before trusting any of it, the team ran a full factorization of a 344-digit number, C344, end to end as a correctness check while the RSA-260 Krylov phase was still running. It came out as a 136-digit prime times a 209-digit prime. A pipeline that factors a number you can verify independently is a far better test than any unit test on one stage, and the check cost almost nothing next to the main run.

The steering log

This is the section to read twice. Lu reports that he "drove several parallel Devins," with an average of three and a maximum of 18 concurrent sessions over the three weeks. His own side of the conversation was 82,702 words across 3,328 messages in 192 sessions. That is about 17 messages per session and 25 words per message: short, frequent corrections, not long specifications. Agents themselves started 101 child sessions, and 36 of those ran with no human message at all.

He describes his job as supplying "executive function": keeping the goal hierarchy straight, "recognizing when Devin was doing something unproductive and redirecting ('you don't need to take that measurement')," spotting repeated inefficiencies ("you can amortize this setup work"), and pointing at directions nobody had tried. He also writes that progress came fast enough that "I (and even Devin itself) could barely keep up."

Put those numbers next to the phase table and a pattern shows. The human was not needed to write kernels, run the queue, or recover from preemptions. The human was needed to decide what not to do. A three-week run offers thousands of plausible measurements, refactors, and side quests, and an agent with a good verifier will happily pursue all of them because each one looks locally productive. Pruning that tree is the scarce input. I made a version of this argument about short tasks in Stop Agents Building the Wrong Thing; RSA-260 is the same failure mode stretched over three weeks, where each unpruned branch costs GPU-days instead of minutes.

What it says about RSA

Very little that is new, and the writeup says so. RSA-1024, at 309 digits, is by Cognition's standard GNFS scaling "merely 78x more computation than RSA-260," which they put at roughly $30M. That is a real number for a well-funded attacker, and it is also why NIST's SP 800-131A transition disallowed 1024-bit RSA for new signatures back in 2013. Lu writes that "the fact that RSA-1024 is insecure is not news." RSA-2048 "remains roughly a billion times harder than RSA-1024," so the keys protecting most TLS today are not affected by this result.

The shift is in who can run the attack. Cognition claims costs about 10 times lower than the previous public state of the art, on rented GPUs rather than specialized hardware or a national lab's CPU allocation, driven by someone who says he "did not learn as much about NFS or GPU programming" as a specialist would have. If you still have 1024-bit RSA anywhere, the budget line for breaking it just moved into commercial range.

What a three-week agent run needs

Strip away the number theory and the project reads like a checklist for any long agent job. None of these items is exotic. Together they are what separated a working three-week run from an expensive pile of half-finished branches.

• A hard oracle per stage. Relations per second, a factor that divides N, a C344 that factors correctly. Agents iterate well only where a machine can say yes or no.
• Units of work sized to lose. Ten-minute sieve workunits made failure cheap and hardware interchangeable. Where the math forbids that, as in the Krylov phase, checkpoints recreate it.
• Verification running beside production. bwccheck on every checkpoint pair and the C344 run caught problems while there was still time to redo an interval instead of the whole phase.
• Hot-swappable components. Faster sievers shipped mid-run because the queue did not care which binary took the next workunit.
• A human who prunes. 3,328 short messages, mostly telling agents what to stop doing. That is the part of the loop nobody has automated, and on this evidence it is the part that decides the bill.

The headline will be the 260 digits. The more durable result is the log: a three-week, 4,900 GPU-day computation that ran with an average of three agent sessions and one person typing short corrections, with every phase designed so a machine could check the work. That is a harness pattern, and it transfers to jobs that have nothing to do with primes. I wrote about the general shape in Harness Engineering; this is the most concrete public case of it working at scale that I have seen.