Inside the RSA-260 Factorization: GPU-Accelerated GNFS and the Role of Devin

When Eric Lu announced the factorization of RSA-260 on September 3, 2026, he published a valid factor but almost nothing about how it had been found. My previous RSA-260 article therefore separated two questions: could the result be verified, and what method had produced it? Only the first had a firm answer.

The Missing Method Is No Longer Missing

On September 9, Lu published a detailed account through Cognition. The second question now has an answer, at least according to the team that performed the computation: RSA-260 was factored with the General Number Field Sieve (GNFS), using a heavily modified, GPU-accelerated version of CADO-NFS developed and operated with multiple Devin agents.

There was no quantum computer and, by Lu’s own account, no new factoring algorithm:

“I report essentially no algorithmic advancements”
Eric Lu, Cognition

That distinction matters. A better algorithm could change how factoring difficulty grows with key size. A better implementation reduces the practical cost of the same mathematics. Cognition reports the second kind of advance: established GNFS techniques were adapted to modern GPU memory systems and otherwise fragmented computing capacity.

This follow-up focuses on the information that was missing from the first announcement: the software, the resources, the role of Devin, and the limits of the larger security claims.

What Cognition Actually Built

GNFS is not one monolithic calculation. It is a pipeline combining polynomial selection, relation sieving, filtering, sparse linear algebra, and square-root extraction. Cognition did not replace that sequence. It changed where much of the work ran and optimized almost every stage around it.

The starting point was CADO-NFS, a mature open-source implementation. Its modular design gave the Devin agents established interfaces, reference outputs, and CPU programs against which GPU replacements could be tested.

According to Lu, the modified pipeline included:

gps1, a GPU adaptation of CADO-NFS’s first polynomial-selection stage, incorporating kernel techniques from msieve
glas, a GPU lattice siever replacing the CPU-based las
optimized coordination, deduplication, filtering, merging, and replay programs
a GPU-oriented block Wiedemann implementation for sparse linear algebra
a GPU-accelerated square-root stage and new run scripts

The central component was the lattice siever. It searches for billions of useful mathematical relations that can later be combined. The work divides naturally into independent units, but each unit performs many reads and writes at irregular memory locations.

That pattern is difficult for GPUs, which work best when many threads follow similar instructions and access predictably arranged data. The challenge was not to compile CPU code for CUDA. It was to reorganize the workload until the GPU’s much greater memory bandwidth outweighed the cost of branching and scattered access.

The mathematics remained GNFS. The operational system around it changed substantially.

Why Spare AI Compute Was a Good Fit

Cognition says the project began while its research team was improving the allocation of disaggregated compute. Large AI workloads prefer tightly connected groups of machines inside NVLink-equipped racks. Real scheduling leaves gaps: one node may remain idle, a job may require an even number of machines, or capacity may be reserved for failover.

Those gaps represented a single-digit percentage of Cognition’s cluster. They were awkward for training jobs, but well suited to relation sieving.

Fragmented GPU capacity reused for independent GNFS sieving workloads

Sieving is described as embarrassingly parallel because billions of small work units can run on separate machines with little coordination. A low-priority unit can be interrupted and rescheduled without invalidating the rest of the computation. The siever could therefore fill small scheduling holes left by larger AI workloads.

Lu says the factorization ran at “no marginal cost” (Cognition). This does not mean that the hardware, energy, or computation was free. It means the run reportedly used capacity that Cognition already owned and could not assign productively to higher-priority jobs at those moments.

The RSA-260 Run by the Numbers

Lu says the first prompt asking Devin to build a GPU lattice siever was issued on August 13. Polynomial selection began on August 18, and the factors were produced on September 3. The recorded run took about 15.6 days, while the broader engineering effort lasted roughly three weeks.

Stage	Reported compute	Share	Main output
Polynomial selection	643 GPU-days	13.1%	Candidate polynomials
Lattice sieving	3,813 GPU-days	77.5%	13.85 billion raw relations
Linear algebra	467 GPU-days	9.5%	Dependencies in a 656-million-row sparse matrix
Total	4,923 GPU-days	100%	About 13.5 GPU-years of aggregate work

The reported stage totals reproduce Cognition’s rounded market estimate:

gpu_days = 643 + 3_813 + 467
market_price_per_gpu_hour = 3.50
market_equivalent = gpu_days * 24 * market_price_per_gpu_hour

print(gpu_days)                       # 4923
print(round(gpu_days / 365, 1))      # 13.5 GPU-years
print(f"${market_equivalent:,.0f}")  # $413,532

Cognition summarizes this as about 4,900 GPU-days and $400,000 at market prices. The latter is a market-equivalent compute estimate, not a bill or a complete project budget. It excludes the distinction between owned spare capacity and rented GPUs, and says nothing about hardware acquisition, power, cooling, human work, or Devin’s development cost.

GPU-days are aggregate work, not elapsed time. Parallel execution compressed the run into just over two weeks, with available capacity varying across B200, GB200, and GB300 systems.

What Happened Inside the Pipeline

The detailed timings reveal where the computation succeeded and where it remained inefficient.

Polynomial selection consumed far more work than planned. Lu attributes the 643 GPU-days to misread early benchmarks and unproductive search ranges. The total is therefore not presented as a theoretical minimum.

Sieving remained the dominant expense. It ran for about 7.9 days, generating 13.85 billion raw relations. After removing roughly 40% duplicates, 8.30 billion unique relations remained. The team upgraded the live siever twice, reporting gains of approximately 14% to 17% on the measured GPU types.

Filtering transformed those relations into a sparse binary matrix of about 656 million rows by 656 million columns, with 98.4 billion non-zero entries. The values represent whether relevant prime exponents are even or odd, so the linear algebra operates over GF(2), using only zero and one.

The block Wiedemann stage then searched the matrix for dependencies. Unlike sieving, its workers had to stay available together and communicate. Higher-priority jobs repeatedly pre-empted allocations, making checkpointing and job placement essential.

Even square-root extraction failed at first. A roughly 176-billion-bit intermediate product overflowed an internal mpz_t limb counter. Lu says Devin rebuilt the component three times, the final GPU-accelerated version completed its main calculation in 88 minutes.

This is what a record computation looks like in practice: measurements, failures, restarts, validation checks, parameter changes, and resource decisions, not one elegant command.

What Devin Did, and What Still Required a Human

Cognition presents the result as evidence that an AI software-engineering agent can contribute to specialized computational research. Its report supports a substantial role for Devin, but not the simpler story of an autonomous AI independently deciding to factor RSA-260 and completing the project alone.

Lu first asked Devin to create a drop-in GPU replacement for las. According to his account, an initial version surpassed the CPU reference after about nine hours. Over the following weeks, parallel Devin sessions optimized components, benchmarked changes, debugged failures, tuned parameters, prepared scripts, and managed cluster jobs. An average of three sessions ran concurrently, with a maximum of eighteen.

What did Devin still need a human for? Lu’s concise answer is “still a lot” (Cognition). He reports sending 3,328 messages across 192 of the 233 sessions used for the project. His role included defining priorities, establishing comparable benchmarks, detecting unproductive directions, organizing results, and deciding when evidence was trustworthy enough to proceed.

Verification remained central. While RSA-260’s linear algebra was running, the team completed an end-to-end factorization of a smaller 344-digit special-form number. It also checked stored linear-algebra states with CADO-NFS’s existing tools. One check failed after about fourteen hours, forcing the affected interval to be rerun.

The practical lesson is balanced. Agents can accelerate implementation and experimentation, but faster iteration increases the need for reference code, measurable objectives, independent checks, and informed human supervision. CADO-NFS supplied the stable, human-designed decomposition that made parallel agent work possible.

A Tenfold Cost Claim, Not a Mathematical Breakthrough

Cognition calls glas the highest-performance GPU lattice siever and estimates that its pipeline cuts factoring costs by about ten compared with the previous public state of the art.

This is a performance and cost claim, not a change to GNFS’s theoretical complexity. The gain comes from GPUs, software optimization, scheduling, and pricing assumptions. Factoring cost still rises extremely quickly as the modulus grows.

There is also no earlier public RSA-260 run for a direct comparison. Cognition scales the CPU cost of the RSA-250 record to estimate what RSA-260 would have required with the earlier approach, then compares that projection with its GPU accounting.

The publication includes detailed parameters, timings, relation counts, and matrix dimensions. At publication time, however, it does not link to the modified pipeline’s source code. The factors are independently verifiable, and the performance advantage is a detailed claim by the team, not yet an independently reproduced result.

What the RSA-1024 Estimate Really Means

The most security-relevant extrapolation concerns RSA-1024. Using standard GNFS scaling, Lu estimates that a 1,024-bit modulus would require about 78 times the RSA-260 computation. At the same assumed price of $3.50 per GPU-hour, the appendix gives $32.3 million, rounded to $30 million in the main article.

That is not an observed attack cost. It assumes that GNFS follows the heuristic scaling model, that this implementation remains usable at the larger scale, and that the same market price is meaningful. It also applies to one chosen modulus, not a reusable universal break.

The estimate suggests that a GPU-rich organization might contemplate attacking one legacy RSA-1024 key. It does not mean Cognition has factored RSA-1024 or that an organization without the software, expertise, and cluster access could reproduce the estimate.

Nor does it change current guidance. NIST already disallows RSA moduli below 2,048 bits for generating digital signatures and for RSA-based key establishment. Cognition refines the economics of an obsolete size. It does not redefine modern RSA hygiene.

Why RSA-2048 Remains Out of Reach

Cognition’s extrapolation places RSA-2048 about a billion times beyond RSA-1024 under the same GNFS model. A projection over such a distance is not a precise budget, but the order of magnitude is the point: a tenfold engineering improvement does not bridge a billionfold gap.

The conclusion of the previous RSA-260 article therefore remains intact. This record matters for computational number theory, legacy-key economics, and AI-assisted performance engineering. It is not evidence of a practical classical attack against correctly generated RSA-2048 keys.

That assessment would change if someone found a fundamentally better factoring algorithm. Cognition explicitly reports no such discovery.

Facts, Measurements, and Projections

The disclosure is easiest to interpret when its different kinds of evidence remain separate:

Statement	Status	Basis
The factors multiply to RSA-260	Independently verifiable	Direct arithmetic, shown in the previous article
GPU-accelerated GNFS based on CADO-NFS was used	Reported methodology	Lu’s technical account and parameters
The run consumed about 4,900 GPU-days	Reported measurement	Cognition’s stage accounting
The compute is worth about $400,000	Cost estimate	GPU-days multiplied by an assumed market price
The pipeline is about ten times cheaper	Comparative claim	GPU result compared with a scaled CPU baseline
RSA-1024 could cost about $30 million	Projection	Heuristic GNFS scaling from this run
RSA-2048 is not meaningfully threatened	Security conclusion	Remaining scaling gap and no new algorithm

A verified factorization does not automatically verify every performance estimate or extrapolation published alongside it.

Conclusion: Engineering Leverage, Not Cryptographic Collapse

The previous RSA-260 article ended with an open question about the method. Cognition now fills that gap: classical GNFS, a substantially modified CADO-NFS pipeline, modern GPUs, opportunistic scheduling, and multiple Devin agents directed by Eric Lu.

The result is significant because it shows how much leverage can still be extracted from established mathematics through better hardware use, performance engineering, open-source foundations, and AI-assisted iteration. It also shows the limits of the autonomous-agent narrative: Devin reportedly wrote and optimized substantial parts of the system, while human prioritization, benchmark design, judgment, and verification remained essential.

For security teams, the practical response is modest but important: identify and retire any remaining RSA keys below 2,048 bits, confirm that key-generation and crypto-agility plans are sound, and avoid treating this record as evidence that RSA-2048 has suddenly become breakable.

The measured boundary moved, especially for legacy key sizes and GPU-rich adversaries. Modern RSA did not collapse with it. The factorization is verified, the resource figures are team-reported measurements, and the costs for larger keys remain projections.