The kissing number asks how many unit spheres can touch a central one — Newton and Gregory argued about dimension 3 in 1694. In dimension 11 the record stood near 582 for decades, then three AI systems moved it three times in eighteen months, each validated by its producer's own verifier — and two of them, four months apart, announced 604. This page re-decides every public witness in exact arithmetic, shared-nothing with all of them, and finds that the two 604s are the same configuration written in two coordinate frames: decided, with a certificate anyone can check.
| bound | who, when | the bytes | verdict here | exact contacts |
|---|---|---|---|---|
| 582 | classical shell (Best 1977 class); bytes from the Station bundle | integer vectors, norm² 4 | CERTIFIED | 22,560 |
| 592 | Ganzhinov 2022 (arXiv:2207.08266) — the last pre-AI record | not yet pulled | QUEUED | — |
| 593 | AlphaEvolve (DeepMind), May 2025 | integer vectors, entries up to ~8.7·10¹² | CERTIFIED | 0 |
| 594 | EinsteinArena agents — the solved public rung, score-0 winner | decimal literals, read as exact rationals | CERTIFIED | 17,088 |
| 604 ×3 | The Station agents (dualverse-ai), 2026 | (a+b√2)/6 entries, shell norm exactly 4 | CERTIFIED | 19,704 · 22,904 · 22,840 |
| 604 | EinsteinArena (arXiv:2606.10402) — the paper's headline, credited by Cohn's table; coordinates published on request 2026-09-07 | p + q√2 integer pairs, shell norm exactly 36 | CERTIFIED | 19,704 |
| (R¹²) 604 | the Station's D₁₂ lift of configuration 3 — the construction device, integer coordinates | integer vectors in R¹² | CERTIFIED | 22,840 |
Three sentences of history. The norm-4 integer shell tops out at 582 — the Station carries a Lean 4 proof of that maximum, which is why every deeper record needs a richer alphabet: AlphaEvolve went to enormous integers, the 604s live in Q(√2). Ganzhinov's 592 (2022) was the last human record; AlphaEvolve took 593 in May 2025; the two agent platforms then pushed to 604 within a year. The upper bound 868 is semidefinite-programming literature and is not audited by this page.
The distinct contact counts are doing quiet work in that table: congruent configurations have equal contact counts, so 19,704 ≠ 22,904 ≠ 22,840 certifies that the three Station 604s are pairwise non-congruent — three genuinely different ways to reach the record, decided by the same exact arithmetic that certifies them.
The EinsteinArena 604 has 19,704 contacts — configuration 1's count — and the coincidence is total: the two are congruent. Decided, not observed: the configurations are complete graphs whose edges carry the exact normalised inner product (22 distinct values), and individualisation-refinement — colour refinement as the invariant, backtracking over the smallest cell, the procedure inside nauty, written here without it — finds the bijection in 11 search nodes. The certificate is explicit and re-verified at every build without the search: a permutation π of the 604 vectors and an 11 × 11 matrix T over Q(√2) with T · 2aᵢ = b_π(i) for every i and TᵀT = I, all in exact arithmetic. T turns out to be a signed permutation of the coordinates: coordinates 1 … 11 of a Station vector are coordinates 1, 9, 4, 7, 3, 5, 11, 8, 10, 2, 6 of the EinsteinArena vector, doubled, with 10 of the eleven signs flipped — so the two files are one configuration written in two frames. Configurations 2 and 3 are not congruent to it: the same search exhausts at its first node (their contact counts already said so; the search says it independently and would have said it without the counts).
Where the 604 came from is also in the bytes. 496 of its directions are the EinsteinArena 594 rung winner's — exactly its 496 integer vectors — and the 594's 98 decimal-valued vectors were replaced by 108 vectors with a √2 part: the record was reached by keeping the integer skeleton and rebuilding the rest in Z[√2]. 176 of the 604 directions are the classical 582 shell's. Its slack is small: 4,608 pairs sit at 60.94°, under a degree from contact.
As data, for whoever needs it: the EinsteinArena file entered a public repository on 2026-04-12 (its paper, arXiv:2606.10402, was submitted 2026-06-09); the Station's artifacts and paper (arXiv:2608.23691) are dated 2026-08-24 and describe three new exact 604-point configurations. Configuration 1 of the three is the EinsteinArena configuration in another frame; configurations 2 and 3 are not. What the two groups make of that is theirs to say; this page only decides what the bytes decide.
EinsteinArena scores submissions with Python decimal.Decimal at 30–80 significant digits, and switches to exact integer arithmetic only for integer-valued submissions. Fixed-precision decimal is high-precision float, not proof — and the winning 594 bytes are NOT integers (982 of their 6,534 entries are decimals). Read as the exact rationals those literals denote, the winner turns out to be a genuine exact witness: 17,088 pairs sit at exactly 60° and every other pair clears it. To our knowledge this page is the first exact reading of those bytes.
The Station agents did verify their 604s exactly — a sympy notebook pinned to the same npz this page consumes, plus Lean 4 formalizations of spotlight sub-theorems (the 582 shell maximum among them). What this page adds there is independence: different code, different language, different arithmetic (BigInt Z[√2] instead of sympy), sharing not one line with the producer — the difference between an author's checksum and an audit.
And one row measured opacity before it measured geometry. On 2026-09-03 EinsteinArena's paper claimed 604, the field's reference table credited it, the platform's own threads discussed the “frozen 604” — and the public API served only the solved 594 rung and the open 605 rung. The row read NEEDS DATA with one sentence attached: publish the vectors in any exact or decimal form and this row decides in minutes. The ledger asked (vinid/einstein-arena#64); on 2026-09-07 the maintainer answered with the repository holding the file — 604 rows of 22 integers, p + q√2 per coordinate at shell norm 36, the same field as the Station's. It decided in 65 ms. The sentence was the price, exactly.
| rung | best submission at fetch | platform score | violating pairs, exact | worst angle | exact contacts | reading |
|---|---|---|---|---|---|---|
| Dimension 11 (n=605) | #2560 · ExoMind-TTS · 2026-09-05 | 1.71023818 | 9,510 | 40.24° | 0 | 9,510 pairs inside 60°; far from a witness |
| Dimension 12 (n=841) · closed 2026-06-30 | #2081 · CHRONOS · 2026-04-23 | 2 | 1 | 0.00° | 40,992 | 840 distinct directions and 1 repeated — an 840-point configuration, not an 841; the contacts are those of the 840 distinct directions (41,128 with the repeat, whose contacts count twice) |
| Dimension 12 (n=842) | #2561 · ExoMind-TTS · 2026-09-05 | 0.54690624 | 237 | 57.09° | 0 | 237 pairs inside 60°; the closest of the three to a witness |
Two rungs on the platform are open — n = 605 in dimension 11 and n = 842 in dimension 12 — and each has a best submission the platform scores above zero. This instrument reads them too, as a distance and not a verdict: every pair decided exactly, every violation counted, the worst named. Neither is a witness, and none of this refutes anything — an attempt that fails is not a bound that fails.
The third row is a closed rung. On 2026-06-29 CHRONOS submitted a score-0 configuration to the n = 841 rung; on 2026-06-30 EinsteinArena found it identical to the construction of Takhanov et al. (arXiv:2606.18984, whose solution appeared on the authors' GitHub on 2026-06-17), archived the problem and kept submissions disabled. Its page now opens “Status: Solved Outside EinsteinArena” and says “Submissions are closed for this problem” (fetched 2026-10-06; both that text and the platform's changelog are pinned in corpus/sources and re-read at every build). K(12) ≥ 841 is the literature's record, and its bytes are queued here, not yet decided. The score-0 submission is not among the solutions the API serves for the rung: the best it serves, the row above, is #2081 (CHRONOS, 2026-04-23, score 2), which is 840 distinct directions with one vector repeated — an 840-point configuration handed in as 841. The bytes are pinned by the digest of the API response at fetch time (2026-09-08, the same digest at a re-fetch on 2026-10-06); a later submission is a later fetch.
In September 2026 three groups published new kissing lower bounds in dimensions 18, 25–39, 43, 45, 49–55: Alexey Kravatskiy's repository (no arXiv paper; its write-up, paper/kissing46.pdf, 47 pages, is in the repository and calls dimensions 25–31 “joint work in progress with H. Cohn and B. Lindow”), R. Takhanov and S. Yun (arXiv:2609.21591), and the Qiushi Engine (arXiv:2609.35051), whose dimension-25 and -27 records are one point more than Kravatskiy's, built on his configurations. Each configuration below was rebuilt from bytes pinned by commit and sha256 and the claimant's own construction table, and every pair was decided exactly: 9,752,457,821,554,402 pairs over 28 configurations, 6,720,098,543,228 of them touching at exactly 60°, none closer. The arithmetic is integer: coordinates are integer combinations of 1, √2, √3, √6 (dimension 18 needs only 1, √2, √6, so its inner products lie in Z[√3]; the coordinates do not); inner products come from float BLAS only under a checked bound that makes every partial sum an exact integer (224 or 253), and every sign is decided in the tower Q(√2)(√3). Dimension 18 was decided twice, in Python and again live in JavaScript by a separate implementation, 34,923,903 pairs each, the same 1,621,638 contacts; and every other row had a seeded sample of 442 to 778 of its vectors decided whole by both implementations, agreeing on every contact count (the 1019-denominator rational heads and the two irrationally normalised Qiushi points sit outside the JavaScript guard and are decided by the Python digit and integer paths only).
After this wave the best bound decided here in each dimension is K(18) ≥ 8,358 (Kravatskiy), K(25) ≥ 197,580 (Qiushi Engine), K(26) ≥ 199,806 (Kravatskiy), K(27) ≥ 201,567 (Qiushi Engine), K(28) ≥ 204,896 (Kravatskiy), K(29) ≥ 209,968 (Kravatskiy), K(30) ≥ 221,012 (Kravatskiy), K(31) ≥ 238,662 (Kravatskiy), K(32) ≥ 347,584 (Qiushi Engine), K(33) ≥ 363,968 (Qiushi Engine), K(34) ≥ 384,196 (Qiushi Engine), K(35) ≥ 409,676 (Qiushi Engine), K(36) ≥ 484,760 (Qiushi Engine), K(37) ≥ 498,024 (Qiushi Engine), K(38) ≥ 591,900 (Qiushi Engine), K(39) ≥ 763,668 (Qiushi Engine), K(43) ≥ 2,553,792 (Qiushi Engine), K(45) ≥ 7,380,090 (Qiushi Engine), K(49) ≥ 52,430,156 (Qiushi Engine), K(50) ≥ 52,458,468 (Qiushi Engine), K(51) ≥ 52,500,930 (Qiushi Engine), K(52) ≥ 52,585,772 (Qiushi Engine), K(53) ≥ 52,698,696 (Qiushi Engine), K(54) ≥ 52,923,774 (Qiushi Engine), K(55) ≥ 53,301,140 (Qiushi Engine). WITNESSED means the published integers, rationals and printed closed forms are already the exact configuration. REPAIRED means some coordinates were published only as binary64 floats of irrational numbers and the exact point had to be decoded from them by the claimant's own formula. Each decoded point, rounded back to binary64, is the published float again — Kravatskiy's K(25) bit for bit, Takhanov–Yun's K(25) to within 1.1e-16: a decode, not a correction. A slip in a witness would not have refuted any bound, and none occurred.
The Qiushi Engine's dimensions 43 and 45. Their counts came from spherical-design moment identities over lattice sections, with no point list, so the rows read NEEDS DATA. At our request (their issue #1) the claimant published every point on 2026-10-11 as integer coordinates in R48; the files are pinned by sha256 and equal the digests GitHub reports. The claimant's own verification checks norms, the subspace, lattice membership and distinctness, and records "pairwise_inner_products_checked": false. K(43) ≥ 2,553,792 is WITNESSED here: the rows span exactly 43 dimensions and all 3,260,925,512,736 pairs were decided, 4,467,331,098 touching, none closer; K(45) ≥ 7,380,090 is WITNESSED here: the rows span exactly 45 dimensions and all 27,232,860,514,005 pairs were decided, 19,832,543,736 touching, none closer — to our knowledge the first pairwise check of these configurations. Both were then decided a second time in the form the construction states: integer coefficient rows over the claimant's published lattice basis and its exact Gram matrix (dimension 43: B B^T = 96 G; dimension 45: B B^T = 12 G, rows over the common denominator 8), every row checked to be a point of the section or projected fibre the construction defines, the Gram matrix proved positive definite, and every pair decided again from the coefficients — the same pairs and the same contacts. That form, coefficient rows and a Gram matrix, is the one this page now accepts from any lattice construction (instruments/kissing/wave/gram.py).
The rest of the Qiushi Engine's table. On 2026-10-12, after the checks above, the claimant published every remaining configuration of its paper (dimensions 32–39 and 49–55, releases configuration-vectors-2026-10-12 and lifting-vectors-2026-10-12, pinned by sha256) and linked these checks from its README. In several of them the rows have different lengths (squared norms 32 and 39 in dimension 39; 48 and a 36-digit norm in dimension 38; 144, 192 and 48 in 49–55), so every row is normalised by its own length and each pair is decided by the exact test p ≤ 0 or 4p² ≤ AB, which also catches a repeated or parallel row. K(32) ≥ 347,584 is WITNESSED (60,407,144,736 pairs, 358,430,976 touching); K(33) ≥ 363,968 is WITNESSED (66,236,170,528 pairs, 368,310,912 touching); K(34) ≥ 384,196 is WITNESSED (73,803,091,110 pairs, 380,481,792 touching); K(35) ≥ 409,676 is WITNESSED (83,917,007,650 pairs, 315,579,800 touching); K(36) ≥ 484,760 is WITNESSED (117,495,886,420 pairs, 404,388,832 touching); K(37) ≥ 498,024 is WITNESSED (124,013,703,276 pairs, 392,397,168 touching); K(38) ≥ 591,900 is WITNESSED (175,172,509,050 pairs, 379,853,270 touching); K(39) ≥ 763,668 is WITNESSED (291,594,025,278 pairs, 325,490,632 touching); K(49) ≥ 52,430,156 is WITNESSED (1,374,460,602,877,090 pairs, 965,197,554,294 touching); K(50) ≥ 52,458,468 is WITNESSED (1,375,945,406,224,278 pairs, 964,169,164,800 touching); K(51) ≥ 52,500,930 is WITNESSED (1,378,173,799,181,985 pairs, 962,629,120,340 touching); K(52) ≥ 52,585,772 is WITNESSED (1,382,631,682,125,106 pairs, 959,560,825,568 touching); K(53) ≥ 52,698,696 is WITNESSED (1,388,576,253,700,860 pairs, 955,491,412,444 touching); K(54) ≥ 52,923,774 is WITNESSED (1,400,462,900,739,651 pairs, 947,433,469,328 touching); K(55) ≥ 53,301,140 is WITNESSED (1,420,505,735,999,230 pairs, 934,069,080,624 touching). Dimensions 49–55, about 1.4 × 10¹⁵ pairs each, were decided on one rented GPU by a kernel that never writes a product to memory, calibrated first against the desk on dimensions 32 and 39 (the same contact counts); exactness there rests on the same bound — every partial sum of products is at most the largest squared norm, 192, far inside what half precision holds exactly. With these, every one of the 19 bounds in the Qiushi Engine's paper is decided here, pair by pair, and every one holds.
The current table. “Decided here” is not “the record”: H. Cohn's table of kissing bounds, read 2026-10-11, lists K(25) ≥ 197,583 (Takhanov & Yun [27]), K(26) ≥ 199,868 (Takhanov & Yun [27]), K(27) ≥ 201,589 (Takhanov & Yun [27]), K(28) ≥ 205,172 (K. Li [17]), K(29) ≥ 210,473 (K. Li [17]), K(30) ≥ 222,072 (K. Li [17]), K(31) ≥ 241,077 (K. Li [17]) — above the bounds decided here in those dimensions, from constructions this page has not decided; in dimensions 43 and 45 the table's bound is the one decided here. The extract is pinned in corpus/sources/kissing/cohn-table-extract_2026-10-11.json.
Who else has checked these. B. Lindow, a collaborator on dimensions 25–31, publishes exact verifiers for them that share no code with Kravatskiy's (btlindow/KissingNumbers, tools/kravatskiy/). Their recorded runs reach dimensions 26, 28–31 at the totals decided here, and K(25) at 197,569 and K(27) at 201,509, below the 197,579 and 201,566 decided here (run against earlier commits of his repository). Those are the collaborators' own checks, not third-party ones; K(18) has, to our knowledge, no outside check but this page's. Both sources are pinned in corpus/sources/kissing.
Calibrations ran in the same engine at the same build: the whole Leech shell, K(24) = 196,560, every one of its 19,317,818,520 pairs, with the textbook 452,088,000 contacts; E8's 240; and the icosahedron's 12 in Z[√5], where no pair touches and the nearest sit at cos² = 1/5 exactly.
4 rebuilds (Kravatskiy K(26), Kravatskiy K(27), Qiushi Engine K(27), Kravatskiy K(28)) had to fix something the claimant's text leaves free, and the ledger row says what: which hexagon triangle or which zero-sum triangle of the cuboctahedron or of the D₄ roots carries which side or class, and about which coordinate axis the dimension-27 axis is turned. Each choice is a symmetry or gives the same thresholds, and the exact decision is made on the one chosen. The Leech shell itself is built here, from the Golay code spanned by the claimants' own published owner vectors.
NEEDS DATA, 43 rows: Kravatskiy's dimensions 49–63, 68–71, 73–96 publish counts — from lattices, class-size tables, moment identities — and no vector list. Each row names what would decide it.
QUEUED, 8 rows: Takhanov–Yun K(26), Takhanov–Yun K(27), Takhanov–Yun K(28), Takhanov–Yun K(29), Takhanov–Yun K(30), Takhanov–Yun K(31), Kravatskiy K(38), Kravatskiy K(39). Takhanov and Yun publish dimensions 26–31 as float64 arrays whose lifted block is turned by a generic rotation; an exact witness needs that rotation as an exactly orthogonal matrix (their paper bounds the polar factor instead). Their dimension 25 needs no rotation and is decided above. Kravatskiy's 38 and 39 ship rebuildable data and wait their turn. One fact about those bytes is already measured: the four points added in dimension 31 are stored as (±0.501179 uj, 0.865343 vj) (to 2e-14), where the README writes (±uj/2, (√3/2) vj) — another point on the same arc, so the array and the text describe two configurations. Which one the paper certifies is theirs to say; neither is refuted here.
The hunt. On every configuration decided here the deepest empty cap was searched in floating point (random directions, a smoothed-max descent, an LP polish to a facet normal) — floats propose, nothing more. None returned a cap of 60° or more: no insertion is proposed in any of the 11 configurations, the widest cap found being 58.694° (Kravatskiy's K(18)) and the gap to 60° 1.31° to 4.48°, after 1,200,000 random directions or more per configuration. That is a search result, not a proof that no hole exists; the Qiushi Engine's +1 in dimension 25 needed 552 points MOVED first, which an insertion search does not try.
No bound is improved by this lab: the deepest-empty-cap search proposes in floating point and decides nothing, and the upper bound is untouched. The Station's own exact verification of the 604s predates this page — the claim here is independence (shared-nothing re-decision from their sha-pinned bytes), not priority of verification. What is, to our knowledge, first here: a third-party exact certification of the 604 record from both platforms' bytes, the exact reading of the EinsteinArena winner's bytes, the non-congruence of the three Station 604s stated as a certified corollary, and the congruence of the EinsteinArena 604 with the Station's configuration 1 decided with an explicit, re-verified certificate. The rung readings decide nothing about any bound. The September wave rows decide witnesses, not priority: who reached a bound first is the claimants' to say. Sources are published, not peer-reviewed; the Ganzhinov 592 row and the dimension-12 record 841 (arXiv:2606.18984, the construction EinsteinArena's archived n = 841 rung was found to match on 2026-06-30) are queued, not forgotten.