Why noeira

The problem: a loop made of seams

Getting a learned policy onto a real robot means closing a loop: simulate a world, learn in it, run the result on hardware, record what happens, and learn again. Each stage has a standard tool, and none of them was built with the others in mind:

Stage	Typical tool	Written in
Physics	MuJoCo	C · Python
Tasks and benchmarks	robosuite, LIBERO, DeepMind Control	Python
Networks and training	PyTorch	Python · C++ · CUDA
Datasets and policies	LeRobot	Python
Motors and cameras	vendor SDKs, OpenCV	C · C++ · Python
On-robot runtime	an export format, a second inference engine	varies

Six tools, four languages, and a Python process holding most of them together. That arrangement built the field, and it works. It also has three structural costs.

Performance cliffs. Every boundary adds overhead and data copies. A rollout that crosses NumPy → the simulator → PyTorch pays for each crossing, per step, millions of times; an on-robot control loop that crosses an export boundary pays for it at every query.

Train–deploy drift. The code that trains a policy is not the code that runs it. Normalisation, image resizing, action chunking — each is written twice, once per side, and a mismatch does not crash: it produces a policy that is subtly worse on the robot than it was in training.

A ceiling on acceleration. You cannot fuse physics, network evaluation and environment stepping into one GPU pipeline when no single component owns all three. The best you can do is make each piece fast alone and pay the seams.

The thesis: one language, from the MJCF file to the motors

noeira builds the loop in Mojo, from scratch — not as a wrapper over existing libraries, but as one codebase the compiler sees whole:

• a physics engine in MuJoCo’s generalized coordinates, loading MJCF and checked against live MuJoCo;
• task suites and benchmarks on a declarative task layer that batches many tasks in one scene;
• learning — reinforcement learning, world models, imitation and vision-language-action policies — on a deep-learning framework written in the same language;
• the real-world side — servo buses, cameras, calibration, recording datasets — and the deployment runtime on the robot’s own computer.

In simulation, the whole training loop can live on the GPU — environment step, observation, network forward and backward, replay sample, target update — with no host round-trips. On the robot, the policy that runs is the one that trained: the same modules, the same normalisation file, the same preprocessing.

Python-like syntax

Mojo reads like Python. The algorithms look like the pseudocode in the papers.

Systems-level performance

Compiled, with manual control over memory layout and SIMD — enough to drive a serial bus and a camera thread without a second language.

Native GPU

Custom kernels target CUDA and Metal from the same source, from a workstation GPU to an embedded board on the robot.

Compile-time specialization

Dimensions, network architectures and environments are type parameters, so the compiler specializes the whole pipeline for the target device.

What that buys in practice

• Batched simulation that trains on its own output. Hundreds of environments step in parallel on the device, and the off-policy update reads from a replay buffer that was never copied to the host. On NVIDIA the loop can also be captured as a CUDA graph and replayed — worth roughly 1.4× on SAC.
• One policy, two computers. A policy trains on a GPU box and runs on the robot’s computer through the same modules and the same normalisation file — ACT, for example, closes its loop at 30 Hz on a Jetson Orin NX.
• Datasets without a Python dependency. Teleoperated episodes are written in the LeRobot v3 format (Parquet, H.264 video) — a format, not a dependency: noeira reads, writes and pushes it to the Hugging Face Hub natively, and reads it back into training the same way.

What this is not

This is not a claim that noeira beats MuJoCo at being MuJoCo, PyTorch at being PyTorch, or LeRobot at being LeRobot. Those are mature, heavily used projects, and noeira leans on them as references throughout: the physics tests compare against live MuJoCo, the environments are faithful ports, the LeRobot writer is checked column by column against real LeRobot recordings, and the ACT and SmolVLA ports are gated against the reference implementations.

The claim is narrower: when one language owns the whole loop, optimizations and guarantees become reachable that no amount of tuning inside any single tool can reach.

It is also a young project. Each page carries a maturity marker, results are reported with their caveats, and the roadmap says what is landing next.

Next

• Installation — pixi, the GPU targets and embedded boards
• The stack — how the pieces fit together
• RL in five minutes — if the vocabulary above was new