July 2026. Where the number stands: c ≥ 2.741610742192 is proved, by exact summation through gap size 94; the best estimate is c = 2.74161075; and a conjectural ceiling of c ≤ 2.741610763332 rests on a decay property I could measure but not prove.
In August 2025 Ayla Gafni and Terence Tao published a paper resolving a question of Erdős about the gaps between prime numbers. Their result depends on a constant. The paper states only that they believe it lies between 2.7 and 2.8, and notes that the series defining it converges very slowly. Tao's blog post about the paper adds that he ran a simple brute-force search, and that he expects exact evaluation to be exponentially hard in the gap length. Two commenters on that post then reported different values.
Working from the paper's own framework, I get c = 2.74161075.
That sits inside the bracket the paper gives, but below the value the blog post leans towards, so the main reason for writing this up is to have it checked. What follows is what the constant counts, how it was computed, what was done to try to break the answer, and — since it is the obvious next question — why it turns out not to help with predicting primes.
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 surprise. The verification account below also reads differently once you know how it was produced.
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 described below 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 further down 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.
What the number counts
Two worked examples below, and by the end of them you'll know what a rough number is, why most
prime gaps contain one, and why the gaps that don't are the ones c 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. 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.
That is exactly what happens between 89 and 97, and it is not what happens between 139 and 149.
In the top row, every smallest prime factor — 2, 7, 2, 3, 2, 5, 2 — is below 8, the gap's own length. Small-prime arithmetic accounts for the entire gap.
The bottom row is one number different, and that one number changes everything. 143 is composite, but it is 11 × 13, and both 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.
Why brute force stalls, and what gets past it
Two things in this section: why the direct approach does not reach c, and the reframing that
replaces it with a computation finishing in under a second.
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. The search is replaced by 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 blocker here was not compute. It was the representation. The problem looks exponential when it is posed as a search over a huge space, and it is not a search at all — it is a product of independent probabilities. Choosing the second description is what makes it tractable.
How the answer was checked
Producing a number is straightforward; establishing that it is right is not. 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
| What was checked | How | Outcome |
|---|---|---|
| The whole derivation | Re-derived from scratch by an agent sealed off from the original code | Got 2.741611 independently |
| The total | Brute-force sieve of every prime below 10¹⁰, counting directly | 56,913,912 gaps, c = 2.74137 ± 0.00036 — within one standard error |
| The shape, not just the total | Formula against raw counts, separately for every gap size 4 to 54 | Agreement at every size individually |
| The small cases | Exact closed forms worked out by hand for sizes 4, 6, 8, 10 | 1, 1/3, 2/15, 1/10 — exact as fractions, not decimals |
| Whether the agreement means anything | Sensitivity check: break one constraint, then break a different one | 1.616 and 2.191 — the agreement is not a loose fit |
| The result, under attack | Hostile review across eight angles, instructed only to break it | Seven angles found nothing; the eighth found the partial-sum error |
| The checker | Re-did the reviewer's own proposed uncertainty interval by hand | Wrong too — its interval excluded its own proved lower bound |
The last row is the check I would weight most heavily.
An error in my first answer
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.741610763332. 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.
Additional computation does not resolve this, which I had not expected. Looking for a rigorous bound on the leftover turned up an obstruction 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 straightforward once seen. 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.
Where the "less than 2.6" report 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.
The general point, which is not really about primes: 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.
Does it help with predicting 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.
What I would tell someone attempting 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.
What I would like checked
Nothing here departs from the paper's framework. The definition of an exceptional gap, the singular series, the conditional asymptotic and the Hardy–Littlewood model underneath it are all Gafni and Tao's; what is added is a way of evaluating the resulting series exactly, and a lot of checking. So the honest description is not a new result but a different number for an existing one, and the value of writing it up depends on whether the number survives review.
The discrepancy is small but real. The paper brackets the constant between 2.7 and 2.8, and the blog post leans towards 2.8. I get 2.74161075. That is inside the bracket and about 2% below the blog's estimate — close enough that a count comparison at ten million, which is what the commenters were doing, has no power to separate the two. So I do not think anyone was wrong; I think the estimator most people reach for is biased in a way that hides the difference.
If anyone wants to check this, these are the places it would break:
- The convention. I take a gap to be exceptional when no interior integer has least prime factor at least the gap length. The two neighbouring conventions are not nearby — over the gaps starting below ten million they give 0.1831, 0.2718 and 0.0154 as the exceptional fraction. If my convention does not match the paper's intent, everything downstream is measuring a different object.
- The independence step. I take the per-prime residues to be independent by the Chinese Remainder Theorem, which turns the count into a product-space probability rather than a search over residues modulo the primorial. This is the step that makes the computation possible, and if it is wrong the whole thing is wrong.
- The exchangeability collapse. Every odd prime above half the gap length covers at most one even position, each with probability exactly 1/(q−2), independent of which position. I use that to collapse those primes into a forward recursion.
- The soft step. Each term is a fixed-length asymptotic with a fixed modulus, so there is no "modulus exceeds x" problem in any individual term. What is not rigorous is the interchange of the limit with the sum over gap lengths — a uniformity question. The terms with modulus above 10^10 start at gap size 32 and total 0.028% of the constant.
- Table 1. My partial sum through gap size 18 comes out at 2.715392, which I believe matches the paper's own table. That is worth confirming directly rather than taking from me.
And one genuinely open mathematical question, which is the thing standing between eight digits and more: does P_bad(h) decay geometrically? I could not prove it, and two natural routes turn out to be false rather than merely unproven. I would be glad to be told this is easier than it looks.
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.