Sarah Guo popped a 67-TOPS robot brain into a Jacquemus Mini handbag and gave NVIDIA the friendliest pitch it has ever made: bring the bag, Jetson brings the robot brain.
It is a genuinely charming argument. A robot's neural engine, desktop-class generative AI, small enough to swing off a designer clutch — free, portable, cloud-independent.
The question you should ask before taking the bait is what, exactly, you sign up for when you slide that module out of the bag.
Last week, we tracked NVIDIA's lock-in thread through Jetson Thor's T2000 and T3000 launch and asked whether any competing accelerator or simulator could revalidate trained policies. This week, the test sharpens.
Start with what is actually open, because the list is real and worth respecting.
The model weights are open. NVIDIA's Nemotron and Cosmos world foundation models ship as open models, and the Jetson tutorials reportedly lean on outside open-weight models too — Mistral, Gemma, Qwen.
The inference stack is open and off-the-shelf. NVIDIA's own livestream teaches developers to launch models with Ollama, vLLM, and llama.cpp, and explicitly tells them to choose the right inference engine for the job.
Newton is open source. The physics engine released as 1.4 at SIGGRAPH is co-developed with Disney Research, Google DeepMind, and NVIDIA, and its source is public — this is the engine whose snow solver taught Disney's robotic Olaf to walk.
And the "no cloud APIs required" promise is not marketing vapor. The Reachy Mini assistant runs voice and vision fully on-device — no cloud, no API keys, no internet at runtime. That is a real capability, and it is the emotional center of the whole campaign.
Now catalog what is not open, and watch the funnel take shape.
The training loop is not the physics engine. Newton runs the physics; the reinforcement-learning workflow that turns physics into a walking policy reportedly lives in Isaac Sim and Isaac Lab. That is where, per NVIDIA, the real2sim2real navigation demos with Niantic Spatial and Flexion AI actually happened — end to end, on Isaac.
Open the box and you find that the free, portable, cloud-independent part is inference — running a trained model. The part that produces the trained model is stitched to NVIDIA's toolchain.
That distinction is the entire game. Weights are portable. The pipeline that generates weights for a specific robot embodiment is not.
Then there is the reference platform, which is openness dressed as infrastructure.
Hyundai and NVIDIA announced a Robot Reference Platform pitched as a "standardized development environment" to help "universities, research institutes and startups build, validate and advance physical AI." Read that as an on-ramp, because that is what a standardized environment is.
It reportedly relates to a 50,000-Blackwell-GPU buildout. When you hand universities and startups a standardized way to build and validate robots, you are defining the default. The default is not neutral.
A generation of Korean robotics researchers — at KAIST, at Seoul National University, through the new NVIDIA AI Technology Centers — will, per NVIDIA's plans, learn physical AI on Nemotron and Cosmos. That is not a product sale. That is a curriculum.
And the third layer, the stickiest one, is the trained-policy format. A trained policy is a learned artifact tied to a specific simulator's physics, a specific embodiment description, a specific reward and observation stack.
There is no exit door on that artifact. Weights you can copy. A policy validated against Isaac's physics is validated against Isaac's physics — nowhere else, until someone proves otherwise.
This is why the openness is the funnel, not the freedom. Open weights and Ollama get you in the door. The reference platform sets the default. The training loop and the policy format are where you stay.
The lock-in has migrated. It used to live in the silicon — buy the GPU, get CUDA. Now the silicon is the least of it. The lock-in lives in the physics engine you validated against, the reference environment you learned in, and the policy artifact nobody can yet revalidate elsewhere.
The lock-in has migrated. It used to live in the silicon. Now the silicon is the least of it.
Which brings us to AMD, and the only question that matters.
On hardware, this is a real contest. A robotics company that wants dual-sourced compute, better pricing leverage, or supply-chain insurance has a genuine reason to look at alternatives. The socket is contestable.
But a socket is not a workflow. The question is not whether a competing accelerator can run inference — of course it can. The question is whether a policy trained in Isaac Lab, validated in Isaac Sim, can be revalidated on AMD's stack without starting the training over.
If the answer is no — if switching accelerators means re-running the entire simulate-train-validate loop on a different physics engine with a different sim-to-real gap — then the second source wins a hardware line item and loses the customer's development process. The company keeps building on Isaac because rebuilding is the expensive part.
That is the entrenchment. It is not that NVIDIA's chip is irreplaceable. It is that the thing you produced on NVIDIA's chip cannot be trusted anywhere else without redoing the work that produced it.
There is even a hairline crack in the friendly on-device story that hints at how these transfer problems behave. Under the Jetson AI Lab Livestream Series post, one reply asked the sharp question: doesn't Jetson's memory ceiling force you into quantized models that "behave differently in practice," and which sizes actually run clean in the demos?
That is the sim-to-real problem in miniature. A model that fits on the edge is not identical to the model you validated; a quantized policy is not the policy you trained. If a bit-width change alters behavior enough to matter, imagine what a different physics engine does to a locomotion policy.
The revalidation gap is the whole ballgame, and everyone building on the friendly on-device pitch is quietly living inside it.
So the verdict. NVIDIA's announcements are, per the evidence, open-washing with real open components — the openness is precisely calibrated to seed developers into CUDA and Isaac at the toolchain level, where the actual lock-in now lives.
And there is exactly one test that would prove this analysis wrong. Show a revalidation path for trained policies on a competing stack — a way to take a policy trained in Isaac and certify its behavior on non-NVIDIA compute or a non-NVIDIA simulator without retraining from scratch.
If that path exists, the workflow moat leaks and the second-source pitch becomes real competition. If it does not, then the handbag was never the point.
The point was the pipeline you can't fit in it.