DimOS — The Agentive Operating System for Physical Space (v0.0.13)

TL;DR

DimOS is an open-source Python SDK / runtime for building agent-driven robotics applications on quadrupeds (Unitree Go2, B1), humanoids (Unitree G1), manipulator arms (xArm, AgileX Piper), and drones (MAVLink, DJI Mavic) — pitched as a modern, ROS-free stack whose primary user is a coding agent rather than a human engineer. The system is organized around three primitives: Modules (typed pub/sub subsystems with In[]/Out[] streams), Blueprints (declarative wiring produced by autoconnect(...)), and an MCP surface that exposes every @skill-decorated method as an HTTP tool callable by Claude Code, OpenClaw, Cursor, or any external agent. v0.0.13 sits on the v0.0.11/v0.0.12 release line that made DimOS “fully Agent-native” — the CLI (dimos run/status/log/agent-send/mcp/stop), a temporal-spatial memory subsystem, an interactive visualizer, and drone + fleet support are the load-bearing pieces.

Key claims

DimOS is positioned as a ROS-free Python-first SDK for generalist robotics, targeting humanoids / quadrupeds / drones / arms with a single install (uv pip install 'dimos[base,unitree]') and running against real hardware, MuJoCo simulation, or recorded replay via one CLI flag [README §Intro, §Quickstart].
The runtime is agent-native: agents are refactored as first-class Modules with direct stream access rather than bolted on top; every @skill method is auto-exposed as an MCP HTTP tool that external coding agents can call via dimos mcp call <skill> --arg ... [README §Agent CLI and MCP; release notes §“fully Agent-native”].
Programming model is typed pub/sub with declarative wiring: Module classes declare In[T] / Out[T] streams, and autoconnect(...) matches them by (name, type) and returns a composable Blueprint whose transports (LCM, SHM, DDS, ROS 2) can be swapped per stream without rewriting modules [README §Use DimOS as a Library, §Blueprints].
Hardware maturity is staged and honest about beta status: Unitree Go2 quadruped is marked stable (🟩), Unitree G1 humanoid and xArm/AgileX Piper arms are beta (🟨), drones (MAVLink, DJI Mavic) are alpha (🟧), and Unitree B1 + Force-Torque sensor are experimental (🟥) [README §Hardware].
Advertised capability stack covers navigation and mapping (SLAM, dynamic obstacle avoidance, route planning, autonomous exploration — both DimOS-native and ROS-backed), perception (detectors, 3D projections, VLMs, audio), agentive control with MCP, and a spatial-memory subsystem (spatio-temporal RAG, dynamic memory, object localization and permanence) [README capability table].
Featured blueprints ship as one-command runfiles: dimos --replay run unitree-go2 (SLAM/costmap/A* replay), dimos --replay --replay-db go2_bigoffice run unitree-go2-memory (temporal memory replay), dimos --simulation run unitree-go2-agentic (agentic + MCP server in MuJoCo), dimos --simulation run unitree-go2-agentic-ollama (same but with a local Ollama LLM), and dimos --replay run drone-agentic [README §Featured Runfiles].
The onboarding contract for coding agents is an AGENTS.md file — architecture, CLI reference, skill rules, blueprint quick-reference — that a Claude Code / OpenClaw / Cursor agent reads to bootstrap itself into building, running, and debugging DimOS apps [README §Installation callout; release notes §“DimOS is now built to be driven by coding agents”].
Multi-language interop is provided via LCM bindings (C++, Lua, TypeScript examples) even though Python is the primary glue [README §Multi Language Support].

Method

DimOS’s architecture is a three-layer stack. At the bottom, transports (LCM by default, plus SHM, DDS, ROS 2) carry typed messages between processes and languages, with dimos-lcm shipped as a separate PyPI package for the schema registry. In the middle, Modules are Python classes that declare typed streams via In[Twist] / Out[Image] fields; the @rpc decorator marks methods that participate in the module lifecycle, and skill methods are picked up by the MCP server. At the top, Blueprints are functions that instantiate one or more modules and return an autoconnect(...) object that resolves (stream_name, message_type) pairs into concrete transport wiring. Blueprints compose (blueprint.transports({...}) swaps the transport for a given stream), which is what lets a single application definition run against real hardware, MuJoCo simulation, or recorded replay data.

The v0.0.11 → v0.0.13 release train reorganized the CLI around a daemon model: dimos run <blueprint> --daemon starts the blueprint in the background, dimos status and dimos log -f inspect it, dimos agent-send "explore the room" pushes a command to the agent inside, and dimos mcp list-tools / dimos mcp call <skill> --arg ... interact with skills as MCP tools over JSON-RPC. Dask (formerly used for stream orchestration) has been removed entirely. Agent modules now subscribe directly to embedded streams — perception (LiDAR, camera), spatial memory, control loops, motor drivers — rather than going through a wrapper. The temporal-spatial memory subsystem exposes an object-permanence-aware RAG that agents query to answer “go find the kitchen”-style commands.

Results

DimOS is a working system release rather than a benchmarked model, so “results” are release milestones and adoption signals. v0.0.10 removed the entire ROS message dependency from core DimOS, added a complete manipulation stack, MuJoCo simulation, DDS transport, and a rewritten visualization pipeline, plus VR / phone / arm teleoperation stacks — the release described as “you can now vibecode a pick-and-place task from natural language to motor commands.” v0.0.11 (the “fully Agent-native” release, mid-2026) shipped the production CLI + daemon, MCP tooling, temporal-spatial memory, interactive visualizer, drone integration, and fleet control, and marked the point where OpenClaw / Claude Code / Cursor agents can drive a full build/run/debug cycle via AGENTS.md + MCP. v0.0.13 continues the same release train with incremental fixes (logging, pytest autoconf, Nix venv docs, G1 rerun visualization, and a G1SimConnection camera fix visible in the changelog). The repo carries 3,520 GitHub stars, 701 forks, 123 contributors, and 339 open issues at the time of filing (source: GitHub org page, external), making it one of the more active generalist-robotics SDKs on the wiki.

Why it’s interesting

DimOS is the first filed artifact that sits between a VLA / world-action model and the physical robot at the deployment plane. The VLA Models concept has accumulated eight+ recipes (π*0.6, Embodied-R1.5, Spirit-v1.5, LingBot-VA, µ₀, HumanEgo, ABC, HyVLA-0.5) each of which produces a policy that eventually has to be wired to a camera stream, a LiDAR feed, an MCP-callable skill library, and a spatial-memory backend on real hardware — DimOS is a candidate runtime for that wiring, in the same infrastructure lane as Rerun — The Data Layer for Physical AI (which owns the data / logging side of the same lane). It’s also the strongest filed instance of the Tool-Use Agents pattern for embodied agents: rather than the terminal/browser/enterprise-workflow surfaces that dominate the tool-use-agents page (SETA, Toolathlon-GYM, OpenReward), DimOS exposes robot skills (relative_move, explore, custom @skill methods) as MCP tools that external LLMs invoke — the same design pattern ASCILINE — Real-Time ASCII Video Rendering Engine uses for visualization skills and that VoLo: A Physical Orchestrator for Open-Vocabulary Long-Horizon Manipulation argues for at the architectural level with “physical orchestration” over interruptible tools. Complements the recent toolkit threads: adjacent to RAIDEN: A Toolkit for Policy Learning with YAM Bimanual Robot Arms on the data-collection side of the same lifecycle (RAIDEN handles teleop → dataset, DimOS handles blueprint → deployment). The explicit “coding agents write DimOS applications via AGENTS.md” bet is a concrete deployment-side answer to the AI-for-AI Research pattern applied to robotics engineering.