Ponder
Ponder is chess with a visible mind. You play an engine that was written from scratch for it, and while it thinks you can watch it work: the line it expects, the moves it’s weighing, and an x-ray of what its search is doing to every position it looks at. Or sit back and let it play itself, with a different amount of thinking time for each side, and see what more time buys.
Like Syzygy, it was built by EILAID from a brief, with me as the engineer in the loop. It took 29 hours, from the first agent run at 15:10 UT on 7 October to the last at 20:16 the next evening. Click the picture and you’re in this exact game, with the engine about to think in front of you.
What I asked for
Three rules shaped the brief:
- Its own engine. No Stockfish inside, no code, tables or opening book from any other engine, and no neural networks. The engine is TypeScript running in a Web Worker, and its evaluation is a set of hand-written terms you could read out loud: material, where each piece stands, mobility, king safety, pawn structure and passed pawns. Other engines are only there as sparring partners and measuring sticks.
- Honest numbers. A level is a number of positions the engine may search, never a time limit, so it plays the same on a phone as on a desktop. Every round of work on the search had to beat the version before in a statistical test (an SPRT) at a fixed number of positions per move, so a busy machine couldn’t skew it. And the app shows no rating it hasn’t measured.
- A mind you can read. The style guide calls it “an engraved chess diagram that thinks out loud”: a board from an old chess book, drawn in fine ink, with the engine’s thoughts sketched over it in amber.
Seven hours in, I played the early build and changed direction. It played well, but the thinking was hard to read, so I asked for the engine itself to be the exhibit: a diagram of how it works, live, and a way to watch it play itself with time per move as the dial. That became most of the rest of the project.
Four ways to look at it
A link to a game opens on the search lens unless it names another. The four below are a key away: x for the x-ray, 2 for watch, m for the time lens and 3 for review.
The x-ray: one search, counted as it runs, from the position to the move it decides on.open this view (x-ray) ↗
Watch: 1.5 k positions a move against 400 k. Both minds side by side, each with what it expects next.open this view (watch) ↗
What more time buys: depth against positions searched, and the measured self-play strength curve.open this view (time) ↗
Review of a Scholar's mate: the inaccuracy, the blunder that allows mate in 1, and the mate itself.open this view (review) ↗
The x-ray is the diagram I asked for. It follows one search from the position through move generation and ordering, then down a ladder of what happens to each position the search reaches: ended early (a draw, a position it remembers, a cut from the static evaluation, a null move), skipped, reduced, searched in full, or cut off. Every rung counts live and explains itself when you hover it.
Watch has Ponder play itself. Each side gets a think-time dial from 1 ms to 10 s, which the app turns into a number of positions on your device, so the game replays the same everywhere. Presets include “the gap”, 0.01 s against 3 s, and both minds sit side by side with the reply each one expects. Any finished game exports as PGN, or opens on Lichess or 365chess, so you can check it against a stronger engine.
The time lens answers my original question, whether 5 s a move really beats 0.05 s, with measured data only (more on that below). And review goes back over a game you played and flags the blunders, mistakes and good moves, with a reason for each and the better line replayed on the board. It only says “mate in N” when a separate solver has proved it.
When you first open it, Ponder is already playing itself with the x-ray running and an intro card offering to let you play instead.
How strong is it?
The official number would come from a long rating run against a ladder of other engines with nothing else on the box, and that run hasn’t happened. What I have is a probe of the finished engine: 450 games at 10 seconds a game plus 0.1 a move against three versions of Stash, an open source engine with published ratings, which puts Ponder at about 2,320 ± 35 on the CCRL Blitz scale. That’s an engine rating, not a human one.
It got there in four steps, each tested against the one before at 8,000 positions a move: three rounds of search work worth about +199, +176 and +176 Elo, then the evaluation terms for another +154. After that I froze the engine, and everything since has been the showcase around it.
The time lens draws a self-play ladder, which I ran outside EILAID: 200 games between each pair of neighbouring budgets, with both sides limited to a fixed number of positions per move.
| Positions per move | Strength against 100,000 |
|---|---|
| 1,000 | −1,229 ± 113 |
| 3,000 | −874 ± 93 |
| 10,000 | −555 ± 71 |
| 30,000 | −244 ± 48 |
| 100,000 | 0 |
Each step up the ladder, about three times the search, is worth roughly 240 to 355 Elo against itself. Self-play exaggerates gaps like these, so the app shows them as a relative curve and never as a rating.
Twenty-nine hours
The engine came first. Through the first evening and night, EILAID’s agents wrote move generation, which had to match the standard perft counts exactly, then the search, the evaluation, the opening book and the first app around them. By the next morning the engine was at its final strength, and the probe above was running.
Then I froze the engine, and the second day was nearly all front end. That’s where the run taught me the most about EILAID, because it kept running into its own limits:
- The tests got in the way. The engine’s tests are heavy on the CPU, and with several verifiers running them at once on a four-core box they started timing out. Once the engine was frozen I told EILAID that front-end work needed no new tests: prove it with the build, the fast tests and screenshots. The reviewers and design reviewers stayed.
- Urgent work starved. A backlog of low-priority planning runs kept refilling every free slot, so the items I’d marked urgent sat waiting. I fixed the scheduler so an item only waits behind work at least as urgent as itself.
- Builders were reading half the spec. For UI work, a designer writes notes, and half of them ran past 14,000 characters, the longest to 34,000. EILAID was cutting them off at 8,000 before they reached the builder, and the reviewers too. That explained a few of the mismatches the reviewers kept finding.
- The coach could undo my edits. EILAID’s coach turns review findings into lessons for each agent. When a run had started on an older version of the agent’s instructions, the proposed new version was built on that old one, so accepting it would have quietly removed my changes. Proposals now build on the current version.
- It hit the spend limit twice. Twice the Claude organisation’s spend limit stopped the run. The agents that were running died mid-step, EILAID kept starting new ones that failed within seconds, and I restarted the work after each reset.
The first four have fixes in EILAID now, on a branch I’ve still to merge. The fifth doesn’t: EILAID still keeps starting runs while the API is refusing them. I also ran my own QA alongside: several agents driving the built app in a browser, each finding checked by a second agent before it became a ticket. They found that pieces didn’t glide on a played move, which no unit test would have caught.
On the second day I cut the scope twice: 67 items when I froze the engine, and 32 more from late morning on, among them human-like levels, two more lenses and commentary. In all, 128 of the 230 items ended cancelled; the other 29 were duplicates, superseded tickets or work done outside EILAID. Three items were merged outside EILAID, the last polish pass among them. These are the numbers for the whole run:
The run numbers come from EILAID’s own database. It queued 1,374 runs and started 1,264 of them, the Oracle’s lookups included, and the agents worked for 67 hours between them, two or three at a time. They went through 1.42 billion tokens, 95% of them context read back from the cache. The $663 is what all of that would cost at Anthropic’s API prices: Claude Code’s own figure for each run, apart from four cut off mid-run that EILAID priced from their token counts. EILAID ran on a Claude plan login rather than an API key, so it’s what the same usage would cost through the API. The builders took 44% of it, the reviewers and the shapers 15% each, and $94 went on items I later cancelled.
Until I froze the engine, nearly every brief and change came to me at the gates: I approved 98 briefs and 40 changes and sent 5 back. After that the Plan Critic and the verification results decided. The Oracle took 149 of the agents’ questions and answered 71 itself; the other 78 came to me.
None of the app’s code is mine. Outside EILAID I set the direction, answered those 78 questions, cut and reshaped tickets, re-recorded or adjusted five tests when the engine’s numbers moved on purpose, ran the rating probe and the ladder, and fixed EILAID when it got in the way. I did that through my own Claude Code session, which isn’t in the numbers above.
It’s done for now. Open a new match, pick “the gap”, and watch a 0.01 s Ponder get taken apart by a 3 s one.
next · part 5Twenty →A Rubik's cube you can play, and a solver that shows you the way out, from a camera or by hand. EILAID built it in a day, with its own solving engine and nothing from me but a brief and the gates.