Recursive AI
ResearchCase study

Building OnePhysics: deterministic 2D and 3D physics with agents

This is the short version. Read the full report →

OnePhysics, in brief

AI agents built OnePhysics to 1.0.0, its first stable release. The C# library simulates 2D and 3D physics with deterministic results: the same starting world and inputs are intended to give exactly the same simulation across supported platforms and thread counts. Its scope includes rigid bodies, characters, vehicles, ragdolls, cloth and soft bodies, ropes, destruction, fluids and tools for saving and replaying a world.

The repository begins on October 26, 2026; the stable release is dated November 10. Engineering and coordination agents ran on Claude Opus 5.5, Claude Sonnet 5.5 and GPT-6.1 Sol through Alera, Recursive AI’s system for building software with agents.

FigureWhat it counts, and the source
1.0.0First stable release; tag and changelog
3 packagesRecursiveAI.OnePhysics, RecursiveAI.OnePhysics.Tools and RecursiveAI.OnePhysics.Interchange, all at 1.0.0
2D and 3DBoth supported; direct access to low-level engine storage remains experimental
1.xThe release README’s compatibility promise

Determinism is not the same as compatibility between versions. The README promises that patch releases preserve simulation results. Minor releases may change results, with changes listed in the changelog. Games that keep simulations synchronized or rewind and replay them must use the same minor version. Saved worlds, files containing only changes to a saved world, recorded replays and scene files from any 1.x release load in every later 1.x release. The programming interface follows standard major, minor and patch version rules. The previews did not promise result compatibility with one another or with 1.0.

OnePhysics is written from first principles, not a wrapper around another engine. The simulation code depends on OneMath and .NET’s built-in library. Separate engines share code for organizing calculations and saving worlds. The tools package prepares shapes for simulation; the interchange package imports robots, physics scenes and levels.

The release README compares median simulation-step time on the same scene files, with the compared .NET engines at their default settings and the runtime set to use optimized code from the start. It uses BepuPhysics 2.5.0-beta.33, Jitter2 2.13.0 and Box2D.NET 3.1.654, on an AMD Ryzen 9 7950X3D and Apple M2. Its claims are:

“2D: at or ahead of Box2D.NET on every scene at every thread count (large pile 0.11× its step time at 1 thread on x64, 0.17× on arm64).”

“3D: within 15% of the fastest stable managed engine, or faster, on large piles, mesh and height-field terrain, joint grids and queries at 1 thread; joint chains and tall pyramids, where no managed engine is stable at its defaults, are gated on stability only.”

On x64 at 1 thread, the ragdoll pile takes 2.19× the fastest stable managed engine’s step time, and sleep–wake takes 2.30×. The README lists additional slower measurements at other thread counts and on arm64.

“Soft bodies: ahead of Jitter2 on cloth. Our cloth sleeps once it settles, so the median step is a sleeping one; while awake, an 8-thread step is about 0.46 ms against Jitter2’s 0.13–0.19 ms.”

The awake cloth measurement is slower.

The stable changelog also records a fix for a collision shortcut that could make a restored 2D world continue differently from the original. The release tests compare summaries of the simulated world after each step across different computers and settings. Test your own worlds, including saving and restoration, before relying on the compatibility promise.

What this doesn’t show. The results do not show that OnePhysics is fastest everywhere, beats engines written in other languages or became faster between development runs. This report did not independently rerun the benchmarks or cross-platform tests, measure human effort or establish that the build was unattended. It covers the stable release, not the end of development.

Sources: the stable source, the changelog, the compatibility and speed claims and the benchmark method. The result is a supported physics library with a clear compatibility promise and published performance limits.