RoboClaw is an embodied AI assistant still early enough to be shaped by its contributors

The assistant half and the robot half, in one repository

RoboClaw is described as an open source embodied intelligence assistant, and the project description is shorter than the code: RoboClaw is an Embodied AI Assistant.

The architecture is drawn in a diagram rather than described in prose, and the directory structure tells you the same thing. There is a roboclaw/ package for the assistant itself, a bridge/ directory for the chat front end bridge, a ui/ directory, a tests/ directory, a scripts/ directory and a docs/ directory, plus a Dockerfile and a docker-compose.yml at the root.

The distinction the project makes is between the assistant and the embodiment. The assistant is the part that talks to a language model, keeps conversation state and routes to tools. The embodiment part is the execution layer that turns an intended action into motion on hardware.

The news list gives the sequence the project has followed, and it reads like a build log. On 2026-03-12 the repository was created. On 2026-03-17 came the embodied framework skeleton, domain contracts, and an assembly-centered onboarding controller. On 2026-03-24 came conversational arm setup, calibration, teleoperation, data collection, training and inference. On 2026-04-11 came a web dashboard for the full embodied workflow.

That ordering matters. The framework came before the chat, and the chat came before the dashboard, which is the opposite of the order in which most chat products get built.

A gateway process is what the chat front ends talk to

The compose file is where the process structure becomes concrete, and it is short enough to read in full.

services:
  roboclaw-gateway:
    container_name: roboclaw-gateway
    command: ["gateway"]
    restart: unless-stopped
    ports:
      - 18790:18790
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 1G
        reservations:
          cpus: '0.25'
          memory: 256M

So the gateway is a long running service on port 18790 with a CPU limit of one and a gigabyte of memory, and it is what the CLI and any other client connect to. A second service, roboclaw-cli, sits behind a compose profile called cli, runs the status command with stdin and a tty attached, and is not started by default.

The pattern is a conventional client and server split. The chat front end does not talk to the robot. It talks to the gateway, and the gateway talks to the hardware. That separation is what lets the same robot be driven from a terminal, from a web dashboard, and from a phone without three implementations of the action layer.

The common configuration block shows that both services share one build and one volume, with ~/.roboclaw mounted at /root/.roboclaw, so the assistant's configuration and state live in one place on the host rather than inside the container.

The Dockerfile reinforces the split. It installs Node.js 20 alongside Python 3.12 because of the WhatsApp bridge, builds that bridge with npm, creates the config directory at /root/.roboclaw, exposes the gateway default port 18790, and sets the entrypoint to the roboclaw command with status as the default command.

The dependency list is the architecture in text

The pyproject.toml is more informative than the README, and it explains what kind of system this is.

The package is named roboclaw-ai at version 0.1.0, requires Python 3.12 or newer, and is classified as Development Status 3, Alpha. Its own description is A lightweight personal AI assistant framework, with keywords ai, agent and chatbot, which is a narrower description than the embodied intelligence framing on the project page.

The runtime dependencies split into four groups. The model and interface layer has litellm, openai, tiktoken, prompt-toolkit, typer and rich, so the assistant can talk to models and present a terminal interface. The messaging layer is the longest: python-telegram-bot, lark-oapi, slack-sdk, dingtalk-stream, qq-botpy, matrix-nio under the matrix extra, and wecom-aibot-sdk-python under the wecom extra. The transport layer has websockets, websocket-client, python-socketio, msgpack, httpx and socksio. The platform layer has croniter for scheduling, readability-lxml and chardet for reading web pages, ddgs for search, json-repair, mcp, oauth-cli-kit, loguru, fastapi with uvicorn, and pyserial.

Two of those deserve comment. The mcp dependency means the assistant speaks the Model Context Protocol, so it can be driven by an MCP client. And lerobot, with the feetech, dynamixel and pi extras, plus pyserial, is the robotics side: lerobot is the framework that drives the arm, and the extras name the motor families, so a Feetech or Dynamixel arm is the expected hardware rather than a generic serial device.

The optional extras are per platform. WeChat Work and Matrix are separate extras, which keeps the base install from pulling in a client for every chat system.

Installing it through an assistant, or from a guide

The installation section offers three routes, and the first one is unusual enough to be worth reading twice.

The AI-assisted setup asks your coding assistant: Help me install RoboClaw from https://github.com/MINT-SJTU/RoboClaw

Help me install RoboClaw from https://github.com/MINT-SJTU/RoboClaw

Then there are two conventional guides, a non-Docker installation and a Docker installation, in the docs/ directory.

The AI-assisted route is a deliberate design choice for a project whose installation involves hardware. A guide that tells you which client to install for which platform, which motor bus to configure and which calibration step to run is exactly the kind of thing a coding assistant can walk through interactively, and the project puts it first for that reason.

The Docker route is the more predictable one for a server, and the compose file is the concrete evidence: a gateway service with a published port and a resource budget, a CLI service behind a profile, and a shared configuration volume.

Both are worth reading before you install anything, because the hardware side is where the friction lives, not the Python side.

The project is looking for direction, not just patches

The community co-creation section is the most unusual part of the README, and it changes how you should read the project's status.

RoboClaw is being built in the open, and the stated aim is that major direction-setting choices, such as embodiment support, simulator priorities and roadmap focus, should be discussed with the community. You can contribute through issues for bug reports, feature requests and implementation suggestions, and through pull requests for code and documentation improvements.

The listed contribution areas are embodied AI architecture, capability abstraction and semantic skill interfaces, ROS2 and execution-layer integration, simulator support and real robot adaptation, and evaluation, validation and developer experience.

The status badge says early stage, and the project has a single release, demo-v0.1, dated 2026-03-30, which the release name describes as a demo video. The mobile client column in the demo table says Coming Soon, so the phone front end shown alongside the CLI in the table is not available yet.

What this means in practice is that a contributor is not patching a mature product, they are choosing its direction. For a research group that wants an embodied assistant with a specific hardware target and a specific chat surface, that is an advantage. For a team that wants to deploy something and rely on it, the demo video is the honest summary of the maturity level.

Where RoboClaw is the wrong tool

There are real limits, and they are worth being concrete about.

The first is that this is a robot project that will not run without a robot. The assistant half is a personal AI assistant with a chat interface, and the interesting half, the one the project is actually about, needs an arm, a motor bus and a calibration routine. If you wanted the chat assistant without the embodiment, the dependency list tells you that is a large fraction of the work, and the project's own package description calls it a lightweight personal AI assistant framework, which is a different product from an embodied assistant.

The second is the alpha status and the demo release. There is no tagged version beyond a demo, the development status is Alpha, and the mobile front end is listed as coming soon. Adopting this means adopting something that is still being designed, which is fine for research and uncomfortable for a deployment.

The third is a licence question that the two metadata sources answer differently. The licence field in the project metadata is Apache 2.0, and the README does not discuss licensing, while the pyproject.toml declares license = {text = "MIT"} and carries the MIT classifier. Those are different terms, and a project that is going to be embedded in a company research programme needs one of them to be corrected rather than both to be assumed.

The alternative approach is to treat the model layer and the robot layer separately. Litellm already gives you a provider-neutral model interface, and a robotics stack like lerobot already gives you the hardware loop, and writing the bridge between them yourself is a day of work that leaves you owning every dependency and every version. RoboClaw is that bridge, plus the chat surfaces, and the trade is that you accept a moving target in exchange for not writing the glue.

Editorial conclusion

RoboClaw fits a robotics or embodied AI researcher who wants a language model driving a real arm and needs a websocket bridge between a chat front end and the hardware layer, since the gateway and bridge arrangement is the interesting part of the design. It does not fit a team looking for a production chat product, because the project is marked early stage with a single demo release and a mobile client that the documentation lists as coming soon. Before adopting it, read the two installation guides, decide whether the Docker path or the non-Docker path suits your hardware setup, and confirm the licence position with the project, because the licence field in the project metadata says Apache 2.0 while the package metadata declares MIT.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. MINT-SJTU/RoboClaw on GitHub
4. README
5. Releases