RSA-260 Falls to 4,900 GPU-Days and a Coding Agent

At 01:48:57 UTC on 3 September 2026, a heavily modified copy of an open-source factoring program printed two 130-digit prime numbers. Multiplied together they give RSA-260, a 260-decimal-digit semiprime published by RSA Laboratories in 1991 and unfactored for 35 years.

We checked it before writing anything else. The exact integers came from the raw wikitext of Wikipedia's RSA numbers page, to avoid transcription loss. In Python, `p * q == N` exactly. Both factors are 130 digits and 431 bits, and both pass 64 rounds of Miller-Rabin as strong probable primes. A million of those multiplications took 0.2019 seconds, so 0.202 microseconds each.

Finding them took roughly 4,900 GPU-days. That is 423,360,000 GPU-seconds of search against 0.202 microseconds of verification, a ratio of about 2.1 x 10^15. Public-key cryptography is that ratio and very little else.

Eric Lu did it. He works at Cognition, the AI startup behind the Devin coding agent, and is described as an engineer there by Scientific American; his own write-up gives no title. He used the general number field sieve, the same algorithm as every record since RSA-130 fell to it in 1996, running a GPU-rewritten fork of CADO-NFS, the LGPL 2.1-or-later codebase written by the CADO-NFS development team and hosted by INRIA. Most of the rewriting and most of the operations were done by Devin, Cognition's coding agent. The previous record, RSA-250 at 829 bits, was set in February 2020 by a team of six academic cryptographers and took about 2,700 CPU core-years.

Some of the coverage has this wrong, so: RSA-260 is a challenge number, not anybody's key. Nothing was decrypted and no system was compromised. The RSA Factoring Challenge ended in 2007 with the remaining prizes retracted, so no money changed hands. The verb is "factored." And the result moves RSA-2048 by nothing at all, which is an arithmetic claim, worked out below.

Lu's technical write-up, published 9 September, opens its methodology section by denying a rumour that had already spread: "Contrary to some circulating claims, I did not factor RSA-260 by guessing and checking 130-digit prime numbers by hand. Cognition also has not yet built a multi-thousand-qubit quantum computer." Scientific American had speculated that his "unclear methodology boiled down to randomly sampling primes and dividing each from RSA-260 until one of them divided evenly."

That method is worth pricing out. There are about 9.3 x 10^126 primes between 2^430 and 2^431. A trillion trial divisions per second, run for the age of the universe, covers about 4.4 x 10^29 of them. You would need to repeat that 2 x 10^97 times.

Before any of that was public, Emmanuel Thomé of INRIA, part of the RSA-250 team, told Scientific American on 4 September that factoring RSA-260 was "expected to be roughly three times as [computationally] expensive as RSA-250," and that the claim was "certainly feasible," if "not exactly low-hanging fruit." Our own computation from the sieve's complexity function puts the ratio at 2.6x. Thomé called it right from the algorithm alone, five days before there was a paper to read.

Lattice sieving ate 78 percent of the compute

The number field sieve has four stages. What each one cost in this run is the quickest way to see what it does.

Polynomial selection picks the polynomial that defines the number field everything else happens in. It buys nothing except a constant factor on the next stage, and it is worth spending a few percent of the budget on. Lu spent 643 GPU-days here and says plainly it was too much: the number is "anomalously high basically due to operator incompetence," and the intended range could have been searched "in 1 day rather than 2.5." The winning polynomial was degree 6, skew 3,226,459, chosen from 83,557,723 candidates.

Lattice sieving is the bulk: 3,813 of the 4,900 GPU-days, just under 78 percent. The goal is to find enormous numbers of relations, which Lu describes as "sparse linear relations over GF(2), where here (suppressing some details) the vector entries represent the parities of prime exponents in the prime factorization of a smooth number." The run produced 13,849,985,589 raw relations across 632,249 work units of about ten minutes each, which filtered down to 8,298,749,059 unique ones. Sieving is embarrassingly parallel and each work unit is independent, which matters more than it sounds like it should.

Linear algebra takes those relations, packs them into a sparse matrix over GF(2), and finds a dependency in its null space. The matrix here was 656,182,601 by 656,182,189 with 98,431,741,898 nonzeros. This stage has the opposite hardware profile to the sieve: "Unlike sieving, linear algebra requires all of its workers to remain up. Consequently it was fatally preempted frequently." Lu used block Wiedemann with m = n = 512 precisely because it relaxes the communication requirement, and still had to write a placement script to keep reshaping the job around whatever nodes the scheduler left him.

The square root turns the dependency into a congruence of squares mod N, takes a GCD, and hands you the factors. It is normally the trivial step. Here the rational product ran to 1.76 x 10^11 bits and, in Lu's words, "sqrt overflowed the mpz_t limb counter and aborted." Devin rebuilt it three times, ending on GPU-accelerated NTT multiplication, and the working version finished in 88 minutes. A factoring record nearly stalled on an integer overflow in a library's bookkeeping counter.

The split between the sieve and the matrix decided what kind of machine this run needed. Sieving can eat the fragments of a cluster nobody else can use, because losing a work unit costs ten minutes. The matrix cannot. Lu says the whole thing "ran at no marginal cost on spare or fragmented compute that couldn't be used for other purposes," on GB200, GB300 and B200 nodes in NVL72 racks amounting to "a single-digit percentage of our cluster."

Seven hours from the first prompt to a working GPU siever

The origin has a timestamp. "At August 13th 0:11:58 Pacific time I aimed Devin at producing a drop-in replacement for `las`," Lu writes, referring to CADO-NFS's lattice siever. He handed it keys to a single GPU box, told it to iterate until it beat the CPU version, added two hours later that it should handle RSA-250 parameters, and went to sleep. "I woke up to find that, after another 7 hours of iteration, Devin had succeeded."

Over the three weeks that followed, Devin wrote a GPU stage-1 polynomial selector, the GPU siever, a GPU block Wiedemann implementation, the GPU square root, parallelised duplicate removal and a fused merge/replay step. Four components went untouched, including the top-level `cado-nfs.py` driver and the stage-2 polynomial optimiser. Lu ran an average of 3 and a maximum of 18 concurrent sessions, checking in "once every couple of hours." Devin's own accounting, which Lu quotes: 82,702 words from Lu across 3,328 messages in 192 of the 233 sessions, with 101 child sessions started by agents themselves and 36 receiving no human intervention at all.

Lu reports "essentially no algorithmic advancements," and says the work "required only 'good old performance engineering' to take advantage of the preposterous memory systems of the GPU." He is equally direct about the limits of the autonomy:

"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."

The list of what the human still had to supply is the most practical part of the post: setting a hierarchy of goals and holding scope, recognising unproductive directions, spotting repeated workflow inefficiencies, suggesting untried approaches ("make sure the GPU never blocks on the CPU", "can you use NVLink SHARP here?"), and catching the agent giving up too early. The single contribution he rates highest is not technical: "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." That matches what Shopify described when it rebuilt its mobile apps, where the reusable piece was the harness the agents ran against rather than the code they produced.

"I noticed that the further the codebase got from upstream CADO-NFS, the more confused the agents became," Lu writes. "This could be attributed to accumulating complexity, but I wonder whether CADO-NFS's presence in pre-training is also relevant here." Nobody has tested that. If it holds, it explains a lot about why agents are fluent in some codebases and lost in others.

The pipeline was general enough to keep going. Between 3 and 8 September the same code factored 2^1277 - 1, a 385-digit target that the amateur factoring community had chased for years, in 2,423 GPU-days. Wikipedia's integer factorization records page now lists it as the special number field sieve record. We verified that one too: the three published primes of 106, 117 and 163 digits multiply back to 2^1277 - 1 exactly.

Renting the same 117,600 GPU-hours costs two to three times more

Lu puts the run at "about $400k at current market prices," on a stated assumption of $3.50 per GPU-hour. The assumed rate is doing most of the work in that sentence, the way it does in agent-loop cost math, so here is the same 117,600 GPU-hours against list prices we read on the vendors' own pages on 16 September 2026.

These are all honest numbers describing different situations. Lu's $3.50 is roughly a committed-reservation rate; CoreWeave advertises up to 60 percent off on-demand for committed usage, which puts its $10.50 GB200 at about $4.20. At retail on-demand list, the same work is $0.8M to $1.2M, two to three times Lu's number. And his own stronger claim, that the run ate fragments his cluster could not otherwise sell, makes even $411,600 an overstatement. For anyone who already owns a fleet, the binding constraint was never the price.

Lu also reports the run as roughly ten times cheaper than a CPU equivalent. That ratio comes from his own table, comparing an estimated $4.91M in CPU cost against $414k in GPU cost, and both sides rest on assumed rates ($0.08 per CPU core-hour, $3.50 per GPU-hour) with the CPU core-year figure itself extrapolated from RSA-250. It is an estimate resting on an estimate, and it has error bars in both directions.

RSA-2048 is 9 x 10^10 times the work

The general number field sieve runs in L_N[1/3, c] time with c = (64/9)^(1/3), about 1.923, which spelled out is:

`exp( c (ln N)^(1/3) (ln ln N)^(2/3) )`

Sub-exponential, which is why RSA-512 fell in 1999 rather than never. Super-polynomial, which is why renting more GPUs does not get anyone to RSA-2048. The exponent grows as the cube root of the logarithm, so the curve looks gentle from close up and brutal from far away. By our arithmetic on that formula, ten more decimal digits costs about 2.5x, and fifty more costs about 86x.

Scientific American told its readers that "with the hardness increasing exponentially as the numbers grow, no regular computers are likely to break RSA encryption anytime soon." The conclusion is right and the stated reason is wrong. Sub-exponential scaling is why RSA-1024 is now within reach of a well-funded private actor while RSA-2048 is not within reach of anyone.

We computed the scaling ratios ourselves, from the L-function alone with no fitted constants, and they land on Lu's published table:

The extrapolation in the announcement survives an independent recomputation.

For RSA-1024 that gives Lu's estimate of about 1,050 GPU-years, or 9.2 million GPU-hours. At his $3.50 that is $32.2M, which is where his "on the order of $30 million per number" comes from; he adds that "with a bit more optimization" it would likely be "substantially less." At Lambda list it is $61.5M, at CoreWeave list $79.1M. A defensible range is $15M to $80M per key, which is large-corporate or state money rather than national-programme money. Lu is careful that this is not news about RSA-1024's weakness, which the TWIRL and Bernstein hardware proposals raised in the mid-2000s. What changed is the cost, the number of parties who can try (GPUs rather than custom silicon), and "the relative ease with which non-cryptographers can now work on speeding up factoring." He notes 1024-bit RSA was deprecated in 2013.

RSA-2048 is where the same curve stops being a cost question. Our multiplier of 9.05 x 10^10 works out to 1.22 x 10^12 GPU-years. Dedicate one hundred million GPUs to it, far more than any operator is known to run, and it finishes in about 12,000 years.

Counted in hardware generations instead: log2(9.05 x 10^10) is 36.4 doublings. At an 18-month doubling that is 55 years of progress before RSA-2048 costs what RSA-260 cost this month. At 24 months, 73 years. Per-transistor cost improvement has been slowing rather than accelerating.

Estimates of the gap vary with the approximation used. John D. Cook derived 2^34, roughly 10^10, from a bit-security formula; Lu's table and our L-function both give around 9 x 10^10. The spread is about 5x and neither is wrong, because both are order-of-magnitude statements about the same curve. Against a gap of 10^10 or 10^11, a 10x engineering win on the sieve is a rounding error.

The largest number reliably factored by Shor's algorithm is 21

More GPUs will not move the date. New mathematics would: an index-calculus method with a smaller exponent, or a genuinely new approach, would reset the curve rather than shift a point along it. Nothing of the sort is in the literature, and Lu's contribution explicitly is not one.

The other route is quantum, and the honest position there means holding two real numbers next to each other. Craig Gidney's May 2025 resource estimate puts RSA-2048 at under a week on fewer than a million noisy qubits, a twentyfold reduction on the 2019 Gidney-Ekera estimate of 20 million qubits in eight hours. Meanwhile IBM's roadmap targets Starling, its first fault-tolerant machine, for 2029 at 200 logical qubits, and Blue Jay, at 2,000 logical qubits, for 2033 or later (IBM's own wording is "By 2033+").

Against those projections, the largest number reliably factored by Shor's algorithm remains 21, in 2012, per Wikipedia's integer factorization records page citing Martín-López et al. in Nature Photonics. Larger claimed quantum factorisations used annealing or adiabatic methods with heavy classical preprocessing. Peter Gutmann and Stephan Neuhaus made the point most memorably in an IACR ePrint titled "Replication of Quantum Factorisation Records with an 8-bit Home Computer, an Abacus, and a Dog", in which they match or exceed the published records using a 1981 VIC-20, an abacus, and a dog. It is a satire, and it is also a serious methodological critique of how those records are counted.

The 2035 deadline has nothing to do with any of this

NIST SP 800-57 Part 1 Rev 5, Table 2, puts RSA-2048 at 112 bits of security strength and RSA-3072 at 128. NIST IR 8547, "Transition to Post-Quantum Cryptography Standards," sets the dates: RSA at 112-bit strength is deprecated after 2030 and disallowed after 2035, and RSA at 128 bits or above is disallowed after 2035 as well. Same for ECDSA and for finite-field and elliptic-curve Diffie-Hellman.

The disallowance applies to RSA at every key size, including 3072 and up. Moving to a longer modulus does not buy you past 2035, because the deadline is set by quantum risk rather than by classical factoring progress. Nothing in the RSA-260 result changes a date in that document.

IR 8547 is still an Initial Public Draft as of 16 September 2026; its comment period closed in January 2025 and `csrc.nist.gov/pubs/ir/8547/final` returns a 404. The standards it points at are done: FIPS 203 (ML-KEM), 204 (ML-DSA) and 205 (SLH-DSA) were finalised in August 2024, and NIST's position is that they "can and should be put into use now." FN-DSA (Falcon) and HQC were selected and remain in standardisation, not final, as of NIST's own page update on 5 August 2026.

The siever code has not been published

The factorization is trivially verifiable and we verified it. The cost is not. Neither `glas` nor `gps1`, the GPU siever and polynomial selector, has been published; we found no public repository, and CADO-NFS's LGPL terms impose no source-release obligation absent distribution, so internal use does not trigger one. Whether Cognition intends to release the code is not addressed in the post. Nobody outside the company can reproduce the performance numbers. Paul Zimmermann's factoring records page still listed RSA-250 as the GNFS record when we checked on 16 September, which is almost certainly an un-updated page rather than a dispute, but no one has ratified anything.

Whose record it is

Lu is unusually clear-eyed about the credit question, and his framing is better than any adjudication of it:

"My name is on the result, but it's not clear to me how to apportion credit among myself, Devin, the hardware, and the world at large. For programming tasks, I think of current models and agents somewhat like 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."

He also notes what it cost him: "I did not learn as much about NFS or GPU programming as I could have expected to had I done this on my own." He says he does not understand most of the underlying mathematics, and describes his grasp of the components as that of "a mid-level car hobbyist."

RSA-250 was dedicated to Peter Montgomery, who died ten days before it was announced. His algorithms are still inside the code that factored RSA-260.

“It is interesting to consider what he needed me for. Somehow, the answer seems to be: still a lot.”

Reporting by TechCurrent Staff · TechCurrent