Your Personal Open-Source Humanoid Robot for $8,999 — Jingxiang "JX" Mo, K-Scale Labs

How can a developer experiment with a humanoid when the available machines are expensive and proprietary? Jingxiang “JX” Mo, a founding engineer at K-Scale Labs, introduces a platform intended to open hardware, software and machine-learning models together. Labor shortages, household work and off-world exploration motivate the project; they are application goals, not a list of tasks the robots already perform.

The ambition is general-purpose robotics that people can build on, rather than technology available only inside a few companies. At the time of the talk, K-Scale has roughly fifteen people in Palo Alto and is preparing to launch its robots. The product and delivery plans throughout the presentation describe that launch period.

K-Bot is a 4-foot-11-inch humanoid with an aluminum body and a reinforcement-learning controller for locomotion. Mo describes it as built in five months, with sensors intended to support manipulation and other applications. Preorders are open during the presentation, with October delivery planned.

The physical demonstration is direct: someone kicks the robot, and its controller handles the disturbance. This makes the learned motion policy tangible before the training machinery appears later in the talk. K-Bot also supports VR teleoperation with hands, and Mo describes running different locomotion and manipulation policies trained in K-Scale’s own framework. The kick is a demonstration of disturbance handling, not a quantified durability test.

Affordability starts with simplifying the machine. Mo presents K-Bot as an approximately $9,000 development and research platform—the $8,999 offer named in the recording’s title. His contemporary comparison puts the next-cheapest research option, a Unitree robot, at roughly $40,000 and a UR5 arm at roughly $15,000. Those are his estimates: the relevant distinction is a development-capable configuration, not simply the lowest advertised humanoid price. Unitree’s specifications distinguish base and development configurations.

The proposed open release extends beyond application code: a bill of materials, CAD designs, electronics, PCBs, software and machine-learning models are all part of the replication promise. That scope matters because modifying a physical robot can require changing its mechanical interfaces and electronics as well as its controller.

Modularity gives developers several ways to adapt the same body:

• End effectors: replace a five-finger hand with a parallel gripper, a UMI gripper or another tool using the mechanical interfaces.
• Limbs: replace legs or arms to repair damage or adopt a new hardware revision.
• Head and compute: replace the head as newer NVIDIA compute becomes available.

The intended upgrade procedure is mechanical replacement of a module, rather than replacement of the entire robot. A Python/Rust SDK then provides the programming interface.

Mo describes package installation as the entry point for programming. For locomotion, developers could use NVIDIA Isaac Sim to train a PPO policy; K-Scale itself uses MJX. Vision-language models and language models could also run through cloud services when local execution is unsuitable, alongside vision-language-action policies.

The default arm has five degrees of freedom, with a seven-degree-of-freedom replacement proposed for research that needs it. Hardware changes are paired with planned model and software improvements through over-the-air updates, which Mo envisions rolling out roughly weekly.

The disclosed component set includes MIT Cheetah actuators, IMUs, audio modules, displays and cameras. Mo states an upper compute figure of 250 TOPS, but does not disclose the full specifications or the accelerator configuration and numerical precision behind that figure.

He dates the K-Bot effort to October of the preceding year and reports progress into mass manufacturing, with another completed design still unrevealed. The lineage begins with Stompy, a full-size, 3D-printable humanoid, proceeds through a prototype and then reaches the version developed with manufacturing partners. The slide makes that progression concrete: Stompy—May 2024, K-Bot V1—October 2024, and K-Bot v2—February 2025. The product website is the destination for the upcoming launch.

What if a developer cannot spend $9,000 on a humanoid? Z-Bot is the smaller entry point: approximately 1.5 feet tall, originating in a hackathon project that gained attention on Twitter and WeChat. K-Scale is bringing it toward mass manufacturing as well, although Mo gives no Z-Bot price.

The useful connection between the two sizes is their shared locomotion and software stack. Mo’s example is a voice-chat application: code written for the small robot can also be used on the large one. Z-Bot has a locomotion policy and simulator support, so its role is more than being a miniature display model.

Google DeepMind’s robot-soccer work inspired the small robot’s direction: a humanoid that can run around and play. The printable version also created a community before the manufactured product. Mo estimates about 5,000 Discord members and a few hundred people who built the 3D-printed robot.

He dates the Z-Bot project to November, describes manufacturing and launch as upcoming, and invites people to try the machines at recurring hackathons. Like K-Bot, Z-Bot is intended to be fully open source.

Autonomy is the next layer above the hardware. K-Scale’s proposed architecture separates high-level action selection from whole-body motion:

Both parts are still under development. A Rust firmware and software architecture powers the robots beneath those policies.

The developer-facing goal is a reusable Python application: someone implements a particular use case and shares it so other robot owners can run it. Mo likens the resulting ecosystem to an app store. That requires tools spanning learning, execution and access to the physical machine, rather than an isolated model release.

The GPU-accelerated learning framework uses MJX for locomotion and manipulation training. This is where K-Scale trained the RL controller used in the earlier kick demonstration. Integration and fine-tuning of generalist policies such as π0 and NVIDIA GR00T are work in progress: the aim is to make useful new models straightforward to run on the robot.

K-Scale OS, or KOS, provides the software framework and Python interface for programming in Python or Rust. Mo contrasts its intended package-and-connect experience with the setup burden he encountered in ROS 1 and ROS 2. His spoken installation command is pip install kos; the inspected KOS README instead uses the pykos Python client.

The connection target is an IP address. KOS Sim, the digital twin, exposes the same gRPC control interface as the physical robot. An application can therefore change its communication target without changing the interface it calls. Using the documented client shape, a small Python entry point can make that endpoint explicit:

import argparse
import pykos


def connect():
    parser = argparse.ArgumentParser()
    parser.add_argument("--ip", required=True)
    args = parser.parse_args()
    return pykos.KOS(args.ip)


if __name__ == "__main__":
    robot = connect()

Pass the simulator’s IP while developing, then the robot’s IP when targeting hardware. That switches the communication endpoint; physical policy performance still needs validation.

Because the simulator is open source, developers can start programming without owning a robot. Together, the operating-system and learning layers provide the route from policies and VLA models to applications on the hardware.

The training walkthrough connects those layers into a sequence for learning locomotion and manipulation—walking, grabbing objects or even dancing. Its first step is deliberately small: clone the training repository and invoke its Python training module. Mo describes the walking example’s train.py as about 500 lines, runnable on a local GPU or a rented RunPod machine using MJX acceleration.

1. Start training. From the cloned repository, run the demonstrated entry point:

   bash

   python -m train
   

2. Tune the task. Training runs through millions of iterations of the robot attempting the desired behavior. Reward functions are adjustable, so the developer can change what the policy is encouraged to do.

3. Inspect learning. Use TensorBoard to follow loss and reward during training.

Mo estimates one to two hours to train a walking policy, without specifying the GPU or exact training configuration.

4. Evaluate in KOS Sim. Run the trained policy and inspect the actual behavior: is the robot walking, standing or picking up objects as intended?
5. Target hardware after evaluation. Once the simulated behavior is satisfactory, change the target IP to the physical robot.

This puts a behavioral check between optimization and deployment. Reward plots show how learning progresses; the simulated rollout shows what the resulting policy makes the robot do.

Mo estimates that the workflow can get a robot working in roughly one-tenth the time needed to set up other training libraries, but supplies no controlled comparison. The concrete reduction in setup work comes from packaging training, observation, simulation evaluation and hardware access into a connected workflow.

A team of roughly fifteen people covers hardware, software and machine learning with help from an open-source community. Mo reports around 5,000 relatively active Discord participants across several servers, public bounties and contributions encouraged by MIT-licensed software. That licensing description should not be extended to every artifact: individual hardware and software repositories have their own terms.

Recurring hackathons give contributors access to the machines and a place to try applications. The prepared talk closes with hiring needs in electrical engineering, firmware and machine learning, and a plan to launch the robots and software stack in two to three weeks. The audience questions then turn from the development platform to its practical operating limits.

The robot uses a battery that slots into place and clicks in. Asked about the trade-off between battery weight and operating time, Mo reports about two hours of walking in tests so far. Wall-power passthrough also allows the robot to operate while charging. He does not give a battery mass or quantify the weight-versus-runtime trade-off.

Are the first customers factories or households? Mo contrasts Figure’s and Tesla’s factory-oriented strategies with K-Scale’s ambition to become a US consumer humanoid company, selling to people interested in developing robotics. An accidental Shopify launch brought unexpected purchases from people interested in household tasks, programming and research. Companies also expressed interest in building B2B applications, including food-related work like the earlier conference demonstration.

A follow-up about unloading a dishwasher exposes the distinction between an accessible platform and an autonomous appliance. Current use is largely limited to teleoperation, Mo says. His broader assessment that nobody yet has a fully working VLA is best read in the context of general household readiness, rather than the absence of task-specific VLA demonstrations. A navigation and VLA stack that could support clothes folding or dishwashing remains a hope tied to improving model capabilities, not a demonstrated K-Bot feature.

The ROS question asks what K-Scale gains or gives up by building outside that ecosystem. Mo acknowledges ROS’s strengths in nodes and asynchronous communication. His architectural rationale is specific to this robot: a policy-based machine with relatively few sensors requiring complicated asynchronous coordination. That reduces the need for the communication machinery he associates with ROS.

There is also a developer-experience preference. After frustrating ROS 1, ROS 2 and Ubuntu setup experiences, Mo wants a robot that arrives able to stand or walk and can be programmed from the purchaser’s existing computer. The desired starting point is an operating machine, not an environment-installation project.

Asked which AI accelerators the robots use, Mo names Jetson Nano and AGX as planned K-Bot compute choices at launch. The answer specifies K-Bot, not Z-Bot, and does not identify exact accelerator variants.

VR is a preferred teleoperation method. K-Scale trains what Mo calls a pseudo-IK policy: an RL model moves the robot toward a desired position instead of directly calculating inverse kinematics. The operator moves their arms to guide motion and presses controller buttons to open or close the gripper. Mo says Z-Bot will also support teleoperation through the same software stack.

The final question compares K-Bot with Tesla Optimus. Mo describes Optimus as mechanically more powerful, citing its linear actuators, and associates it with factory work. His view is that this difference need not produce an equally large difference in the use cases available to someone buying a robot to program; he does not present a comparative task test.

For price, Mo repeats an Optimus figure of at least $60,000 as something he last heard, not a verified selling price. He closes by putting K-Bot at $9,000 before mass production. The practical proposition is access to a programmable machine whose hardware, control software and learning tools can develop together—even while dependable autonomous household work remains unfinished.