Retrieved article excerpt
Open article · Retrieved 2026-10-06T03:34:03.917196+00:00
# I Used OpenAI Dots as an Agent Swarm to Break a 47 Year Old Math Record For Free (with Lean Verification of the Proof)
### My apologies for the clickbait title. This article is fully human written.
[unexcitedneurons's avatar](https://substack.com/@unexcitedneurons)
[unexcitedneurons](https://substack.com/@unexcitedneurons)
Oct 05, 2026
Share
A few days ago, OpenAI released Dots, their version of a personal assistant, meant to take on Muse/Grok Bot/etc. I wanted to see what Dots was capable of.
The Dots agent runs on a VM (see my previous article on this topic[1](https://unexcitedneurons.substack.com/p/i-used-openai-dots-as-an-agent-swarm?utm_source=app-post-stats-page&r=f8o93&utm_medium=ios#footnote-1)), with 9 cores of an AMD Epyc CPU, 10GB of RAM, and 32GB of allocated storage space.
More importantly, it gives you free unlimited access to GPT-6 Astra agents, each with a reasoning effort setting (you can request them to be set to low/med/high/xhigh/max/ultra). You get 7 slots in total, including your primary agent, so that gives you 6 subagents. Note, this **does not use your Codex usage** at all. It was free… so I just played with Dots, while I twiddled my thumbs waiting for another Codex usage reset from Tibo.
So I decided to try out Dots and use it to solve a math problem. That seems to be all the rage at the big AI labs these days, right?
## The (Less Technical) Background Story.
I started off with a bigger problem, which was probably a bit more than the agents can chew; along the way, it proved this as a lemma. Specifically, Dots improved on the old lower bound of the covering problem **C(24,14,4) ≥ 19 (Schönheim 1964, Mills 1979)**. The agents proved **C(24,14,4) ≥ 20**.
Claude described the problem as: *Here’s the problem described as a lottery: Suppose the lottery draws 4 numbers out of 24, and each ticket lets you pick 14 numbers. How many tickets do you need so that, whatever is drawn, one of your tickets has all four? Nobody knows, and mathematicians call this the covering number C(24,14,4).* Thanks, Claude.
The agents answered the question of whether 19 blocks of size 14 could cover every four-element subset of 24 points. They found a contradiction, which establishes that 19 tickets can never be enough, so C(24,14,4) ≥ 20. The same argument also raises the bound for the next case up, C(25,15,5), from 32 to 34.
This took roughly 3 days of compute from my agent swarm of 7 agents (Oct 1 to Oct 3). This is a far cry from OpenAI’s 10,000 agent swarm that solved Navier-Stokes, but hey, did I mention that this cost me $0 and I was out of Codex usage already? And the agent swarm is still chugging along.
## Trust the Process?
I took inspiration from other people who have ~~vibe coded~~ used AI to assist with mathematics, and organized the agent swarm with various roles (more on that later), including an adversarial reviewer of the proof, and an agent which formalized the proof into Lean (and more fresh agents with a new kv cache to review the formalization). I cannot claim to fully understand the proof, as it started off something I could digest, but then went past the limits of my mathematical knowledge. I can understand parts of it with handholding, but I am definitely out of my element.
I recommend people check out the companion website for the proof, which helpfully breaks the proof down into more approachable terms. Here’s the links:
- The companion website breaks the proof into eight steps, with interactive figures you can play with: <https://jamesyc.com/covering/>. There’s also a grid where you can try to cover all 10,626 four-number sets with 19 tickets yourself. (You can’t)
- The Lean proof passed the mechanical checks of the Palomar registry, an independent registry of Lean-verified results: <https://palomar-registry.org/entry.html?id=PALOMAR-2026-10-04-000003&version=1>
- The code is on GitHub (this is the repo Palomar checked): <https://github.com/jamesyc/covering>
I don’t claim that this stuff is peer reviewed. Right now, this is just a website; I haven’t thrown a paper up on arXiv or gotten fully peer reviewed yet. That being said, I am in touch with the mathematicians at Covering Repository, who are helping me get this proof reviewed. The Lean proof has also passed the mechanical checks at the Palomar registry. I currently don’t want to put it on arXiv yet until I get actual confirmation from mathematicians.
## The Slightly More Technical Stuff.
Note that this section is not “the more mathematical stuff”, but rather about how the agent orchestration worked.
I originally divided the work into roles for each agent of mathematical research, Lean formalization, construction and computational search, adversarial review, and coordination. Each agent pursued a different approach while still exchanging messages, and they checked one another’s arguments. A promising argument could be sent to another agent to look for missing assumptions or counterexamples, while a formalizer worked on translating it into Lean.
I made sure that agents would have their work checked multiple times; a single agent’s proof was just considered “plausible argument”, and it needed to be verified by other agents and a Lean formalization created before it could be trusted. The Lean build would also need to be separated from a completely independent rebuild, with no sorrys in the proof. The review agent also had to check that the formal statement described an actual covering design, and that intermediate lemmas applied to the same blocks and points used by the final theorem.
Later on, I got tired of pure mathematics approaches, when I realized they were attacking subsets that you can exhaustively manually check on a modern computer in less than 1 second. That was a waste of time trying to find a more elegant mathematical proof, when you can just brute force ~100k combinations. So I added a brute forcing role. You can roughly estimate the runtime brute forcing would take, as counting bounds restricted the search area of point degrees and pair incidences.[2](https://unexcitedneurons.substack.com/p/i-used-openai-dots-as-an-agent-swarm?utm_source=app-post-stats-page&r=f8o93&utm_medium=ios#footnote-2) I defined searches under 5 minutes as something the agents can run without asking for permission; larger searches need stronger reductions or a better plan. The brute force run, if successful, would then be reproduced with direct Lean kernel checking.
After a while, I realized most agents were sitting idle while waiting on another step of the process. My restrictions were a bit different from most people- I wasn’t compute limited, I was limited by the number of agents! Thus, I decided to design a slightly different swarm architecture. I then migrated the swarm from largely fixed assignments to a shared task pool. Agents can propose follow-up tasks as they discover new questions or finish existing work. The main Dots agent (that I talk to) acts as the coordinator which checks their scope, dependencies and priority, then makes them available for other agents to claim.
The task pool isn't a strict queue, because each agent has a warm KV cache of what it worked on before. Tasks were ordered by priority, but an agent could pick a work item not at the top of the queue if it was related to the previous work they had been doing. This kept similar tasks within the same agent’s context. On the other hand, proof development, independent review, formalization and computational checks are separate tasks, that **required** another agent (that is not the original agent) to pick up the task.
## What Did I Learn
*Agents are good at grinding and bad at knowing when to stop.* Left alone, they would happily spend hours hunting for an elegant argument about a case a laptop can check in under a second. The biggest improvements came from changing the strategy.
*Verification is the whole game.* Every agent was confident, and some were confidently wrong. There were plenty of times (looking at the raw logs) where agents went down a dead end. I didn’t bother to trust any agent result, but only the stack of checks. Especially at the end, with Lean refusing to accept any bad arguments.
*The proof is short; the code isn’t.* The human-readable argument fits in a few pages: counting, a rank argument, a rigid design, and the Petersen graph. The Lean version is 80 files and about 8,800 lines. Nope, not reading all that. Sorry[3](https://unexcitedneurons.substack.com/p/i-used-openai-dots-as-an-agent-swarm?utm_source=app-post-stats-page&r=f8o93&utm_medium=ios#footnote-3).
*Things break, and the OpenAI Dots agents mostly cope.* Partway through, the agents’ shared workspace disappeared. Everything was deleted. They rebuilt the missing files from what survived and from their own messages. This is the most generalized knowledge that’d be useful for other people using OpenAI Dots- yes, they will delete the VM out from under you, but the agents actually survive that pretty well.
## What’s Next
The proof is with mathematicians now, and I’m waiting to hear back before anything goes on arXiv. If it holds up, the bound goes into the covering tables, and since bounds feed into each other, a few more entries move with it: C(26,16,6) to 56, C(27,17,7) to 89 and C(28,18,8) to 139.
Meanwhile the swarm is still running. It’s still free, so why not.
If you find a mistake, in the proof, the Lean or the website, please open an issue on GitHub. And if you can cover all 10,626 four-point sets on the website with 20, 21 or 22 blocks, you’ll have found something nobody has[4](https://unexcitedneurons.substack.com/p/i-used-openai-dots-as-an-agent-swarm?utm_source=app-post-stats-page&r=f8o93&utm_medium=ios#footnote-4).
[1](https://unexcitedneurons.substack.com/p/i-used-openai-dots-as-an-agent-swarm?utm_source=app-post-stats-page&r=f8o93&utm_medium=ios#footnote-anchor-1)
That previous article is mostly AI generated. Sorry not sorry. (This one is not)
[2](https://unexcitedneurons.substack.com/p/i-used-openai-dots-as-an-agent-swarm?utm_source=app-post-stats-page&r=f8o93&utm_medium=ios#footnote-anchor-2)
The agents would then proceed to mathematically cut down arguments into bite sized pieces. They estimated it would take ~20 seconds to brute force. Then, when they brute forced it, it took roughly 0.6 seconds.
In retrospect, I could probably tell them that they are automatically approved to run any brute forcing operation that would take less than half an hour; that would probably end up costing only 1 minute or something. I was just worried that they’d try a problem which would actually take years.
[3](https://unexcitedneurons.substack.com/p/i-used-openai-dots-as-an-agent-swarm?utm_source=app-post-stats-page&r=f8o93&utm_medium=ios#footnote-anchor-3)
Those who get it, get it.
[4](https://unexcitedneurons.substack.com/p/i-used-openai-dots-as-an-agent-swarm?utm_source=app-post-stats-page&r=f8o93&utm_medium=ios#footnote-anchor-4)
And in that case you should definitely open an issue.
Share