OpenClaw Mission Control: the dashboards, compared

September 2, 2026 · 7 min read · By ClawMetry Team

Search for "openclaw mission control" and you land on half a dozen GitHub repos with the same name and different ideas about what a control room for AI agents should be. This post sorts them out: what each one does, how it talks to OpenClaw, and what a mission control does not give you no matter which one you pick.

What "mission control" means for OpenClaw

OpenClaw runs a gateway process on your machine (by default at 127.0.0.1:18789) that owns sessions, cron jobs, channels and the agent runtime. Everything that calls itself a mission control is a web UI that talks to that gateway so you can run the fleet without the CLI: see which agents are up, hand them tasks, schedule work, read logs, and in some cases chat with them from the browser.

OpenClaw ships its own Control UI too. The community dashboards exist because people wanted a task board, an org chart, cost reporting, or a friendlier setup on top of it.

The dashboards, one paragraph each

robsannaa/openclaw-mission-control

The most complete of the set and the one most people mean. Its own description: "a harness for running a fleet of AI agents from one screen." Live fleet view (agents, gateway health, cron, CPU, memory, disk), a browser chat with file attachments and model selection, a Kanban board (Backlog, In Progress, Review, Done) that agents pick jobs from, cron management with run history, an org chart of agents and sub-agents, per-model and per-agent token cost, memory search, model and credential configuration, channel connections (Telegram, Discord, WhatsApp, Signal, Slack), health checks with one-click fixes, and a built-in terminal. It runs on port 3333, connects to the gateway over HTTP with an optional bearer token, keeps no database of its own ("glass over the engine"), and sends nothing out. MIT licensed. Install: clone into ~/.openclaw and run ./setup.sh.

abhi1693/openclaw-mission-control

An earlier orchestration dashboard for assigning tasks and coordinating multi-agent work through the gateway. Its README now points to a successor product, Wardn AI, and recommends new users start there.

navjotdhanawat/openclaw-mission-control

A command-center UI focused on the task loop: create tasks, dispatch them to agents, watch progress through a Kanban workflow, and see agent activity in real time.

manish-raana/openclaw-mission-control

A lighter real-time UI built with Convex and React. Task state, agent activity and live logs update instantly without polling or a message queue. Good if you want the live view and not the whole control room.

carlosazaustre/tenacitOS

A real-time dashboard and control center for OpenClaw instances built on Next.js, React 19 and Tailwind v4. Pick this if you want a modern front-end codebase you intend to extend.

jamesxu81/openclaw-dashboard

Kanban tasks, cron jobs, team status, an "office view" of who is doing what, and a daily digest in one place.

ChristianAlmurr/openclaw-dashboard

Fleet monitoring with a wider lens: costs, performance, context health, security posture and market intelligence panels.

How to choose

You want to manage agents without the CLI: robsannaa. It covers the most ground and is the most active.
You want a task board above all: navjotdhanawat or jamesxu81.
You want the smallest live view: manish-raana.
You want a codebase to build on: tenacitOS.

All of them share one property: they read and write through the gateway. That is the point of a mission control, and it is also its blind spot.

A control room shows you what the gateway reports. It does not tell you what an agent actually did across every session file on disk, what a single runaway session cost by the minute, whether an agent has been repeating the same failing tool call for twenty minutes, or which session read a credentials file it had never touched before. Those questions need an observer that reads the evidence directly and does not depend on the process it is watching.

That is the layer ClawMetry adds next to any of the dashboards above. It reads OpenClaw's session transcripts and channel transcripts from the files OpenClaw already writes, subscribes to the gateway's WebSocket for live events, and stores everything in a local DuckDB file on your machine. From that it shows:

every session, tool call and sub-agent as it happens, with token counts and cost per session and per model;
trajectory detectors for a stuck loop, no progress, or a tool failing repeatedly, with the dollars at risk for the flagged stretch;
behavioural detectors for credential access, unusual network egress, privilege changes and a file blast radius wider than the agent's own baseline;
cron run history and health, read from the gateway.

Observation is read-only. Intervention is opt-in and off by default, and one limit is worth saying plainly: OpenClaw has no pause primitive, so a "pause" from ClawMetry is advisory unless ClawMetry's enforcement proxy is in front of the model calls. Stop and kill act on the process and do work.

Run both

The two do not compete for the gateway. Install your mission control of choice, then in a terminal on the same machine:

pip install clawmetry && clawmetry

Open http://localhost:8900. There is nothing to configure: ClawMetry finds the OpenClaw workspace, the gateway and the session files on its own. The free tier covers OpenClaw on one node; plan details are on the pricing page. ClawMetry Cloud is optional and end-to-end encrypted if you want the same view from your phone.

Sources

See what your OpenClaw agents actually did

Open source. Reads the files OpenClaw already writes. One command.

Get ClawMetry