1X NEO vs Tesla Optimus vs Unitree G1: Which Is Actually Open to Developers?

The Unitree G1 is the only one of the three you can buy today and write real code for; 1X NEO and Tesla Optimus are closed products. Unitree ships a development kit, message definitions and a simulation model, 1X sells NEO as a household appliance with a waiting list, and Tesla builds Optimus for Tesla. That verdict flips only if you need a supported research platform with a warranty behind it, where a smaller specialist maker serves better, and none of it decides the software layer you write on, which is ROS 2 or a middleware such as HORUS. The rest of this post is for someone choosing which humanoid to spend a research budget, a seed round or a year of evenings on.

You have watched all three videos more times than you would admit. One robot folds laundry in a living room. One walks across a factory floor and sorts parts into bins. One does a backflip, gets pushed by a man with a stick, and stays upright.

What none of the videos tell you is whether any of this is available to you. The pages read like product pages, with reservation buttons and specifications and a delivery estimate, and it took you a while to notice that two of the three never quite say what a buyer is allowed to do with the machine.

So you started searching for developer documentation, and that is where the picture separated. One of them has a public repository with example programs in it and people filing issues about them. One has research papers and a beautiful website. One has an earnings call.

Now you are trying to plan a year of work around hardware, and you cannot tell whether you are choosing between three robots or looking at one robot and two advertisements.

Which of these three humanoids is actually open to developers?

The Unitree G1 is, and the other two are not. Unitree sells the robot to anyone who can pay, publishes a development kit in C++ with a Python binding, ships message definitions that ROS 2 programs can read, and provides a simulation model so work can begin before the crate arrives. That is what open to developers means in this market, and one of the three meets it.

1X sells NEO as a home product. The company publishes research and demonstrations, and what the company does not publish is a way for a buyer to write software that runs on the robot standing in their kitchen.

Tesla does not sell Optimus at all. Units go into Tesla's own operations first, there is no development kit, no purchase route and no external programme to apply to.

So the comparison is shorter than it looks. If your plan involves code executing on a humanoid's own computer within the next year, there is one candidate here, and the remaining decision is about which configuration of it you order.

What does open to developers actually mean for a humanoid robot?

Open to developers has four levels, and vendors are careful about which one they let you assume. The first is that you can buy the robot at all, without a research partnership, an application or an introduction. Plenty of impressive humanoids never clear this bar.

The second is a published interface: a documented way to send commands and receive sensor data, with example programs that run. This is where a robot becomes a platform rather than an appliance.

The third is joint-level access, meaning you can command individual motors rather than only asking for a walk or a pose. Everything interesting in balance, whole-body control and learned locomotion lives at this level, and it is the level vendors most often withhold, because a customer who can command joints can also break the robot in ways the warranty did not imagine.

The fourth is open hardware and firmware, meaning drawings, board designs and the code that runs closest to the motors. No commercial humanoid offers this, and pretending otherwise leads to disappointment. What actually runs inside a humanoid explains why that boundary sits where it does.

What are your real options if you want to write code for a humanoid?

Five options exist, and only three of them involve a humanoid you can order. Unitree's G1 is the volume answer and the reason this question comes up, with a smaller sibling and a quadruped from the same maker offering cheaper ways into the same tooling. Research humanoids from specialist makers cost considerably more and come with support agreements, documentation written for engineers and, usually, joint-level access by default. Small open bipeds you build yourself, the printed and hobby-servo kind, teach balance and control honestly for the price of a repair rather than an invoice. Simulation alone is the fifth option and is underrated, because most of the software you need to write does not care whether a robot exists yet.

The robot is only half the decision. The software layer between your own programs is a separate choice: ROS 2, the vendor's kit, or a middleware such as HORUS, an open-source real-time robotics middleware for Rust, Python and C++ where the three languages share the same shared-memory ring buffers, so messages between processes on one machine are not serialised. Apache-2.0, validated in simulation, and it is not a robot, a controller or a replacement for the vendor kit.

How do the three humanoids compare?

Read the last column first, because most people are eliminated into a platform rather than argued into one, by availability and by budget rather than by preference.

Nothing in that table ranks how impressive each robot looks, because that ranking has no bearing on whether you can build anything.

Are you a researcher, a startup, or a hobbyist?

Those three answers point at three different robots, and the mismatch is where money gets wasted. A researcher whose contribution is the controller needs joint-level access above everything, which means the developer configuration of a G1 or a specialist research platform.

A startup usually needs the opposite. The differentiator is the application, the behaviour, the thing the robot does for a customer, and the walking is infrastructure you would rather buy than build. A standard G1 with the vendor's balance controller underneath is the right shape, and what works out of the box on a G1 matters more than the joint interface.

A hobbyist should almost certainly not buy any of these. A desk-sized biped falls over all evening and costs a printed part when it breaks, which is the only sustainable way to learn a subject that is learned by breaking things.

What can you afford to buy, and to break?

Budget the repairs, not the robot, because that is the number people get wrong. A humanoid falls. It falls during your first joint-level experiment, it falls when a network cable is nudged, and it falls the day someone changes a sign in a controller. Each fall is a risk to a wrist, a hand, a knee actuator or a covering panel, and replacement parts on a humanoid are not commodity parts.

The G1 costs roughly what a decent car costs, and the specialist research platforms cost several of those. NEO is priced as a household appliance and sold with a subscription arrangement rather than as a component. Optimus has no price a stranger can act on.

Then add a test rig, which nobody budgets for and everybody eventually builds: a frame with a strap that catches the robot before it hits the floor. Teams who skip it lose more in repairs and downtime than the rig would have cost.

How long before you need something to demonstrate?

If you need a demonstration this quarter, buy the standard configuration and build on top of the vendor's walking controller, because writing your own is a year of work and you do not have a year. The robot arrives able to stand, walk and be driven around, and everything you add above that layer is where a demonstration actually comes from: recognising something, deciding something, going somewhere on purpose.

If your horizon is a year or more and the contribution is the motion itself, order joint-level access from the start. That decision is made at purchase and cannot be recovered afterwards with any amount of software, which is the single most expensive mistake in this whole category.

If your horizon is a research programme measured in years, spend the first months in simulation regardless of what you buy. Every humanoid worth considering ships or supports a simulation model, and a team that arrives at delivery day with working message handling, logging and behaviour code gets months of value out of a robot that would otherwise sit in a crate.

What if you have never worked on a legged robot before?

Start with something that falls cheaply, because the first three months of legged robotics are spent learning what breaks. A wheeled robot forgives a mistake by driving into a wall. A humanoid answers the same mistake by falling from standing height onto hands that cost real money, and the lesson lands harder than anybody expects.

The things you have not met yet are not programming problems. Safety practice around a machine that can hurt you. A cable that unplugs itself under vibration. A robot that behaves differently on a carpet than on a hard floor. A battery that means every experiment has a clock on it. Knowing when to press the stop button before you consciously decide to.

A beginner's map to programming humanoids is a better first purchase than a robot. So is a small biped, which teaches the same lessons and is far harder to destroy.

What actually goes wrong in the first month with a humanoid?

Networking goes wrong first, and it goes wrong for about a week. The robot expects a particular network arrangement, the examples assume a machine configured a particular way, and until that is right nothing you write can even see the robot. This phase is nobody's research and everybody spends it.

Then the software versions go wrong. Vendor examples are written against an older distribution than the one you installed, and starting on the newest release means the first days are spent fixing build errors in somebody else's package rather than in yours.

Then the coordinate frames go wrong, which is quieter and worse. Something is upside down or rotated, the robot leans toward a wall, and finding it takes an afternoon of drawing arrows on paper.

Only after all of that does the interesting failure arrive: the robot works, then behaves differently on the second run for no reason you can name. That one is timing, and it is where a project stops being about the robot and starts being about the computer inside it.

What do you give up by choosing the open one?

You give up polish, support and the illusion that somebody else has thought of everything. The G1 is a platform sold to people expected to be competent, and the documentation reflects that: enough to work from, not enough to hold your hand. Answers come from a community and from other people's repositories rather than from a support contract.

You also give up guarantees about the parts you did not choose: firmware is closed, some capabilities are gated by configuration, and behaviour can change between releases.

What you do not give up is the thing that matters, which is the ability to run your own software on your own robot and to keep working when the vendor is asleep. The closed alternatives give up exactly that, and no amount of polish compensates. Judging whether an open robotics project is alive is the skill this trade-off demands.

When is ROS 2 the better choice?

ROS 2 is the better choice for almost everything you will build on top of any humanoid, and saying otherwise would mislead you. The cameras and laser scanners bolted to these robots have ROS 2 drivers already. Mapping, navigation, coordinate transforms, visualisation and recorded runs all exist there, tested by thousands of people, and a humanoid project that rewrites any of it has chosen a hobby over a result.

ROS 2 is also right when the system spans more than one machine, when an operator station sits off the robot, and when your team is large enough that shared vocabulary matters more than any technical property.

HORUS is not the answer to those needs, and a project that needs drivers, navigation and an ecosystem should use ROS 2 without hesitation. The narrow situation where a shared-memory layer earns its place comes later: one onboard computer, several of your own programs in different languages, and a balance loop that must receive what perception produced before the next step is committed rather than after.

Will Tesla Optimus open up to developers once it ships?

No, and here is why: nothing about how Tesla builds products suggests an external development kit is coming. Tesla makes vertically integrated machines and controls the software on them tightly, and the stated plan for Optimus has been internal deployment inside Tesla's own operations before any outside customer. A robot deployed that way needs no public interface, and publishing one would create obligations Tesla has consistently avoided in its other products.

Even the friendliest plausible future — a consumer Optimus with an application store — is a very different thing from what a developer means by open. An approved application running in a sandbox is not joint-level access, and it is not permission to run your own controller.

Planning around a hypothetical opening is the expensive version of this mistake. Teams have lost a year waiting for a platform to become available, and the reliable move is to build on hardware you can order now, keeping your own software separable enough to move later if the situation ever changes.

Is the Unitree G1 an open-source robot?

Partly, but not the way you think. What is open is the layer you write against: the development kit, the example programs, the message definitions and the simulation model are published, and the community around them publishes learning environments and controllers that genuinely run. That is a real and useful openness, and it is why the G1 dominates this conversation.

What is not open is the robot. The firmware is closed, the internal control loops that keep the machine upright are the vendor's, the mechanical design is not published, and access to the joints depends on which configuration you bought and what your paperwork says. You cannot rebuild a G1, and you cannot inspect the code that catches it when it stumbles.

Calling that open source stretches the term past usefulness. The honest description is a closed robot with an open development interface, which is a perfectly good arrangement and a completely different thing from the open humanoid projects worth following that publish drawings anyone can build from.

How do you decide which humanoid to write code for?

Decide by writing down what you must be able to command, then striking out every robot that will not let you command it. If the sentence is "I need to command individual joints", the list is one long and the configuration matters more than the brand. If the sentence is "I need a walking base that carries my perception stack", the standard configuration is enough and you have saved yourself a year.

If you cannot write that sentence yet, do not buy anything. Spend a month in simulation with the model the vendor publishes, and the requirement will state itself far more honestly than a specification page will.

And separate the two purchases in your head. Buying a humanoid gets you a machine that walks. Everything that makes it useful — what it recognises, what it decides, what it does for somebody — is software you write, and that software is where your year actually goes. The robot is the cheaper half of the project, whatever the invoice says.

Here is the decision in five lines.

• If you need a humanoid running your code this year -> a Unitree G1, because it is the only one of the three you can order and program.
• If your research is the balance controller itself -> a G1 developer configuration or a specialist research platform, because joint access cannot be added later.
• If you want a humanoid in your home -> 1X NEO, on the understanding that you will live with NEO rather than program it.
• If you are waiting for Tesla Optimus -> build on something else now, because there is no developer route to plan around.
• If your budget is personal -> a small biped you assemble yourself, because falling over should cost a printed part rather than a repair invoice.

The HORUS Fit Framework reduces the software half to five axes you can judge without a benchmark: ecosystem size, setup effort, team size fit, deployment target and licence. For humanoids, deployment target and team size fit usually decide it, since everything has to run on one onboard computer maintained by very few people.

The week your humanoid walks and your own programs start tripping over each other is a bad week to start reading about middleware. Put HORUS on the shelf before then: star it so it is in your list when you start building.