Best Humanoid Robot Platforms for Developers in 2026

For most developers in 2026, the Unitree G1 is the humanoid you can actually write code for, and Tesla Optimus and 1X NEO are not. The G1 ships a documented interface, other people's code exists to learn from, and a matching simulation model keeps work moving while the battery charges. The verdict flips if your project is arms and speech rather than legs, where a wheeled torso wins, or if what you need is ROS 2 or HORUS rather than a robot. The rest of this post is for a developer or a small team deciding what to buy, or whether to buy anything, in the next quarter.

There is a video you have watched more than once. A machine walks across a stage, catches itself on uneven ground, hands somebody a box, and the comments underneath are arguing about whether it was teleoperated.

You are not trying to settle that argument. You want to write code that makes a humanoid do something, and every path you investigate ends the same way: a waiting list, a form asking which Fortune 500 company you represent, a price quoted only on request, or a launch video with no documentation link anywhere on the page.

The ones you can buy raise a different set of worries. Will the interesting parts be locked behind a signed agreement. Will the walking controller be a sealed box you can only send goals to. Will the thing be bricked by a firmware update, or unsupported in your country, or so fragile that one fall ends the project. Is this a robot or a very expensive statue that needs two people to move it.

And underneath: whether buying anything at all is premature, and whether the developers who look furthest ahead are the ones who never bought hardware and worked entirely on a model of a machine they do not own.

Which humanoid platform should a developer actually build on in 2026?

Build on a Unitree humanoid if you want legs and can spend real money, and on a wheeled humanoid torso such as Reachy 2 if your work is arms, language and behaviour.

Those two cover most developers, and the reasoning is the same in both cases: they are the machines where an outsider can read documentation, get a working interface, find other people's code and keep working when the hardware is unavailable. That combination, and not the specification of any joint, is what makes something a platform.

Everything else divides into three groups. There are research humanoids from established vendors, which are excellent and priced for institutions with grant funding. There are education humanoids that stand knee-high, which teach real lessons about balance and are not the machine in your video. And there are the famous ones, Tesla Optimus, Figure, 1X NEO, which are products rather than platforms, with no route for an outside developer to write code for them.

The comparison of the three most discussed machines has its own post: which of these humanoids is actually open to developers.

What makes something a humanoid robot platform rather than a product?

A platform is a robot whose maker expects you to write code that they did not write, and has done the work to make that survive.

Concretely, that means five things. Documentation you can read before buying, not after signing. An interface into the machine that reaches the joints and the sensors, rather than a list of pre-approved commands. A simulation model of the same robot, so the code you write today runs even though the battery is flat. Other people's code in public, because you will learn more from one repository written by a stranger than from any manual. And a support story that does not depend on a single account manager answering an email.

A product has none of those and does not need them, because a product is finished. The company sells a machine that does a thing, and improving that thing is their job rather than yours.

The confusion is expensive because the most impressive machines are products, and the most useful ones to a developer are platforms. A robot that folds laundry beautifully and takes no code from you is not a place to build a career or a company.

Which humanoid platforms can you actually write code for today?

Roughly eight, and they split by whether the robot has legs and by who the vendor expects to sell to. Unitree's humanoid line, headed by the G1, is the one most independent developers end up on: purchasable, documented, with a software development kit and a simulation model. Booster Robotics sells developer and education humanoids that turn up in competitive leagues. Fourier and PAL Robotics sell serious research humanoids to institutions with budgets. Agility's Digit works in logistics and comes with a fleet layer aimed at operators rather than tinkerers. Reachy 2 gives you two arms and a wheeled base with the designs published. Small education humanoids teach walking basics on a desk. Open hardware designs let you build one yourself. And a simulated humanoid, running the same interface as a real one, is a legitimate platform that costs nothing.

One distinction saves a quarter: the robot is not the layer your own programs talk through. That layer is ROS 2, the vendor's own stack, 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 programs on one machine are not serialised. That project is Apache-2.0 and validated in simulation, and it is not a robot, ships no walking controller and replaces no vendor SDK.

How do the humanoid platforms compare?

Read the last column first, because most developers are eliminated into a platform by budget, floor space and what the robot is actually for, long before anybody compares joints.

No column lists specifications, because no developer was ever blocked by a joint count.

Which platform fits a hobbyist, a research lab, or a startup?

A hobbyist should start simulated and buy small, a lab should buy what its grant and its collaborators support, and a startup should buy the machine that most resembles what the product will be.

For a hobbyist, the honest arithmetic is that a full-size humanoid costs a car and breaks like a laptop. Start with a simulated version of a real machine, write behaviour that works there, and buy a small education humanoid when you want to feel what balance actually means. The lesson that a real motor gets hot and a real battery sags is worth having, and it is cheaper on a knee-high robot.

For a lab, the deciding factors are procurement and comparability. A machine your collaborators also own is worth more than a better machine nobody else has, because shared platforms mean shared code and comparable results.

For a startup, buy the closest thing to your eventual product and expect to replace it. If the plan is a robot working in a warehouse, a walking research machine teaches you less than you hope. If the plan is manipulation and language, legs are an expensive distraction from the actual problem.

What space, power and computers does a humanoid actually demand?

A full-size humanoid needs clear floor in every direction, a harness or gantry for early testing, a charging routine somebody owns, and at least one more computer than you planned for.

The floor point is not a formality. A machine at chest height that falls does not fall politely, and the first weeks of any humanoid project involve falls. Teams that skip the gantry pay for it in repairs and in the caution that follows, because a developer who is frightened of the robot stops experimenting.

Power is the surprise that gets people. Batteries mean run windows measured in a fraction of an afternoon, then charging, then a second battery, then a routine for swapping without dropping anything.

Computers are the other surprise. The robot has its own computer running balance, and you will want another one for perception, language models and whatever else your project actually is. That second machine is where your code lives, where things compete for processor time, and where a stack that hesitates makes the robot hesitate. Which programs run where, and how they talk, is covered in what software runs inside a humanoid robot.

How soon do you need the robot to do something in front of someone?

If a demo is due within a month, use the vendor's own stack and their example programs, and postpone every architectural decision until afterwards.

Humanoids punish ambition on short timelines in a specific way: the impressive parts, walking and balancing, already work, and the parts you add are the parts that break. A demo that uses the vendor's walking and adds one clear behaviour on top will land. A demo that replaces the walking controller will not, not in a month, no matter how good the team is.

On a horizon of a quarter, the calculation changes and it becomes worth building your own layer, because the vendor's examples are structured for demonstrations rather than for a program that runs all day, and you will hit that wall eventually.

Beyond a year, assume you will replace the machine. Humanoid hardware is moving quickly, and the code that survives is the code that treated the robot as an interface rather than as an assumption. Teams who wrote against the vendor's structure everywhere find that migration expensive, and teams who kept their own boundary find it merely tedious.

What should you already know before buying a humanoid?

Linux, one language properly, and enough respect for machinery that you plan the stop switch before the first run.

Beyond that, the useful preparation is narrower than people expect. You do not need to have implemented a walking controller. You do need to be comfortable when a program starts and nothing happens and there is no error, because that is most of the first fortnight.

The skill that separates people who make progress from people who stall is debugging across several programs at once. On a humanoid, the interesting failures are never inside one file. A message stopped arriving, a process died quietly, two things wanted the same joint, a program woke up too late and acted on stale information. If you have only ever debugged a single program in a single language, that is the gap, and it is worth closing before the hardware arrives.

Simulation is where you close it cheaply. A humanoid model, the vendor's own interface, and a deliberate month of making things fail teaches nearly everything except how heavy the machine is.

What goes wrong in the first month with a humanoid?

The robot works perfectly out of the box, then stops working the moment you add your own code, and the first month goes into finding out why.

The pattern is consistent. The vendor's demo runs. You add perception, and the robot starts hesitating. You add a language model, and hesitation becomes stumbling. Nothing has crashed, no error appears, and the robot is simply worse than it was on day one.

What has happened is almost always that your programs are competing for one computer, and the loop that keeps the machine upright is no longer getting its slot on time. The balance controller expects fresh information on a rhythm, and your camera pipeline has quietly stolen the moment it needed.

The second common failure is the recording problem. Something goes wrong once, dramatically, and nobody can reproduce it because nobody was recording what each program saw. Set up recording before the robot walks, not afterwards, because the interesting failures are rare and expensive.

The third is human: one person becomes the only one who can start the robot, and the project moves at their calendar.

What do you give up by choosing the most open platform?

You give up support, polish and somebody to blame, and you accept that a broken machine is your problem to solve.

The vendors who sell to institutions include engineers who answer questions, spare parts that arrive, and a warranty that survives an experiment going badly. The open, purchasable machines are cheaper for exactly that reason. When a joint fails on a Friday, the difference between a support contract and a community forum is the difference between a delayed week and a delayed month.

You also give up a certain amount of documentation quality. Vendor manuals aimed at institutions are thorough because a procurement process demanded it. Documentation aimed at developers is often a repository, a few examples and a community thread, and the parts you need most are the parts nobody wrote down.

And you give up stability. Firmware changes, the interface shifts between versions, an example that worked in a video no longer runs. That is the tax on buying from a company moving quickly, and it is a real tax, paid in afternoons. What you get in exchange is a machine you own and can actually modify, which is the entire point.

When is ROS 2 the better choice?

ROS 2 is the better choice for most humanoid projects that involve anything other than walking. Choose ROS 2 when the robot must navigate a building, when you need a motion planner for the arms, when cameras must be calibrated against grippers, when a fleet needs monitoring, or when the code has to be handed to another team who will expect the conventions they already know.

Choose ROS 2 when your humanoid is a research vehicle in a group that already runs ROS 2 on everything else, because the value of a shared vocabulary is enormous and the cost of being the one person on a different stack is paid daily. Choose ROS 2 when the vendor's own bindings are written for it, which is common, and detailed for one machine in what works out of the box with a Unitree G1.

HORUS is not the answer to those needs. It ships no navigation, no planner, no calibration tools and no package ecosystem, and a humanoid project that needs those needs ROS 2. The narrower case arrives later, when several of your own programs share the robot's computer and the machine starts hesitating under load.

Do you need to buy a humanoid to develop for one?

No, and here is why: the machines worth developing for publish simulation models, and the code you write against a model is the same code that runs on the metal.

For locomotion and manipulation work, this is not a compromise. Policies for walking and grasping are trained in simulation as a matter of course, because a real machine cannot survive the number of attempts learning requires. Buying hardware first inverts the process: the robot sits charging while you write the code that will eventually use it.

What simulation cannot give you is the physical stuff. How heavy the machine is when you lift it onto the gantry. How a joint feels when the motor is warm. How different the room looks to a real camera. How quickly a battery goes from working to not. Those lessons need hardware, and they matter, and they arrive later than people think.

The sequence that works for most developers is simulation first, hardware when a specific question demands it. If the question is about grasping and contact rather than the whole robot, choosing between MuJoCo and PyBullet is the decision that actually matters.

Will a single learned model handle the walking and the hands for you?

Partly, but not the way you think: learned models handle more of the humanoid stack every year, and they sit inside a system that still has to be built and kept running.

The learned parts are real. Walking on uneven ground is now largely a trained policy rather than hand-written equations, and grasping is heading the same way. That is a genuine change and it means a small team can attempt things that needed a department a decade ago.

What does not disappear is everything around the model. Something has to get camera frames to the model, get the model's output to the joints on time, decide what happens when the model produces nonsense, stop the robot when a person walks in, log what happened, and restart cleanly after a fall. That scaffolding is most of the code in every working humanoid.

The failure mode to watch for is a system that behaves differently every run while the model is unchanged. That is not a model problem. That is programs on one computer arriving late, and no amount of retraining fixes it.

How do you decide which humanoid to commit to this quarter?

Decide by what the robot must do in front of a person twelve months from now, then buy the cheapest machine that lets you practise that thing honestly.

Most regretted humanoid purchases come from buying capability rather than a question. A team that wants to explore language and manipulation buys a walking machine because walking is impressive, then spends a year on balance problems that have nothing to do with their product. A team that needs legs buys a desktop humanoid because it was affordable, then discovers that the lessons do not scale.

Two checks settle it. First, what does your code need to touch: if the answer is only high-level commands, you do not need an open machine and you may not need a machine at all yet. Second, who else has one: a platform with other developers around it is worth more than a better machine you are alone on, because you will be reading their code at two in the morning.

If neither check decides it, stay simulated for one more quarter. Nobody ever regretted the code they wrote before buying.

• If you want legs and can spend real money -> a Unitree humanoid, because that is the walking machine an outsider can own and modify.
• If your project is arms, speech and interaction -> Reachy 2 or a similar torso, because legs are a year-long distraction from your actual question.
• If you have a grant and need support -> a Fourier or PAL research humanoid, because a warranty and an engineer on the phone are what grant money buys.
• If you are learning alone -> a simulated humanoid plus a small education robot, because the first year of lessons costs almost nothing.
• If you are deploying into a warehouse -> Agility Digit or a vendor partnership, because operations, not research, is the work.
• If the robot hesitates once your own code runs -> look at the layer underneath, because the fault is timing between programs rather than the machine.

The HORUS Fit Framework reduces that layer to five things 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, and licence matters more than expected on the day a customer asks what exactly they are buying.

The week your humanoid starts hesitating under its own software is a bad week to begin researching middleware. Put HORUS on the shelf before then: star it so it is in your list when you start building.