OpenMind OM1: a Go runtime for wiring LLMs into robot hardware

The gap OM1 fills between a language model and a moving robot

A language model answers text. A robot needs a loop that reads a camera frame, transcribes a microphone, decides something, and drives an actuator. Most teams write that loop by hand, once per robot, and then rewrite it when the hardware changes. OM1's stated goal is to make that loop configurable rather than bespoke: the README describes it as a modular AI runtime for deploying multimodal agents across digital environments and physical robots, naming humanoids, phone apps, quadrupeds, TurtleBot 4, Gazebo and Isaac Sim as targets.

The intended audience is a developer who has hardware or a simulator and wants the agent pipeline handled. The README's quick start uses a conversation agent that reads a webcam and microphone and replies through speech, which is a reasonable proxy for the whole input-LLM-action shape. If you are building a robot product and the alternative is gluing together ASR, a VLM, a transport layer and a metrics stack yourself, OM1 is aimed at you. If you only need a chatbot, it is a large amount of machinery for the job.

How the Go runtime is put together

OM1 is split into two runtimes. The original Python implementation lives on the python branch and the README states it is deprecated and will not be maintained. The Go runtime is the newer implementation, and the README gives the reasoning directly: lower latency, better concurrency, a smaller memory footprint for edge devices, and deployment as a single Go binary with the Zenoh C library bundled alongside it.

The dependency list in go.mod shows what that binary pulls in. eclipse-zenoh/zenoh-go is the transport, gordonklaus/portaudio handles audio capture, yalue/onnxruntime_go runs local models, prometheus/client_golang exports metrics, and modelcontextprotocol/go-sdk indicates MCP support. Hardware and service connections are plugins: the README says new hardware is supported through plugins for API endpoints and connections to ROS2, Zenoh and CycloneDDS, and it recommends Zenoh for all new development. Configuration is JSON5, with config/conversation.json5 as the starter file and a JSON schema validator (santhosh-tekuri/jsonschema) in the dependency tree, so configs are validated rather than silently ignored.

One design consequence worth noting: the runtime is the orchestrator, not the model host. It calls out to OpenAI, xAI, DeepSeek, Anthropic, Meta, Gemini, NearAI or a local Ollama instance, and the README lists text-to-speech and multiple VLMs among the pre-configured endpoints. Your latency and your bill both depend on services OM1 does not control.

Installing OM1 and running the conversation agent

The fastest path is the pre-built binary. System dependencies come first. On macOS the README gives `brew install portaudio ffmpeg`; on Linux it gives `sudo apt-get update && sudo apt-get install -y portaudio19-dev ffmpeg pkg-config`. Pre-built archives exist for linux-amd64, linux-arm64, darwin-arm64 and darwin-amd64, and the README notes the archive already contains config/, knowledge_base/ and the libzenohc files, so no clone is needed for runtime assets.

After extracting, make the binary executable and point it at a config. Note that the README's own example writes the flag with a space around the equals sign, while the launch section below it uses the standard `-config` form; use the latter.

chmod +x om1
./om1 -config ./config/conversation.json5

On macOS, Gatekeeper may block the binary. The README supplies this to clear the quarantine attribute, and it also says to allow om1 and libzenohc.dylib under System Settings, Privacy & Security if prompted.

xattr -d com.apple.quarantine om1 2>/dev/null || true

The binary needs a shared library path pointing at the extracted folder. On Linux that is `export LD_LIBRARY_PATH="$PWD:$LD_LIBRARY_PATH"`; on macOS the equivalent uses DYLD_LIBRARY_PATH. Then set the API key, which you obtain from the OpenMind portal.

export OM_API_KEY="<your_api_key>"

Building from source instead requires Go 1.25.0+ and make. The README gives three commands, and the run step uses a CONFIG variable to select the agent rather than a file path.

git clone https://github.com/OpenMind/OM1.git
cd OM1
make deps
make build
CONFIG=conversation make run

A successful start shows the agent starting, input processing and LLM responses in the terminal, and speech output in response to voice and camera input. Optional monitoring needs Docker: `docker-compose up -d grafana prometheus` brings up the bundled stack, and the README says the OM1 Latency Monitoring dashboard is auto-provisioned at http://localhost:3000 with default login admin/admin. If the metrics port 9090 is already taken, the README's troubleshooting section says to stop the conflicting process.

The Go runtime is not yet at parity with Python

The README is unusually direct about this: the Go runtime covers the core agent pipeline, but several capabilities available in the Python runtime are still under active development. That is the main risk for anyone adopting OM1 now. You are being pointed at the Go implementation for new work, while the reference implementation that has the full feature set is deprecated and will not be maintained. There is no stated timeline for closing the gap, and the README does not enumerate which capabilities are missing, so you cannot tell from the documentation alone whether the plugin you need is ported.

The practical check is the plugins/ directory and the config files under config/. If your target hardware or transport appears there and the config validates, the risk is low. If you are on CycloneDDS, or on a form factor the README does not name, treat parity as unverified.

A second constraint is billing. OMCU is described as the computational unit for billing on OpenMind's platform, with a free plan of 50 OMCU renewed monthly. A VLM that processes camera frames continuously will consume that quickly, and the README points to the portal for upgrades. For a robot running all day, the hosted endpoints are a recurring cost, not a one-off. The local Ollama option is the obvious escape hatch, but the README does not state which pipeline stages can run fully offline.

OM1 against ROS 2 on its own

The honest alternative for many teams is not another agent runtime but ROS 2 plus your own glue. ROS 2 gives you the middleware, the node model and a large ecosystem of drivers; what it does not give you is a decision layer that turns transcribed speech and camera frames into an action. With plain ROS 2 you write that node yourself, choose your own ASR and LLM clients, and build your own metrics.

OM1 sits above that layer rather than replacing it. The README lists ROS2, Zenoh and CycloneDDS as plugin targets, so the intended use is OM1 as the agent and ROS 2 as the transport to hardware. That is a different bet from writing the whole stack in ROS 2: you trade control over the pipeline internals for a config-driven loop and a bundled Prometheus and Grafana setup. If your team already has a mature ROS 2 stack with a working decision node, adopting OM1 means replacing code you understand with a runtime you would have to learn. If you have hardware and no decision layer, OM1 is the shorter path.

The transport recommendation is worth following. The README recommends Zenoh for all new development, which suggests Zenoh is where the Go runtime's attention is going, and CycloneDDS support is the older path.

Maintenance, licensing and what upgrading costs you

The repository is not archived and the last push was on 2026-09-04, so the Go runtime is being worked on. The release history tells a more cautious story: the most recent tagged release is a nightly development build from 2026-06-04, and before that v1.0.2-beta.2 from 2026-04-29 and v1.0.2-beta.1 from 2026-04-14. Everything tagged is either a beta or a nightly, and there is no stable release in the list. Plan for the possibility that a config key or plugin interface moves between versions.

Upgrading from a pre-built binary is cheap in the sense that there is nothing to compile, but the archive is self-contained: config/, knowledge_base/ and the Zenoh library all ship inside it. The Dockerfile shows the container copying config to config_defaults and then running `cp -rn /app/OM1/config_defaults/* /app/OM1/config/` at entrypoint, which fills in missing files without overwriting ones you have edited. That is a sensible upgrade behaviour, and it also means a config key removed upstream can linger in your volume rather than failing loudly.

OM1 is MIT licensed, which permits commercial use and modification. Two caveats that are not legal advice: the bundled Zenoh C library and the ONNX Runtime are separate components with their own terms, and the OpenMind hosted endpoints are a service governed by the portal's terms rather than by the repository licence. Running the whole pipeline against a local Ollama instance changes the cost picture but not the licence of the dependencies you are linking.

Editorial conclusion

Adopt OM1 if you already have robot hardware or a simulator and want a config-driven agent loop instead of writing your own sensor-to-LLM plumbing. Do not adopt it if you need the full capability set today: the README states the Go runtime covers the core pipeline while several Python-era capabilities are still under development, and the Python branch will not be maintained. Before committing, verify two things. First, whether the specific plugin your robot needs exists under plugins/ and is wired into the Go runtime. Second, whether the OMCU free plan of 50 monthly credits covers your LLM and VLM call volume, since the hosted endpoints are billed through the OpenMind portal.

Frequently asked questions

Official sources

1. License: MIT
2. OpenMind/OM1 on GitHub
3. Project website
4. README
5. Releases