Metatron-v1: NVIDIA's Quiet Humanoid Policy Is Not a Language Model

Late on 27 October 2026, a repository called nvidia/Metatron-v1 appeared on Hugging Face. There was no press release, no post on NVIDIA's own blog — searching that blog for the name still returns "No Results Found" — no paper, and no product page. What did appear was two ONNX files of roughly 403 MB each, a licence, a NOTICE file, and a model card describing a learned walking-and-recovery controller for a Unitree G1 humanoid. Metatron-v1 is a robotics policy, not a language model, and almost everything worth knowing about it has to be read out of that card, because nothing else exists to read.

The repository's own counters describe how quietly this landed. Six commits between 21:43 and 22:32 UTC, three likes, and no meaningful download figure at all — the page says downloads are not tracked for this model, while the API reports zero. That is not a launch. It is an export dump with documentation attached, published under NVIDIA's open model licence and left for someone to find.

The name is the first thing that misleads

Metatron sits one letter away from Nemotron, NVIDIA's actual open language-model family, and the resemblance is doing damage already: the same Hugging Face organisation publishes both, the tags on this repository read robotics / reinforcement-learning / humanoid, and the pipeline tag is reinforcement-learning rather than text-generation. None of that stops the name from being filed next to chat models.

It matters because the comparison is not merely unfavourable — it is meaningless. A reader who lines Metatron-v1 up against Gemma 4 12B or Qwen 3.8 is holding a controller that maps joint history and goal poses to motor targets beside models that map text to text. There is no shared input, no shared output, and no benchmark that could place them on one axis. The honest version of that page would be a single sentence, which is why we have not written one.

What the policy consumes and what it produces

The card is unusually specific about tensors, which is the most useful thing about it. The single-robot demo file takes 39 inputs in total:

• Current G1 state, plus eight historical state samples — the policy sees about a tenth of a second of recent movement, not one snapshot.

• Paired incoming raw actions and a nine-entry raw-action history, so the network can tell what it was already trying to do.

• Masked future pose, style and velocity goals, plus scene-box context — the goals are partly specified and partly blank, which is the MaskedMimic-style inpainting idea the card alludes to.

It returns joint PD targets as action, the gains as stiffness and damping, and raw_action for history feedback. Those three outputs are what a robot needs at control rate; there is no text anywhere in the interface.

Two claims in the card are worth separating from the rest. The first is that walking, scene interaction and recovery now share one policy — the card describes the current export as the epoch-6410 "SAMP-capable unified student" with no separate recovery adapter. SAMP is not spelled out, but in the scene-aware motion literature it stands for Stochastic Scene-Aware Motion Prediction, and the scene-box inputs fit that reading; treat the expansion as our inference, not NVIDIA's wording. The second is that recovery targets stay live runtime inputs rather than baked goals, which is the difference between a policy that can be re-aimed mid-fall and a fixed animation.

Two exports, two runtimes, one set of weights

Both files carry the same learned policy in different graph layouts, and the card is emphatic that they are not interchangeable. The demo file runs one robot and includes observation processing and action conversion inside the graph. The Racer file is a six-robot batched network that expects observations computed outside the graph, and its batch size cannot be changed without rebuilding and revalidating it.

The only numbers in the entire repository are a parity check: the six-robot path was compared against the single-robot demo export on 60 distinct and history-perturbed test states, with a maximum absolute action error of 5.55e-6. NVIDIA also varied recovery height, recovery timing, action history and scene inputs and confirmed the outputs moved in response. Both of those are export-engineering checks — they prove the two graphs compute the same function and that the inputs are wired up. They say nothing whatsoever about whether the robot stays upright, and the card says so directly: "These are numerical export checks, not task-success or real-robot benchmarks."

What NVIDIA has not said

The absence list is longer than the presence list, and it is the part a reader should weigh most heavily.

• No announcement, blog post, paper or product page that we could find, and no NVIDIA blog coverage under the name at all.

• No training description beyond two phrases — MaskedMimic-style transformer student, deterministic prior and decoder — and no indication of data, compute or training objective.

• No task-success rate, no fall-recovery rate, no sim-to-real result, no video we can independently verify.

• No training checkpoint and no dataset. The card states plainly that the repository is not a complete training-reproduction package, which means there is nothing here to fine-tune.

The safety language is equally direct: the model is not a collision-avoidance system or a safety controller, hardware use requires independent validation, torque limits, supervised testing and an emergency stop, and the game-side assists — launch boosts, low-gravity zones, respawns — are application mechanics rather than capabilities of the learned policy. A card that goes out of its way to say a respawn is not a capability is telling you something about how much of the demo is the policy and how much is the game.

The licence tells you what you may not take

The files are released under the NVIDIA Open Model License, with attribution in NOTICE.txt and a separate grant covering the two ONNX exports specifically. Everything around them is carved out. The repository grants no rights to motion datasets, recovery reference clips, robot meshes, game assets or third-party runtime software, and the NOTICE file adds a pointed line about "standalone redistribution of demo-only motion clips" — permission to show a clip inside a demo does not travel with the clip.

Practically: you may redistribute the policy file under the licence terms, and you cannot rebuild the demo from this repository, because the meshes, clips, runtime code and application configuration are distributed elsewhere and under their own terms. The card also notes that public browser delivery requires anonymous access to the files, which is a hint about the delivery model the export was built for.

Who can actually do something with this today

Not many people, and the card is honest about why. The browser integrations run MuJoCo compiled to WebAssembly for physics and ONNX Runtime Web for inference; WebGPU is recommended, and the CPU/WASM fallback "does not guarantee real-time six-robot operation." Integration requires the matching runtime manifest and identical joint and body ordering, quaternion convention, history ordering, normalization, target masks, control rate and action mapping. Get one of those wrong and the policy will run happily and produce nonsense.

Deployment beyond the browser is mentioned — other simulators, real G1 hardware — but with no recipe attached, and the card explicitly declines to certify that these exact files were validated on hardware. For a research team with a G1 and a MuJoCo scene, that is enough to start. For everyone else it is a reference artifact.

Where a router fits, and where it does not

You cannot call Metatron-v1 through an API, and nothing here changes that: what NVIDIA published is a pair of files you load next to a simulator, not a hosted endpoint. What we route is the other half of a robotics stack — the language work that surrounds a controller. Task plans written before the policy takes over, telemetry and failure logs summarised after a run, motion captions turned into structured goals. OrcaRouter puts 200-plus models behind one key at provider list price with no markup, and fails over automatically when one provider's endpoint goes down, which is the difference between an evaluation harness that finishes overnight and one that quietly loses half its runs.

That is the whole of the connection. If your question is which controller to load into MuJoCo, this article is the wrong place to answer it, and no routing decision will help.

What would change this story

Four things, in rough order of how much they would matter. A real announcement with task-success numbers on hardware would turn a card into a claim. A training checkpoint or a dataset would make the policy adaptable rather than fixed. An independent reproduction in a public simulator would let someone other than NVIDIA say whether the unified scene-and-recovery design works. And the application bundles shipping publicly — the browser demo and the six-robot Racer — would let the rest of us see what the policy actually looks like in motion, which is the one thing a model card cannot show.

Until then the interesting fact is not the policy. It is the publication pattern: NVIDIA put a humanoid controller on the open hub with a licence and a careful limitations section, told nobody, and let the card carry the weight a launch post used to carry. Six commits, three likes, and a download counter that never started. That is what a release looks like when a company has decided the artifact is the announcement.