I computed a number nobody had computed

In August 2025 two mathematicians, Ayla Gafni and Terence Tao, published a paper that settled an old question of Erdős about the gaps between prime numbers. Near the end of it, they mention a constant — a specific number that their result depends on. They say they think it's somewhere between 2.7 and 2.8. They say the formula for it converges very slowly. Tao's blog post about the paper adds that he only ran a simple brute-force search, and that he suspects computing it properly is exponentially hard.

Then two people in the blog comments disagreed with each other about what the value was. One of them reckoned it was below 2.6.

So: an actual open question, with a specific numerical answer, that nobody had worked out. Not in the paper, not on the Erdős Problems website, not in the encyclopedia of integer sequences, not anywhere.

I worked it out. It's 2.74161075.

This is what that number means, how I checked it, and what happened when I tried to use it to predict prime numbers — which is what I actually wanted it for.

Who did the work

Before anything else, because it changes how you should read the rest: I directed this work, but I didn't do it with my own hands. The derivations, the code, the sieving, the checks and the hostile review were all done by AI agents working under my direction. I'd rather say that here than have it surface later as a gotcha, and honestly the verification story below is more interesting when you know how it was produced, not less.

The division of labour, since people ask. Claude Fable 5 ran as the director: setting the research direction, deciding what was worth attacking, reviewing every result that came back, and writing the interpretation. Claude Opus 5 did infrastructure, creative ideation — the "what if we reframed it like this" moves — and the adversarial reviews. Claude Sonnet 5 did implementation and the disciplined, repetitive experimental work, which is most of the hours and none of the glamour.

The part that actually mattered wasn't the model choice, though. It was the shape of the work. Everything got delegated to sub-agents running in parallel, each handed a self-contained brief that stood on its own without the surrounding conversation. And critically, separate agents were tasked with attacking results rather than supporting them. Not "review this" — break this. The hostile reviewer that caught the eleven-digit error in Part 4 was one of those. So was the agent that then went and caught an error in the reviewer's own correction.

The other habit that earned its keep: novelty checks ran before the investment, not after. An agent whose entire job was to find prior art, run first, on every candidate direction. That rule exists because an earlier round of this project spent two full days carefully re-deriving a paper from 1970.

I want to be plain that this is a workflow, not magic. The agents produced several confident wrong answers over the course of this — fluent, well-argued, and wrong. The eleven-digit headline in Part 4 was one of them. What made the final number trustworthy wasn't that a model computed it. It was that other models were paid to hate it, and one of them succeeded.

Part 1: What the number counts

Gaps, and why the numbers inside them are composite

Primes get further apart as they get bigger. Between 89 and 97 there's a gap of 8, and the six numbers in between are all composite — none of them is prime.

Fine. But here's the question that turns out to matter: why is each of them composite?

Every composite number has a smallest prime that divides it. Let's list them:

Every single one is knocked out by a prime smaller than 8 — and 8 is the size of the gap.

The way I ended up picturing it: imagine a row of lockers, and a set of janitors numbered 2, 3, 5, 7, 11 and so on. Janitor 2 opens every 2nd locker. Janitor 3 opens every 3rd. And so on. If the janitors numbered below the gap size can between them open every locker in the row, then the whole gap is explained by small primes doing their ordinary job. Nothing else is needed.

Now compare the gap from 139 to 149, which has size 10:

Eight of those are the usual small-prime rubbish. But 143 is 11 × 13 — and both of those factors are bigger than the gap size of 10. No janitor numbered under 10 can open that locker.

143 is still composite. But it's composite for a reason that has nothing to do with small primes. A number like that gets called rough.

The question, and the answer

Erdős asked: does every big gap have to contain one of these rough numbers?

Gafni and Tao proved that almost every gap does. That part is a theorem — it stands on its own, no assumptions attached.

The gaps that don't — the ones where small primes genuinely explain everything — get rarer and rarer as the numbers get bigger. And here the paper says something more precise, but on a weaker footing: assuming a famous unproven conjecture, the rate at which they thin out is

fraction of gaps near x that small primes fully explain ≈ c ÷ ln(x)

where ln is the natural logarithm — the thing that grows very, very slowly. ln of a billion is only about 21.

That distinction matters and I'll come back to it. The existence result is proved. The formula with c in it is conditional. My computation lives entirely in the second, weaker category.

c is the number in front. That's the whole thing. That's what I computed.

To put it in concrete terms: below 10 million, 18.3% of gaps are the fully-explained kind. By 10 billion it's down to 12.3%. It keeps dropping forever, but slowly, because logarithms are slow.

Part 2: Why it was stuck, and the one idea that got it unstuck

The textbook way to compute c means checking every possible starting position of a gap against all the relevant small primes at the same time. The number of positions you have to check is the product of all the primes below the gap size.

That product explodes:

• gap size 24: 223 million positions
• gap size 30: 6.5 billion positions

and you need to go far past 30. This is where brute force dies. It's why the authors gave a range instead of a number.

Here's what gets you out, and it's an idea any engineer will find familiar: the janitors are independent of each other. Knowing which lockers janitor 3 opens tells you nothing whatsoever about which ones janitor 5 opens.

That's a real theorem (the Chinese Remainder Theorem), and what it means practically is that you never have to enumerate the positions at all. You can just multiply probabilities together, the same way you would for independent dice rolls. An impossible search turns into a small dynamic programming problem that runs in under a second.

There's one more trick that makes it exact rather than approximate. Any janitor numbered above half the gap size can only open one locker at most, and the probability doesn't depend on which one. So all of those collapse into a short recursion. Once you do that, every term in the sum is an exact fraction — no floating-point, no simulation, no sampling error. The answer is arithmetic, not statistics.

The lesson I'd take from this if I never touched primes again: the blocker wasn't compute. It was a bad representation. The problem looked exponential because it was being posed as a search over a huge space, when it was actually a product of independent probabilities. Reframing beat optimising, by a factor of about a billion.

Part 3: How I checked it (this is the actual work)

Getting a number out of a computer is easy. Being right is the hard part. So most of the effort went here.

1. A second derivation from scratch. I had the whole formula re-derived independently, in a sealed directory, by an agent that was forbidden from reading the first implementation. It got 2.741611. It also reproduced the small cases in exact fractions that you can check by hand: the probability is exactly 1 for gaps of size 4, exactly 1/3 for size 6, 2/15 for size 8, and 1/10 for size 10.

(Why is it exactly 1 for gaps of size 4? If p and p+4 are both prime, then p+2 sits between them, and one of any three numbers spaced 2 apart has to be divisible by 3. So p+2 is always divisible by 3, and 3 is smaller than 4. Every gap of size 4 is fully explained, always. That's the kind of thing you can verify on paper in ten seconds, and it's a real check on the machinery.)

2. Brute force, completely separately. I sieved every prime below 10 billion and just counted the fully-explained gaps directly. Got 56,913,912 of them, which works out to c = 2.74137 ± 0.00036. That's within one standard error of the formula's answer.

3. Term by term, not just the total. This is the check that actually matters. A wrong formula can match one total by luck. It can't track a raw count gap size by gap size. Every gap size from 4 to 54 agreed separately.

4. A sensitivity check. If you deliberately break one constraint in the derivation you get 1.616 instead. Break a different one, you get 2.191. So two independent routes agreeing to five significant figures is meaningful, not a coincidence of something loosely fitted.

5. A hostile review. Finally I had the whole thing attacked by an agent whose only instruction was to break it, across eight specific angles. Seven found nothing. The eighth found a real error.

The checks in one table

That last row is the one I'd frame and hang on the wall.

Part 4: The error, which matters more than the result

My original headline was c = 2.7416106755. Eleven digits. Stated confidently.

It was the partial sum up to gap size 78. The rest of the series had been measured and then never added on. Adding the exact terms out to gap size 94 changes it by another 0.000000067.

And it's worse than a simple slip, because the terms don't shrink neatly as you go. The term at gap size 84 is bigger than the one at 80. So you can't just bound the leftover bit and be done. Past that point the value rests on an extrapolation, and calling it anything else would be dishonest.

So the corrected result is two statements, not one:

• c ≥ 2.741610742192 — this is proved. It's the exact sum of every term from gap size 4 through gap size 94, computed as fractions. Every term in the series is positive, so a partial sum is a genuine floor.
• c ≈ 2.74161075 — this is the best estimate, with the leftover extrapolated rather than bounded. The underlying point estimate is 2.7416107451; I quote eight digits because that's what the method honestly supports.

There's a ceiling too, but a much softer one. If you assume a decay property that I could measure but could not prove, you get c ≤ 2.741610763. That's a conjecture resting on a conjecture, so I don't quote it as a result. What it's good for is saying where the remaining doubt lives: in the eighth decimal place, nowhere that changes anything in this article.

Fewer digits than I started with. The difference between "proved" and "estimated" is now written down explicitly instead of being blurred.

There's a specific missing piece: a proof that those terms shrink geometrically. Nobody has one. Until someone does, eight digits is what this method honestly supports.

And you can't buy your way out with compute, which surprised me. I went looking for a rigorous bound on the leftover and found a wall instead. The obvious rigorous method — check a fixed number of positions rather than all of them, which can only overstate the answer — gets worse as the gaps get longer, not better: 0.00077 at gap size 78, 0.0012 at 92, 0.012 at 400, heading towards 1. The reason is almost funny. As the gap gets longer, more primes come into range, so covering any fixed set of positions gets easier, so the bound you're computing gets weaker. It doesn't just fail to be tight — it never even shows the leftover converges.

That has a structural consequence I had wrong for a while. Computing more exact terms and proving a decay theorem are not two routes to the same destination. They are complements, not alternatives. Every extra term raises the floor and leaves the ceiling exactly as missing as it was before. I could grind out gap size 96, 98, 100 forever and never once move the thing that's actually absent. Buying more of the cheap resource does not substitute for the expensive one, and it took a hostile review to make me stop pretending otherwise.

And the two obvious candidate proofs of that decay aren't merely unproven — they're false. The straightforward one, that each term is smaller than the last, fails: the term-to-term ratio exceeds 1 at 11 of the 43 steps I can check, reaching 2.185 at its worst. The multiplicative version, where you bound a long gap by combining two shorter ones, needs a constant out front, and that constant itself grows with the gap size — so there's no single value that works for all gaps, which is exactly what the argument needs. These aren't "someone should do the work" gaps. They're closed doors.

One more thing, which I think is the most useful part of the whole episode. The reviewer that caught my error then proposed a corrected uncertainty range — and that was wrong too. The range it suggested excluded both its own proved lower bound and its own best estimate. I only caught it by doing the arithmetic myself.

Checking the checker was necessary. That's the bit I'd want any engineer to take away.

Part 5: Where "less than 2.6" came from

The commenter who reported a much lower number wasn't being careless. They got bitten by something that will be immediately familiar to anyone who's ever computed a rate from a window of data: the wrong denominator.

The density of these gaps at height t is c ÷ ln(t)². To count how many there are between X and 2X, you should integrate that density across the window.

The natural shortcut is to treat the density as flat across the window and just use its value at the left-hand edge. That gives you a count of roughly c × X ÷ ln(X)², so you'd estimate c by rearranging: c ≈ count × ln(X)² ÷ X.

But ln(t) increases across the window. So 1 ÷ ln(t)² is always a bit smaller than its left-edge value. The shortcut overstates the density, so it understates c. Working through it, the bias is about 0.77 ÷ ln(X) — roughly 4.6% too low at 10 million.

Here's the nasty part. Over the entire range anyone can actually compute, that estimator returns between 2.57 and 2.65. It looks like it's settling down near 2.6. It isn't. It's crawling up towards 2.7416 from below, absurdly slowly, because the error only shrinks like one over a logarithm.

Divide by the honest integral instead, and the estimate sits flat at 2.7414 from 100,000 all the way to 10 billion. Same data. Different denominator.

If you take one thing from this article, take this: an estimator with a 1/log(n) bias will look convergent over any range you can afford to compute, and it will be wrong. That's not a prime numbers problem. That's an everything problem.

Part 6: Does it help predict primes?

That's what I originally wanted it for. The honest answer is no — but the reason turned out to be more interesting than the answer.

First, a negative result that saved me time. The constant can't possibly help with the version of the problem I'd been working on. When you estimate the n-th prime, your error is dominated by a wobble of size roughly √p, which comes from the Riemann zeros and is classical mathematics going back to 1859. The constant describes something about what's inside gaps, which is a much smaller effect — around ln(p) in size. At the scales I was working at, the wobble is roughly 400 times the size of the layer the constant lives in — and even after subtracting 500 zeta zeros, what's left is still about 15 times bigger. Applying it there would be exactly the same category of mistake as the wrong-denominator problem above: right quantity, wrong layer.

What it does connect to is a different question. Not "how big is my error" but "when is arithmetic enough?"

A gap is fully explained by small primes exactly when a sieve-based predictor that already knows the gap size lands on the next prime precisely. I checked that equivalence on 59,900 cases and found no exceptions. So:

probability that arithmetic alone pins down the next prime exactly ≈ c ÷ ln(x)

That's 11.9% at 10¹⁰. It's 1.19% at 10¹⁰⁰. It's heading to zero. The reach of pure arithmetic shrinks like one over a logarithm, forever — it never quite hits zero and it never stops falling.

And there's a hard ceiling hiding in there. Suppose you predict the next prime by sieving out everything divisible by a prime below some cutoff, then guessing the first survivor. Your accuracy works out to about 1.781 × ln(cutoff) ÷ ln(p). (That 1.781 is a specific constant that shows up all over this area.) To be certain, you'd need a cutoff of around p^0.56.

Trial division only needs to go up to √p, which is p^0.5. So the sieve approach needs more work than just testing the candidate directly. It can never win. That's structural — not a limitation of my code, or of anyone's code.

Part 7: What I'd tell someone trying this

Check whether it's already been done, before you invest, not after. Two full days of my earlier work turned out to be a careful re-derivation of results from 1970. The work was fine. The territory was occupied. An hour of searching up front would have redirected all of it. That's now a standing rule here: a prior-art pass runs before the money gets spent, not after.

The genuinely open problems are much narrower than you'd think, and that's good news. "Predict prime numbers" isn't a research question. "Compute the constant these two authors said they could only bracket between 2.7 and 2.8" is one — and it's exactly the sort of thing someone from outside the field with decent computational hygiene can actually do. The authors are theorists. They had no particular interest in spending a week on numerics.

Read the comment threads. The opening here was in a blog comment section: an author saying his method was brute force, and two commenters disagreeing about the answer. An unresolved question sitting in plain sight.

Verification is the work. Independent re-derivation, brute-force cross-check, term-by-term comparison, sensitivity analysis, hostile review. What made the number trustworthy wasn't the computation. It was everything that happened afterwards.

Caveats, stated plainly

This is a computation, not a proof, and it hasn't been peer reviewed.

It's conditional on something called the Hardy–Littlewood prime-tuples conjecture. "Conditional" means: if that conjecture is true, this follows; if it's false, this doesn't. It's widely believed and it's been unproven for about a century.

I want to be careful about what is and isn't conditional here, because it's easy to blur and I did blur it in my first draft. Gafni and Tao's headline theorem — that almost every prime gap contains a rough number — is proved outright. No conjecture needed. It's the density formula, the one with c in it, that assumes Hardy–Littlewood. So the constant I computed is a conjectured constant in a conditional formula, sitting underneath an unconditional theorem. If Hardy–Littlewood turned out false, their main result would survive and my number would not mean what I've said it means.

There's one soft step in the derivation, where a limit gets swapped with an infinite sum. That's standard practice in this area but it isn't rigorous.

And the last couple of digits rest on an extrapolation rather than a bound.

The value is c = 2.74161075, and c ≥ 2.741610742192 is proved.

References

A note on these: the two sources this article actually depends on — the Gafni–Tao paper and the Erdős problem number — I have open in front of me. The historical citation years below are from memory and have not been checked against the papers themselves. They should each be verified before this goes anywhere public.

The paper and the question:

• A. Gafni and T. Tao, Rough numbers between consecutive primes, arXiv:2508.06463 (August 2025). The paper this is all about.
• T. Tao, Rough numbers between consecutive primes, blog post, 10 August 2025. Where the "2.7 to 2.8" range, the "brute force" remark, and the disagreeing comments live.
• Erdős Problem #682, erdosproblems.com/682. The original question.

The mathematics the result leans on:

• G. H. Hardy and J. E. Littlewood, Partitio Numerorum III (1923). The prime-tuples conjecture that everything here is conditional on.
• F. Mertens (1874). The theorem about products over primes that sets the overall scale.
• A. A. Buchstab (1937). The function that counts "rough" numbers, which turned up again later in the prediction work.
• B. Riemann (1859), and H. von Mangoldt (1895). The explicit formula — the classical description of where primes are, and the thing that dominates the error I was originally trying to reduce.

Context for the prediction side:

• H. Cramér (1936) and A. Granville (1995). The two competing conjectures about how big prime gaps get. Nothing here settles that argument — the scales I can compute at are nowhere near where it becomes meaningful.
• H. Riesel and G. Göhl (1970). The work my earlier two days accidentally re-derived.
• D. Goldston and H. Montgomery (1987); H. Montgomery and K. Soundararajan (2004). On how prime counts vary in short intervals — used to show there was no local-density signal worth chasing.

The code and the record

Everything is in a repository with:

• 771 automated tests across 30 test files, including exact closed-form values pinned for every gap size where one is known by hand. 770 of them run in the default suite; the last one recomputes the exact terms from scratch and is opt-in, because it takes about a quarter of an hour.
• 25 written findings documents, each with the question, protocol, key numbers, what it rules out, and its caveats.
• A pre-registration written before each experiment ran, recording what I expected. Eleven experiments, eleven pre-registrations, and five predictions that turned out wrong — recorded as wrong, rather than quietly edited afterwards.
• Sealed holdout data that no model was allowed to touch until it was scored.

That last set of practices is borrowed wholesale from empirical science, and it's the main reason I believe my own results. It also caught me out five times.