Humanoid Robot Prices and Buying Paths: Compare the Contract, Not the Sticker

A practical comparison of current prices, deposits, subscriptions, quotations and the difference between reserving a place and buying a usable system across Unitree G1, Unitree H1/H2 and 1X NEO, with the evidence a buyer should request before treating a published claim as a purchase requirement.

Start with the decision, not the specification row

The useful question in this guide is current prices, deposits, subscriptions, quotations and the difference between reserving a place and buying a usable system. That question sounds narrow, but it crosses mechanics, software, service and contract boundaries. A specification can be accurate and still fail to answer it. A published maximum may describe one option, one motion or a laboratory condition; a buyer needs to know what the delivered robot can repeat, under what limits, with which human assistance and what remedy applies when the answer is different from the quotation.

The current market also mixes several kinds of product. The Unitree G1 is a compact platform whose base and EDU editions have important development differences. H1 and H2 are full-size machines with different configurations, capabilities and handling demands. 1X NEO is presented as an Early Access home robot with ownership and subscription paths and a managed assistance model. Comparing them is useful only after the buyer states whether the goal is research, application development, industrial evaluation or household service.

Translate the topic into observable requirements

Write a requirement without using adjectives such as advanced, safe, fast, intelligent or production-ready. State an observable condition, a measurement, an allowed tolerance and an evidence source. If the requirement concerns a document, name the issuing party and the exact model or configuration it must cover. If it concerns behavior, specify the environment, starting state, task, number of trials, intervention rule and failure definition.

For this topic, the minimum evidence packet is a dated quote, complete bill of materials, refundable-payment terms, tax and freight estimate, software rights and a written acceptance window. Ask the seller to mark each item as standard, optional, unavailable or buyer-supplied. A blank cell should not become an optimistic assumption. It should become a condition of purchase, a priced integration task or a reason to remove the candidate from the shortlist.

Separate five layers that marketing naturally compresses

Mechanism. Identify the physical parts that create or constrain the result: joints, transmissions, hands, batteries, sensors, thermal paths and structural limits. Ask whether a figure is continuous, peak, nominal or optional. Record the software limit used during the demonstration. The same body can behave very differently after an end-effector change, firmware update or protective speed cap.

Control. Determine which function is built into firmware, which is exposed through an SDK, which runs on an application computer and which depends on a vendor service. Record command rates, latency, failure behavior and responsibility for integration. A platform may physically support a motion that the purchased software edition does not expose or warrant.

Operation. Count preparation, calibration, supervision, resets, charging and recovery as part of the task. A ten-second successful motion can require minutes of staging. If those minutes are omitted, the comparison measures an edited clip rather than throughput. Include the work performed by remote experts and local operators even when it is sold as assistance rather than labor.

Service. Establish the repair path, spare availability, log access, software-update period and support response. A result that depends on a single calibrated unit or visiting engineer is not yet a deployable result. Test whether the buyer's trained staff can restore the robot after an ordinary fault and how long a failed proprietary part leaves the whole system unavailable.

Contract. Preserve the page or demonstration that prompted the purchase, but treat the signed configuration, warranty, license, privacy terms and acceptance schedule as controlling. Product pages change. Quotes expire. A pre-order may establish a queue position rather than a finished sales contract. Put critical requirements into the documents that allocate price, delivery and remedy.

Build a test that can disprove the optimistic assumption

The common failure mode is that budget approval is based on a headline price, but the delivered edition lacks the compute, hands, support or development access required by the project. Design the trial to expose that outcome early, while the robot can still be rejected, reconfigured or limited to a narrower use. Start with manufacturer reference behavior to confirm a healthy system. Then change one variable at a time until the test resembles the buyer's real operating condition.

Use at least three classes of run. A baseline run uses a clear area, known objects, fresh battery and trained operator. A representative run uses realistic surfaces, lighting, network, payload and interruptions. A boundary run deliberately approaches one published or agreed limit without exceeding the safe envelope. Stop conditions must be written before the test so enthusiasm does not redefine a near miss as a success.

For every run, capture configuration, firmware, application version, robot state, commands, sensor health, battery, elapsed time, human interventions, faults, damage and recovery. Video helps explain a failure, but structured logs make runs comparable. Report the distribution rather than the best clip: completed trials, unsafe stops, operator takeovers, resets, mean cycle time and the worst credible recovery time.

Score uncertainty explicitly

A practical comparison table should contain four columns after the vendor claim: source date, quoted configuration, buyer verification and residual uncertainty. This prevents an official but incomplete statement from being treated as false, and it prevents an attractive statement from being treated as verified for the buyer's unit. Use “not established” when evidence is absent. That phrase is more useful than an invented estimate.

Weight each criterion by the consequence of being wrong. A cosmetic preference may need one inspection. A safety, privacy, software-rights or delivery assumption may need contractual evidence and repeated tests. Apply the same burden of proof to every candidate. Do not demand production statistics from one vendor while accepting a showreel from another simply because its product story feels closer to the project.

Use staged commercial gates

The safest buying path moves from information to reversible commitment. Begin with a requirements exchange and written configuration. Continue to a remote or in-person demonstration using buyer-defined cases. If necessary, pay for a bounded evaluation with clear data rights and damage rules. Release the main purchase only when the configuration, delivery, acceptance, warranty and service terms are complete.

Tie payment milestones to evidence the seller can actually provide: order confirmation, configuration freeze, shipment documents, arrival inspection and acceptance. Reserve a fair remedy for mismatch, including repair, replacement, reconfiguration or return. A buyer should not demand a guarantee that experimental AI will solve an undefined problem, but it can require that the quoted hardware and interfaces arrive and pass documented reference tests.

Questions for the final review

• Which exact model, edition, revision and options support the claim?
• Is the evidence a current product page, a signed quotation, a test or an edited demonstration?
• What environment, software, operator, remote assistance and preparation produced the result?
• What can the buyer inspect or test before the payment becomes non-refundable?
• What changes after a firmware update, subscription change, account closure or service outage?
• Who performs recovery, repair, security response and data deletion?
• What is the stop condition, acceptance threshold and contractual remedy?

These questions do not make an emerging market perfectly predictable. They make uncertainty visible and priced. That is enough to distinguish a learning purchase from an accidental open-ended commitment.

Turn the purchase into an acceptance specification

Prices and buying paths should be purchased against a task, not against a showreel. Write one page that describes the operating environment, the objects or payloads, the people who may be nearby, required runtime, permitted network access, maximum intervention and the evidence that constitutes success. This converts broad claims such as “general purpose,” “home assistance” or “industrial research” into a test both buyer and seller can understand.

Separate hardware acceptance from application acceptance. Hardware acceptance checks that the delivered configuration matches the order, boots cleanly, charges, reports healthy joints and sensors, executes supported reference motions, stops on command and arrives without shipping damage. Application acceptance asks whether the buyer's own task works. The seller can reasonably warrant the first without promising the second.

Ask for the complete commercial packet

For a team comparing a research, industrial or home humanoid for a bounded task, the acquisition route is a configuration-specific quotation, reservation, ownership purchase or managed subscription. Before money becomes non-refundable, collect the quotation, configuration schedule, warranty, software license, privacy policy, support plan, shipping terms, battery documentation, declaration of conformity where applicable and every safety or certification document the seller is willing to stand behind. Marketing pages can guide questions; signed documents allocate risk.

Have engineering, safety, security, facilities, finance and legal review the same configuration. Otherwise each group approves a different imagined robot. Engineering may picture an EDU API while finance prices the Standard unit. Security may picture offline use while the application team depends on cloud learning. Facilities may picture guarded trials while a sponsor imagines a public demonstration. Put these assumptions in one bill of materials and operating-envelope document.

Use a conservative commissioning ladder

1. Inventory without motion. Photograph shipping condition, verify serials and options, inspect batteries and record installed software.
2. Power with restraint. Establish the emergency stop, command timeout, user roles, logs and a safe recovery method before free movement.
3. Run manufacturer references. Reproduce supported health checks and basic motions on a clear surface under the documented limits.
4. Add one project variable. Introduce the buyer's sensor, model, payload or task separately so failures have an identifiable cause.
5. Repeat under realistic conditions. Measure success, intervention, energy, temperature, falls, resets and damage over enough runs to reveal variance.
6. Expand access last. People outside the trained team enter the operating area only after controls have been demonstrated and documented.

This ladder is intentionally slower than an unboxing video. It is faster than debugging simultaneous hardware, network, policy and task failures after a public demo has been scheduled.

Import, privacy and liability are configuration-dependent

Do not copy a generic duty percentage into a budget. Classification, origin, destination, declared value, battery handling and current trade measures determine the actual customs treatment. Use a broker and identify importer of record. Confirm who pays when customs requests documents or returns the shipment. Radio approvals, electrical compliance and workplace obligations likewise depend on destination and use; a seller's global availability page is not proof of local approval.

Map every camera, microphone, telemetry stream, remote-support route, mobile app and OTA service. Record destination, encryption, credentials, retention, administrator, offline behavior and deletion. Put the robot on a segmented network during evaluation and observe traffic rather than relying only on a “local mode” label. If recording workers, visitors or household members is possible, establish notice, access and retention rules before collecting real data.

Physical liability cannot be assigned by a sentence in an article. Applicable law, the sales contract, product defect, buyer modifications, operator conduct and the chosen environment all matter. The buyer should insure the actual use and preserve logs, configuration and maintenance records. Never assume the manufacturer absorbs all autonomous-motion risk, and never accept a blanket claim that it absorbs none. Get jurisdiction-specific advice for a consequential deployment.

Measure cost per accepted task, not cost per robot

The purchase price is only the first denominator. Track engineer setup time, operator supervision, failed attempts, charging, battery aging, replacement parts, service travel, software subscriptions, network service, floor-space controls and the time spent preparing the environment. Then divide by accepted task cycles under the conditions that matter. This calculation prevents a low acquisition price from hiding a platform that consumes a full-time operator, and it prevents an expensive platform from being rejected when it reliably replaces a genuinely costly process.

Set a learning budget before commissioning. Decide how many weeks, engineering hours, falls, damaged consumables and vendor support cases are acceptable before the team pauses or changes scope. Record failures as structured observations: command, software version, environment, robot state, intervention and recovery. Video is useful evidence, but it should accompany logs rather than replace them. A failed trial that identifies a repeatable boundary has value; an endless sequence of undocumented demonstrations does not.

Plan the exit while the robot is still working. Determine how accounts are closed, credentials and recordings deleted, batteries shipped or recycled, licensed software removed and hardware resold, returned or stored. A platform with no supported transfer or decommissioning route carries a residual cost that belongs in the original decision.

A purchase-order checklist

• Exact model, edition, revision, serial-number range and included end effectors.
• Compute, storage, sensors, controller, batteries, chargers, cables and case.
• SDK and firmware versions, API level, source access and update policy.
• Permitted development, commercial use, model ownership and redistribution rights.
• Safety documents, certified standards and the exact configuration in their scope.
• Price, currency, tax, Incoterms, freight, broker, duty and importer of record.
• Delivery window, cancellation, acceptance period and remedy for mismatch.
• Warranty duration, excluded uses, spare prices, service location and response time.
• Telemetry, remote access, privacy controls, retention and offline capability.
• Training, installation, maintenance schedule and safe decommissioning.

Bottom line

Treat current prices, deposits, subscriptions, quotations and the difference between reserving a place and buying a usable system as a testable acquisition requirement, not a label or single comparison-cell answer. The right purchase is the configuration that passes a written task, safety and service case at a defensible landed cost. Preserve the source page, quote, software version and acceptance evidence together. That record is what lets a team distinguish a capable platform from a compelling demonstration and keeps the next software update or repair from erasing the basis of the decision.