Before buying a humanoid: seven checks for capability, cost and support
/ GUIDE
A demo is not a complete purchasing specification. Using official G1, NEO and Asimov 1 documents, this guide explains how to check tasks, full costs, development access, repairs and long-term support.
Choosing a humanoid resembles choosing a car: headline performance matters less if the product cannot do your job or be maintained within your budget. ROBO COMPASS uses the following seven checks as a purchasing framework. This is an editorial guide based on official documents, not an independent hardware test.
1. Define one job before choosing a model
Replace “I want a smart robot” with a specific task: moving a particular part between trays, carrying items across a flat floor, or researching locomotion. Specify the object, environment, duration, acceptable failures and how often a person can intervene. Research, home use and commercial operation can lead to different requirements.
2. Separate demonstrations from capabilities you can reproduce
Ask whether a demonstration is autonomous or teleoperated, how the environment was prepared and what happens after a failure. The NEO order page distinguishes basic autonomy from scheduled remote assistance through Expert Mode for unfamiliar complex tasks[2]. That service description is not a promise that every chore will finish without human help. Unitree also notes that some G1 demonstration functions remain in development or testing[1]. Ask what the exact purchased configuration can do at your premises on delivery.
3. Turn the advertised price into a complete acquisition budget
List the robot, hands, computing, spare batteries, charging equipment, shipping, taxes, software charges, training and support separately. A finished unit, kit, deposit and subscription are different purchases. Asimov 1’s repository describes its DIY kit as unassembled and lists tools and hands as excluded items[3]. An advertised price therefore does not establish the cost of a working solution for your task. Compare initial spending and maintenance over the same period; do not invent an annual repair estimate when failure data is unavailable.
4. Verify the edition and your development rights
A series name alone is insufficient. Unitree’s comparison table distinguishes secondary-development support between G1 and G1 EDU[1]. Beyond SDK availability, check joint-control access, sensor access, required computing and commercial-use terms. Distinguish manufacturer training from features that let the buyer train or modify the system.
5. Ask what happens on the day it breaks
Identify the first support contact, repair location, shipping responsibility, diagnosis process, replacement-part prices and expected availability. A warranty period alone does not tell you the likely downtime. Where schedules matter, ask about spares and remote diagnosis. A local reseller may handle a repair or merely forward the request; establish which service is included.
6. Assess open source as practical ownership freedom
A public repository is not enough to establish repairability. Check mechanical designs, electronics, bills of materials, assembly and calibration instructions, control software, learning environments and subsystem licenses. Asimov 1 publishes mechanical/electrical designs, simulation assets and software, and documents both a kit route and self-sourcing[3]. Your next questions are about fabrication, proprietary parts, substitutes and the skills available to you. Greater freedom can come with a greater maintenance responsibility.
7. Separate manufacturer scale from support for your purchase
Funding and partnerships are starting points for research, not guarantees of future parts or repairs. Look at deliveries, release history, documentation, responses to technical questions and written support terms. We do not manufacture funding figures or assign an unsupported company-survival score. The relevant question is whether there is a credible, specific path when an owner needs help.
Buy, trial or wait
A robot becomes a purchasing candidate when your required task is reproducible and the full cost and support fit your constraints. If reproducibility remains uncertain, request a task-specific demonstration or evaluation. Waiting can be reasonable when a required feature is only planned, repair arrangements are unclear or the necessary control access is unavailable. Filter by your requirements rather than treating one headline number as an overall ranking.
Official sources checked on 5 November 2026. Specifications, territories and terms can change; reconfirm before contracting. [1] G1 official product page. [2] NEO official order page. [3] Asimov 1 official repository.
Sources
[1] www.unitree.com ↗[2] www.1x.tech ↗[3] github.com ↗Edited by ROBO COMPASS. This is source-based reporting, not independent product testing.