A passing Go suite gives you a starting point for a robot
Autonomous OS passed all 112 Go tests in our sandbox, but deciding whether to put it on your desk requires a different question: which physical actions will your robot actually support? The project connects an AI agent to cameras, microphones and motors. Its README gives a useful example: a request to turn off the Lamp's lights can take a local command path, while an ambiguous request about making an image brighter goes to the main agent.
The old autonomous-ai/autonomous-os address now redirects to autonomous-ai/lampOS. The current English README calls the stack Physical AI Operating System and describes Lamp, Intern and Reachy Mini. Keep that naming change separate from our September 27 checkout at commit 7f1239e. GitHub now labels the primary language Python, while our measured build path was Go. Neither label describes the whole system: a Go daemon coordinates a Python hardware layer and agent runtimes.
What happened when we ran it
Our sandbox installed commit 7f1239e in 13 seconds, adding 66 packages, and completed the build in 43 seconds. We used golang:1.24-bookworm in an unprivileged Debian container with 3 CPUs, 8 GB of RAM and no secrets on September 27, 2026. Those are encouraging results for a developer checking whether the repository can be worked on without first provisioning a robot or handing over credentials.
The test step completed in 45 seconds: go test reported 112 passed and 0 failed out of 112. The checkout contained 3,007 files, roughly 452,988 source lines and occupied 61 MB. Our scan found 2 CI workflow files, no Dockerfile and no tests directory. A missing directory named tests does not contradict the passing Go command. These results establish a successful software path at that commit; they provide no measurement of voice quality, motor behavior or physical safety.
A new body needs Linux support and a hardware driver
The 61 MB checkout contains far more than a chat interface. The bring-your-own-robot guide requires arm64 Linux with systemd and a recognized board entry. Its worked example is Reachy Mini, where the existing robot daemon retains control of the motors. A robot declaration lists capabilities, and the hardware layer mounts the routes those capabilities allow. This gives a port author a concrete interface to implement instead of starting a separate agent stack for every body.
The README's markdown-first pitch understates the work for unfamiliar hardware. ROBOT.md describes the body and SOUL.md sets its personality, but a new motor subsystem still needs a driver. The guide says today's motion contract fits articulated heads; wheels and legs need a separate locomotion service. Choose this for a supported desk robot or a port you intend to maintain. If your next task is mobile navigation, the documented contract is a reason to choose another foundation.
The 13-second install does not configure speech or computer control
Our 13-second installation needed no secrets. A useful talking robot does: the README says inference can use remote services, and the hosted-services guide documents the AI gateway plus custom language-model, speech and perception endpoints. That guide also contradicts itself. An early paragraph says a custom OpenClaw endpoint is unavailable, while a later section explains llm_base_url configuration. Resolve that against your chosen revision before promising an offline deployment.
Computer work adds another connection. Harness delegates tasks to agents on a paired computer, while Buddy lets the device agent inspect and operate Mac applications. The README explicitly gives them separate pairing paths. Start with the robot's own lights and voice before adding those permissions. A green build says nothing about whether a paired Mac is reachable, whether the selected model accepts the request, or whether the agent interprets an application screen correctly.
Declared safety limits can be absent
The 112 passing Go tests should not persuade you to use this as a safety appliance. The safety documentation says missing light, audio and motion bounds pass through with logging. Malformed bounds fail loudly, but an omitted limit does not become a conservative default. Read the actual SAFETY.md for your body and check which limits the documented hardware path enforces. A reassuring filename is insufficient evidence that every movement has a bound.
An open HAL fire-hazard report makes that distinction concrete. It describes the perception model labeling a burning sofa as a bonfire, a label treated as safe, so HAL raises no alert. The report concerns this project's current hardware layer, not an unrelated component. It is upstream evidence, separate from our sandbox findings. I would reject this stack for fire monitoring or any deployment where a missed detection could leave somebody relying on a silent robot.
Mixed licensing and October activity deserve separate decisions
Our 3,007-file checkout warrants reading the folder-level licenses before product adoption. The README says code outside hal/ is Apache-2.0, while hal/ is GPL-3.0 and closed vendor SDKs should run out of process. It also flags AGPL-licensed tracking components. GitHub's Apache license label cannot settle that entire distribution decision. A hardware vendor needing a wholly permissive stack has a specific reason to walk away.
The last push was October 14, 2026, and GitHub listed 444 stars with 46 open issues and PRs. Recent issue updates and a closed movement-related PR show ongoing work. The latest release, models/ambernet, contains language-identification assets rather than a complete OS package. For Reachy-only applications, use Pollen's Reachy Mini SDK and its simulator. For a broader robotics foundation, consider ROS 2. Choose this project when sharing agent behavior across supported desk bodies is worth maintaining the hardware port, then require an observed movement before calling that port ready.