One runtime contract. Two language surfaces.
Millrace ships first as the Python runtime you install with pip install millrace-ai. A public Rust implementation lives alongside it, and a live Millrace instance updates that Rust line after every version release of the main Python implementation.
pip install millrace-aiThe production millrace-ai runtime publishes the next version.
The documented updater at live.millrace.ai picks up the release.
millrace-rs is refreshed against the Python runtime contract.
The Rust repo and crate expose the tracked implementation state.
Python keeps the product easy to install and inspect.
The Python package is the primary runtime surface because it is the fastest path to a working local operator loop: CLI, managed workspace files, runner adapters, diagnostics, and restart-safe state.
Rust makes the contract harder to hand-wave.
A second implementation forces the runtime ideas to be explicit. Queue state, stage boundaries, and public package identity have to survive translation into another language.
The sync itself is part of the proof.
The Rust implementation is automatically updated after Python version releases by a running Millrace instance. That makes the automation visible rather than merely aspirational.
millrace-ai on PyPI, import namespace millrace_ai, installed CLI millrace.millrace-ai, crate namespace millrace_ai, CLI binary millrace.The update loop is public.
Millrace is not just claiming that an agent can keep a second implementation current. The Rust implementation is updated by a live Millrace instance after every version release of the main Python implementation, and the automation is documented at live.millrace.ai.