openmathmodel/open-math-harness

Adopt with caution: the design is inspectable and the slice example runs, but the interactive agent, Ultramath and proof-search paths are documented as dependent on the Open Math OS deployment, not a local install.

The problem

A mathematician who wants an agent to attack a hard statement currently has to assemble the loop by hand: pick a model, give it file and shell access, keep notes across sessions, and separately check any candidate proof in Lean. A chat transcript saying "verified" is not the same as Lean accepting the candidate. Open Math Harness moves that work into one runtime: agents work inside a confined workspace against a fixed Lean statement, and the verifier, not the model, decides whether a proof holds. The user gets a search tree of candidate proofs with recorded verifier outcomes, plus a project memory file later sessions can cite.

What's different

Two mechanisms stand out. Ultramath has several agents register distinct proposed directions, with a model-based duplicate check comparing them; members share lemmas, partial results and dead ends on a common board while keeping working files separate. A coordinator can send reports back for revision or accept one, stopping the rest. That makes parallel exploration reviewable rather than a pile of chat logs.

Second, the capability-based microkernel. Every program, agents included, is a confined process holding only the capabilities its composition grants, and child processes inherit no more. Model output, tool results and repository content are untrusted input, so text cannot approve an action or change a verification result. That is a meaningful choice for anyone letting agents run shell commands. The trade-off is coupling: kernel, identity, IPC and service lifetimes are custom, and the build path reaches the full experience only inside the managed Open Math OS VM.

Who should try it

Good fit: a Rust developer or research engineer who wants to study or build on a capability-secured agent runtime and is comfortable running the scripted slice example and reading kernel docs rather than typing at a chat prompt. It also suits anyone designing multi-agent proof search who wants to see direction registration, shared findings and Lean verification wired together.

Poor fit: a working mathematician who wants a usable proof assistant today. Interactive agents need a service configuration, model credentials and a client, and proof search needs a Lean and Mathlib environment; the repo says no standalone local setup exists yet. The deploy/vm files target the managed VM and are not a personal-machine installer.

Requirements and limitations

Linux only; Windows and macOS are not native runtime hosts. You need a C compiler and linker, Rust via rustup (pinned by rust-toolchain.toml), and bubblewrap with bwrap on PATH plus permission to create unprivileged user namespaces. Startup fails if confinement is unavailable, so the sandbox is a hard gate, not optional hardening, and some default host security policies will block it.

The slice example needs no model credentials or deployment, but it does not call a model or start chat, Ultramath, memory or proof search, and re-running it requires deleting the generated report first. Upkeep means tracking a 0.41.0 runtime whose components are still being decoupled from the platform.

HotRepo's take

HotRepo has tracked this project since 2026-10-24, two days after creation. Its only recorded observation is a Rust NEW-REPOSITORY board placement (#13, 169 total stars) on 2026-10-25 — not an overall Trending rank and not a daily growth figure. With no comparable daily-board history, persistence cannot be judged. Before investing time, check the project instructions to see whether any component beyond the slice example can now run outside the Open Math OS VM.