NVIDIA Metatron: A Unitree G1 Humanoid Policy That Runs in Your Browser

NVIDIA has quietly put a humanoid control policy you can run in a web page on Hugging Face. The repository nvidia/metatron-browser contains "Metatron v1 G1 Browser Exports": ONNX versions of the Metatron walking and recovery policy for the Unitree G1, used by NVIDIA's browser demo and a six-robot game called G1 Racer.

It is a narrow release, and the model card is unusually frank about what it is not. But for anyone tracking open humanoid control, it is a useful artifact: a learned locomotion policy, with a recovery adapter, small enough to ship as two files and fast enough to be driven in a browser tab.

TL;DR: what NVIDIA released

What exactly is in the repository?

Two files with the same learned weights but different interfaces. The model card stresses they are "not interchangeable."

The demo export is a single-robot pipeline that includes observation processing and action conversion. Its inputs, per the card, are the current G1 state, eight historical state samples, raw-action history, ground height, masked future pose, style and velocity goals, and an explicit recovery_enabled flag. It returns joint PD targets as action, PD gains as stiffness and damping, and raw_action to feed back as history.

The Racer export is a six-robot batched network. It expects observations computed outside the neural graph by G1 Racer's own code, evaluates all six robots in one batch, and exposes action and raw_action. NVIDIA warns not to feed raw demo inputs into it or change its batch size without rebuilding and validating it.

Two details are worth noting. First, the policy outputs PD gains alongside joint targets, meaning the network itself modulates how stiff each joint is, which is common in learned humanoid control. Second, recovery targets and the recovery gate "remain runtime inputs, not baked goals," so the application decides when the robot should try to get up or rebalance.

Why does a browser-runnable policy matter?

Most humanoid control research ships as training code that needs a GPU cluster and a simulator install. Shipping the finished policy as ONNX, with MuJoCo compiled to WebAssembly, means someone can try the behavior with no install at all. That lowers the barrier for students, game developers and researchers who just want to see what a modern learned controller does when pushed.

It also matches NVIDIA's broader pattern of releasing humanoid pieces in open form. Earlier this year the company showed real-time character motion on the same robot in its MotionBricks work for Unitree G1, and its FLORA open models target the data side of robotics. Metatron sits closer to the control layer. The model card links to NVIDIA's ProtoMotions framework, whose GitHub repository describes a GPU-accelerated approach to training simulated humanoids, and to the NVIDIA Open Model License.

How do you try it?

The model card is clear that the ONNX files "alone are not complete demos." The applications supply the physics, observations, task goals and control logic. In practice:

1. Download the files from Hugging Face, pinning to a specific commit rather than main, as NVIDIA recommends for reproducibility.
2. Load them with ONNX Runtime Web in a WebGPU-capable browser. CPU and WebAssembly work as a fallback but "does not guarantee real-time six-robot operation."
3. Pair each file with its matching application. Preserve joint and body ordering, quaternion convention, history ordering, normalization, target masks, control rate and action mapping.
4. If you host the files publicly, remember that browser delivery needs anonymous access, and never embed a Hugging Face token in client-side code.

NVIDIA reports that for the demo export, native-to-ONNX checks show maximum absolute errors below 3.1e-6 across the checked outputs, with recovery enabled and disabled. It labels these "numerical export checks, not task-success or real-robot benchmarks," and G1 Racer runs action-parity fixtures at startup.

What should a developer check before wiring it up?

Because the policy is a closed graph with a strict interface, most integration bugs will come from mismatched conventions rather than from the network. The model card points to a handful of places where things typically break, and it is worth turning them into a checklist before you write any glue code.

• Tensor signatures. Use the matching runtime manifest and the ONNX tensor signatures for exact layouts. Do not guess shapes from the description above; the card says the manifest is the authority.
• History handling. The demo pipeline consumes eight historical state samples and the raw-action history. If you feed them in the wrong order, or forget to push raw_action back in on the next step, the policy will behave as if it had amnesia.
• Joint and body ordering. The G1 has 29 controlled joints. A different joint order than the one the policy was trained on will produce plausible-looking but wrong targets.
• Control rate and action mapping. PD targets and gains only make sense at the control rate the policy expects. Match the paired application, not your simulator's default timestep.
• Batch size on Racer. The six-robot network is exported for a fixed batch. Changing it means rebuilding and validating the graph.
• Recovery gating. The recovery_enabled input is explicit. Decide in your own runtime logic when to switch it on, and test both states, because NVIDIA's numerical checks cover recovery enabled and disabled separately.

If you only want to watch the behavior, none of this applies: use the matching browser applications and let them handle the plumbing. If you are building your own simulator harness, expect to spend most of your time on these conventions.

What are the limits and safety caveats?

This is where the card is most useful, because humanoid demos often imply more than they show. The listed limitations:

• Recovery, balance and tracking "can fail, especially outside the evaluated states, terrain and command distribution."
• Game mechanics like launch assists, low-gravity zones and respawns are application features, "not capabilities guaranteed by the learned policy or physical robot."
• It is not a collision-avoidance system or a safety controller.
• Hardware use "requires independent validation, appropriate joint/torque limits, supervised testing, and an emergency-stop mechanism."
• Not a training-reproduction package: no dataset or checkpoint.

The honest reading: this is a showcase of a locomotion and recovery policy, not a drop-in controller for your robot. If you plan to touch real hardware, treat it the way you would any research code, and read our notes on how fast robot demos get overstated in the Unitree H2 endurance claims.

Humanoid robot silhouette walking, illustrating the NVIDIA Metatron G1 walking policy

How does the license work?

The weights fall under the NVIDIA Open Model License, and the card says the complete agreement governs rather than the summary. Equally important is what the license does not cover. The card states that model licensing "does not grant rights to motion datasets, recovery reference clips, robot meshes, game assets or third-party runtime software." Permission to include a clip inside a demo does not imply permission to redistribute that clip as a standalone dataset. If you are building something commercial or public, you will need to source robot assets and motion data separately and follow their terms.

How does this compare with other open humanoid work?

A few reference points from our recent coverage:

NVIDIA does not publish head-to-head benchmark numbers for Metatron in the model card, so none are claimed here.

What is not known yet

• Training details. The card names a conditional generative control policy with a gated recovery adapter, but no dataset sizes, training compute or success rates.
• Hardware results. Compatibility with real G1 robots is described as a deployment workflow, not a validated result for these exports.
• The demo apps. The card says the availability of the model files "does not change the separate distribution terms or release status of the associated application bundles, motion clips and other assets," so what is publicly playable may differ from what is downloadable.
• Community use. The repository had no likes when we checked, and we found no independent tests posted at the time of writing.

Reward-seeking agent on a path, illustrating the reinforcement learning behind Metatron humanoid control

Why you might care even if you never touch a robot

Two reasons. First, WebGPU inference is maturing. Running a roughly 397 MB policy at control rates in a browser shows how far in-browser ML has come. Our coverage of Opera's WebAI proposal for local models points the same direction. Second, physical AI is converging on a common pattern: simulate at scale, train with reinforcement learning, export a compact policy, then run it close to the device. Metatron is a clean public example of the last step.

Bottom line

NVIDIA's Metatron browser exports are a small, well-documented release: two ONNX files, a clear license, and honest limits. They will not let you build a humanoid, but they do let you poke at a learned G1 controller without any setup, and they are another sign that robotics weights are being published the way language-model weights are.

Related reading

• NVIDIA MotionBricks: real-time motion for Unitree G1
• NVIDIA FLORA open models for robot data engines
• SuperMimic: whole-body humanoid control on one GPU
• Microduck: a $399 open-source RL robot
• Unitree H2 endurance claims: claimed versus verified
• NVIDIA GTC Berlin microduck demo: human-piloted claim
• Official: nvidia/metatron-browser on Hugging Face, ProtoMotions on GitHub, MotionBricks project page

File sizes, license terms and limitations are as stated on the Hugging Face model card on October 27, 2026 and may change.