A recoverable, audited operating system for mathematical work
Give it a mathematical objective. Get back a result with its evidence, or the exact stage where it stopped.
MathResearchOS is a command-line runtime that turns one objective into a staged run: normalise the problem, search the literature, explore proof ideas, try to refute them, integrate an argument and write it up. Models from the Codex CLI, the Claude Code CLI or an HTTP API do the work; every stage output must pass a verifier verdict before the next stage uses it. Each case keeps the exact objective, its frozen contract, every attempt and an event log, so a run can be paused, resumed or audited later.
Usage guide
Please help me use MathResearchOS, a command-line system for recoverable, audited mathematical work.
Project page: https://qrsntu.org/projects/mathresearchos/
Usage guide: https://qrsntu.org/projects/mathresearchos/details/
Plain-text summary: https://qrsntu.org/projects/mathresearchos/summary.md
What it is
MathResearchOS is a zero-dependency Python runtime that turns one mathematical objective into a recoverable, audited run. Each case keeps the exact objective, a frozen contract, an executable stage graph, every attempt and an append-only event log. Stages are carried out by model backends (the Codex CLI, the Claude Code CLI, OpenAI-compatible HTTP endpoints, or a manual hand-off to a human), and every stage output passes a verifier verdict (accept, repair, replan or escalate) before the next stage uses it. RESULT.md is written only after a verifier accept.
How to use it
- Install: Python 3.11+, `pip install -e .`, and a logged-in `codex` and/or `claude` CLI for live runs. Dry runs need none of these.
- Create a case: `mathos create --mode solve --title "..." --objective-file problem.md`; add `--workflow v2 --explorers N` for the tiered workflow with a seeded explorer swarm.
- Preview, then run: `mathos run CASE --dry-run` makes no model calls and prints the resolved model for every stage; `mathos run CASE` makes real calls.
- Choose models: `--route openai | claude | cross | cross-rev`, `--mix` (for example `claude/openai`, or per role with `role=family:model@effort`), or `--pool pool.json --route NAME`.
- Follow a run: `mathos status CASE`, `mathos events CASE --last 20`, `mathos pause CASE`, `mathos resume CASE`.
- Human gates: `mathos approve-contract CASE --accept`, then `mathos continue CASE --restart-at STAGE --reason "..." --confirm`. Models only reachable in the ChatGPT app go through `mathos handoff`.
- Larger jobs: `mathos campaign SPEC --dry-run`, then `--confirm-live`. Lean audit: `mathos lean-check FILE.lean --target THEOREM`.
Evidence so far
- Pilot MATH-0003 (IMO-ProofBench, problem PB-Basic-008, workflow v2, 8 explorers): 17 calls, about 11 minutes. All 8 explorers delivered distinct ideas; the final proof was correct, checked by hand. One problem, one run, a public benchmark: a plumbing and diversity signal, not an accuracy measurement.
- No comparison of models or roles on held-out problems has been run yet.
Version 0.1.0 · Python 3.11+ · no third-party packages
One run of the v2 workflow: specify, explore in parallel, triage, integrate, refute, then verify. A repair verdict sends the draft back; an accept moves on, and RESULT.md is published only after the final verifier accepts.One run of the v2 workflow, from specify to RESULT.md. A verifier verdict (accept, repair, replan or escalate) gates each audited stage; RESULT.md is published only after the final verifier accepts.Illustrative run; stage names are the workflow’s own, verdicts vary.
MathResearchOS at a glance
Quick start
Install, create a case from a problem file, preview the run for free, then run it. The full guide covers each step.
pip install -e .
mathos create --mode solve --title "First problem" --objective-file problem.md
mathos run MATH-0001 --dry-run
mathos run MATH-0001 --route cross
mathos status MATH-0001
Live runs call real models and can cost money; --dry-run never does. A live run needs a logged-in codex or claude CLI. Install details →
Evidence so far
Pilot run tested
One public-benchmark problem (IMO-ProofBench, problem PB-Basic-008) through the v2 workflow with 8 explorers: 17 calls, about 11 minutes. All explorers delivered distinct ideas and the final proof was correct, checked by hand.
One problem, one run: a check that the pipeline works end to end, not a measure of accuracy.
Held-out comparisons In progress
Model and role comparisons on held-out problems, with every arm and failure reported, are planned but not run yet.
A benchmark harness with contamination-aware held-out problems; effort sweeps, a verifier canary with known-wrong proofs and explorer-yield counts, each planned before the run and reported in full.
Obligation ledger and independent checkers
A proof-obligation ledger the final verifier must cover, plus exact-arithmetic and Lean adapters, so more claims rest on a checkable certificate and less on a model’s audit.
Longer research runs
Retrieval-backed memory with a novelty ledger, so objectives that take many sessions do not repeat approaches already tried.