Devin Factors RSA-260 on GPUs for $400K, 10x Cheaper Than the Previous Record

A Cognition researcher used Devin agents to factor RSA-260, a 260-digit decimal number, into its prime factors. It is a new record among publicly solved RSA Factoring Challenge problems: the previous one, RSA-250, was set in February 2020. The computation took about 4 900 GPU-days (13.5 GPU-years) and cost roughly $400K at market prices. By the author's estimate, that is 10x cheaper than the previous public level.

The author stresses that there is no algorithmic breakthrough. The work used the general number field sieve (GNFS), the most efficient known method for numbers larger than about 100 digits. The base is a heavily reworked CADO-NFS. The gain came, in his words, from "good old-fashioned performance engineering" tailored to the GPU memory layout. There is no quantum computer involved, and nobody tried to guess 130-digit primes by hand.

Where the compute came from

Cognition's clusters for LLM training and inference are built from NVL72 racks, each nominally holding 18 nodes connected by fast NVLink. The scheduler packs jobs into racks, and a free node is left over somewhere: a spare in case of failure, an odd number of machines for an even-sized job, 17 nodes instead of 18. Together this adds up to a single-digit percentage of total capacity.

The researcher configured the scheduler to fill these gaps with single-node jobs at the lowest priority. What was missing was a source of jobs that can be interrupted at any moment. Lattice sieving fit perfectly: it parallelizes into billions of small units of work and is safe to preempt instantly. All previous public GNFS records ran this stage on CPUs only, because branching and irregular memory access got in the way on GPUs.

How Devin worked

The prompt went out on August 13 at 0:11:58 Pacific time. The task: build a drop-in replacement for CADO-NFS's CPU sieve las that is faster than the original. Two hours later, the author added a requirement to pull in the RSA-250 parameters and went to sleep. By morning, after another seven hours of iteration, Devin had it working.

The agents then optimized the rest of the pipeline. Over three weeks, an average of 3 sessions ran in parallel, with a peak of 18. The author checked in on the loop every couple of hours. Devin set up experiments itself, tuned the sieving and linear algebra parameters, debugged the code, and launched computations on the cluster. The author admits he does not understand the mathematics in depth and describes his own role as setting priorities, running benchmarks, and catching mistakes in the direction of the work in time.

Almost every component was rewritten: a GPU version of the first stage of polynomial selection, the GPU sieve glas, faster dup/purge and merge/replay, a new GPU implementation of the block Wiedemann algorithm, and GPU-sqrt. Only cado-nfs.py, polyselect_ropt, makefb and dup1 were left untouched.

Project numbers

• About 4 900 GPU-days in total, roughly $400K.
• Polynomial selection: 643 GPU-days (anomalously high because of operator errors).
• Sieving: 3 813 GPU-days.
• Linear algebra: 467 GPU-days, with about 7% lost to failures and preemption by higher-priority jobs.
• 8.3 billion linear relations over GF(2) were obtained.
• The computation ran on a few percent of cluster capacity, with no marginal cost.

What this means for real keys

By standard GNFS scaling, RSA-1024 requires only 78 times more computation than RSA-260. The author estimates the cost at roughly $30M per number and allows for another 2x reduction after further refinements. Hyperscalers and large AI labs are theoretically capable of this. But 1024-bit RSA was deprecated back in 2013, and suspicions about intelligence agencies' capabilities have circulated since the mid-2000s.

RSA-2048, the current standard, remains roughly a billion times harder than RSA-1024 and is unaffected by this work. Three things have changed: the price, the number of potential actors (this takes GPUs, not specialized hardware), and the fact that people who are not cryptographers can now take part in optimizing factorization.

What teams should do

Security teams should check whether any 1024-bit keys and certificates remain in their infrastructure, including embedded devices and old internal services. For them, migration is long overdue. There is no urgency with 2048-bit keys, but this result is worth factoring into threat models for long-lived data.

For engineering and research groups, the takeaway is broader. Single-node preemptible jobs can use the fragmented leftovers of a cluster. Autonomous coding agents can take on a combination of narrow theory and GPU optimization that previously required a team of specialists working for months.