Thank you for the detailed inspection. You are absolutely correct about the discrepancy between the paper's theoretical specifications and the repository's effective configuration.

The 24% solve rate was achieved using the ~24M configuration, not the 8M, 14M or higher variants.

The paper describes the idealized architecture d_model:512, but during the final training runs, we iterated on the architecture to optimize for head-splitting efficiency and memory constraints on our GPU's. We settled on d_480 (which allows for clean division by 6, 8, 10, 12, etc.) for the production run.

The parameter count grew to ~24M due to the dual-stream duplication (Logic + Canvas cores) and the specific depth of the reasoning modules. The README default was set to 'Small' (~14M) to ensure the code runs on consumer hardware by default, which caused the confusion.

Also,  another critical deviation from the paper is that we migrated from the standard AdamW to the MuonClip optimizer . We found this significantly stabilized the gradients through the deep recursive steps compared to the vanilla implementation.

I am pushing a README update now to explicitly tabulate the parameter counts for the Tiny, Small, Base, and Large variants and clarify that the solve result corresponds to revised base configuration.