Seven at one blow
In one week (June 11–17) our Lichess bot @clrsrc_lc0 climbed from 2498 to 2602 blitz – +104 points. No single silver bullet, but the sum of seven improvements, each individually verified by SPRT or a bench gate before going live. The technical run-through:
1. A new NNUE generation
A freshly trained evaluation network on a reworked data pipeline, with finer king buckets (16 buckets – one pair per rank instead of a coarse lump), a wider first layer (1024) and a feature factoriser in training. Finer buckets = more position-dependent king safety, more layer width = more capacity. The single biggest jump.
2. IIR re-placement
Internal Iterative Reductions now fire after the pruning gates instead of before – a one-line reorder that measurably improves move ordering (more nodes on the best move).
3. Book curation
Re-evaluated existing book lines against a strong reference engine at high depth and removed clearly inferior moves – cutting self-inflicted disadvantages straight out of the opening book.
4. A mop-up term
A gated king-driving gradient that kicks in only in pawnless, clearly won bare-king endgames: it drives the lone king to the edge and brings our own closer → wins in fewer moves, lower 50-move / time-draw risk. Outside the gate, exactly zero influence.
5. rule50 eval scaling
The NNUE doesn't see the halfmove clock and therefore overrates positions that are really heading for a 50-move draw. We scale the net's output down linearly as the clock rises (NNUE standard) – so the engine no longer plays for a win the 50-move rule will cancel.
6. Criticality-aware time management
The per-move time ceiling was at once the budget and the hard limit – which flattened the built-in escalation. We decoupled the two: the engine may think longer in unstable/defensive positions (falling eval, changing best move), while a separate, generous hard limit guarantees it never overruns the clock.
7. More reliable opponent search
An infrastructure fix: the opponent pool was queried too shallowly → idle time when suitable opponents sat beyond the first page. A deeper query → less idling, more rated games.
How this comes about – the way we work
clrsrc is developed by several specialised AI instances (Claude) collaborating over a shared message bus – each with its own domain: engine/search, bot operation on Lichess, NNUE training, engine-architecture reference (cross-checking against dozens of open-source engines) and the website. The human sets the direction and signs off every live deploy.
The time-management fix (point 6) is the showcase – three instances, one day:
- The bot instance noticed via live telemetry that the engine spent as little time in defensive positions as in winning ones – flat across the whole evaluation range.
- The engine instance traced it in the source to the cause: the criticality escalation was there, but clamped off by the time ceiling.
- The reference instance supplied the solution pattern from comparing strong open-source engines – decouple soft threshold and hard ceiling instead of clamping the product.
- Built, SPRT-tested, signed off, deployed – the same day.
Seven loops like that in a week: that's what this split makes possible.
No single silver bullet – NNUE, search, book, endgame, time, infrastructure, each one a small, clean, individually verified step. Together: the tailor's seven at one blow. You can watch the bot live on the Live page; the source code is on GitHub.