Erdős Problem a Daythe open tracker
The guide · for anyone with a subscription and an afternoon

How to work on an Erdős problem with your AI subscription

A field guide from two people who have done it 595 times, with the receipts.

Why this page exists

On 6 October 2026 Thomas Bloom, who runs erdosproblems.com, froze problem comments and proof claims on the site, removed every status label and the solved counter, and asked for one thing instead: good write-ups. His reason was a flood of AI-generated "solutions" posted with no explanation, as priority claims, by people who hadn't understood them. He wrote that the site exists to help "the Erdős-community of humans flourish," and his closing advice to anyone using AI was: use it however you like — but write the proof up yourself, pick problems you actually care about, and talk to people. (His post, crossposted on Terence Tao's blog.)

We agree with all of it, and we also think a lot of people with a twenty-dollar subscription and a curious streak could do real, honest work on these problems if someone told them how. Nobody has. This page is that.

It is written from our own record. Since July 2026 we have attempted 595 Erdős problems with frontier models, verified what came back, and published every outcome — including the many walls. A handful of exact values and bounds are new. Most attempts produced a verified partial result or an honest nothing. Every lesson below cost us something, and the problem numbers in it are where.

What you actually need

Step 1 — Pick a problem you'd be glad to understand even if you never solve it

Bloom's advice first: don't pick for glory. Pick something whose answer you want. You'll spend hours inside it, and the hours only pay if the problem is still interesting when the model stalls — which it will.

Then apply a tractability filter, because wanting isn't enough. We reverse-engineered one from the problems that have actually fallen to AI-assisted work; the long version is on How We Pick. The signature is known hammer + nontrivial dictionary + auditable cleanup: a crisp question (an existence, a collision, an asymptotic), a re-encoding (valuations, finite fields, a finite optimisation) under which it resembles an existing theorem or a finite search, and a proof that decomposes into pieces that can each be checked on its own. Bad targets: famous conjectures with no visible reduction; anything whose first step needs new input about the distribution of primes; open-ended classification questions; problems with several competing AI manuscripts already circulating.

The most reliable shape of all is a finite residual: the literature has narrowed something to a bracket, and one construction or one exhaustion would settle it. #813 arrived as "h(18) is 4 or 5". That's a computation, and it got done — the answer is 5, with a certificate. Browse the board by tag, read the Lean statement, and ask: is there a finite question inside this one whose answer nobody has written down?

Step 2 — Find out what's actually known, before the model tells you

Models are confidently out of date, and a tracker's status is a snapshot. Do this yourself, in order:

  1. The community database entry: status, its last-update date, and whether a Lean proof exists. "open (Lean)" means a machine-checked proof exists that no human has digested yet — treat it as solved for your purposes.
  2. The problem page on erdosproblems.com and its comment thread. The thread is frozen now, but the archive is where "oh, this was done in 2019" lives.
  3. arXiv, searched by the problem's key phrase and by "Erdős problem N". Open the current version of any paper you find, not the abstract. In July we found that #1199 had been answered eight days earlier by a preprint the tracker didn't know about; the page still said OPEN.
  4. The Formal Conjectures Lean file, which often lists the known partial results as "variants", each with a citation.

Write half a page on the state of the problem in your own words before you open a model. If you can't, you don't understand it well enough yet to judge what comes back.

Step 3 — Brief the model like a colleague, not an oracle

The quality of what you get is set almost entirely by the brief. Ours look like this, and you are welcome to copy it:

TASK: Erdős problem #N (erdosproblems.com/N).

STATEMENT, verbatim, with every quantifier: ...
KNOWN: [what you found in Step 2, citing only papers you personally opened]
NOT WANTED: a survey of the literature, a plan, or a restatement.

GOAL, in order of value:
 (1) an explicit construction / counterexample / closed form, with a from-scratch checker;
 (2) an exact small-case computation -- a verified table or a sharp bound in a
     concrete regime -- with reproducible code;
 (3) a clean reduction isolating exactly what remains;
 (4) if none of those is reachable, a precise diagnosis of WHY: name the missing
     lemma or the computation that would decide it, and estimate its cost.
A precise negative is a first-class result. A hand-waved "probably open" is not.

RULES: write and run code. Recompute anything you derive, by a different route.
Label every claim (a) elementary-rigorous, (b) rigorous modulo a NAMED theorem,
(c) plausible but unverified, (d) computational only. Never treat a computed list
as a theorem. Never say "closed" without the step that actually closes it.
Verify that every paper you cite exists and says what you claim.
An honest decline is welcome. End with exactly one line beginning
FOUND: / PROVED: / PARTIAL: / WALL:

Three things in there matter more than the rest. Rank the outputs, so the model doesn't default to the easy survey. Demand code. And give it permission to fail — a model that believes it must deliver will invent the delivery.

Step 4 — Make it compute, not narrate

Every one of our real results went through a program. Every one of our embarrassing moments came from prose.

Step 5 — Verify as if the model were a stranger who wants to be published

This is the step that separates a contribution from noise, and it's the one Bloom was actually asking for.

  1. Recompute every load-bearing number by a different route. Not the same script re-run — a different method. If the model used a dynamic program, write the brute force for small n and check they agree.
  2. Get a second opinion from a different model family, cold. Paste the statement and the claim — not the proof — into another provider's model and ask it to refute. Models from one lineage share blind spots; two families disagreeing is where you learn something.
  3. Check novelty against the live world. Search arXiv again, now that you know exactly what was found, and open the latest version. Read the source paper's examples and corollaries, not just its abstract — more than once our "new" result was sitting in somebody's Example 2.1.
  4. Read the proof yourself, out loud if you have to. You are looking for three things: a lemma that quietly assumes something as strong as the problem; a cited paper that doesn't say what the model says it says (open it); and the word "clearly" in front of the only hard step.
  5. Grep the claim against the transcript. When you summarise what the model found, check that the specific numbers and the specific story are actually in its output. We once published a headline about a result whose numbers appeared nowhere in the 20,000-line log it supposedly came from (#1063). The real result in that log was stronger; we had told the wrong story about it.

The ways it goes wrong — our own catalogue

None of these is hypothetical. Each happened to us, on the problem whose number follows it.

Step 6 — Write it up yourself

Bloom's rule, and ours: if you have something, you write it, not the model. Partly because the writing is where you find out whether you understand it. Partly because an unexplained AI proof is precisely the artifact that got the comments closed.

A good write-up — a full proof, a new exact value, or an honest "here is why this is hard" — has:

Step 7 — Where it goes

What to expect

Our hit rate, honestly: of 595 attempts, a few dozen produced new verified exact values or bounds, a few hundred produced a verified partial that mostly confirmed what experts already suspected, and the rest were walls. That is roughly what a serious amateur with good tools should expect too. The win condition isn't a solved problem. It's a problem you now understand better than almost anyone, a verified fact nobody had written down, and the habit of checking.

Bloom signed his post "Be human. Let your brain be open." We can't improve on that.

Found something?
Send it. We'll read it the way we read our own.
Submit an attempt ↗ Pick a problem ↗