OpenClaw Monitor
A free, self-hosted dashboard that watches your OpenClaw agents' token usage, sessions and 7-day trends.
- Source repo
- flik2002/openclaw-monitor
- Stars
- ★ 12
- Last updated
- 4mo ago
- License
- MIT
- Primary language
- JavaScript
- FA score
- 38/100 · Major gaps
At a glance
- How it runs
- Works with
- Platform-specific
- Cost
- Free, no paid service needed
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- Developers already running an OpenClaw Gateway who want to see which model burned the most prompt/completion tokens over the last seven days.
- Not a fit if
- Teams without an OpenClaw Gateway running
- Users monitoring AI runtimes other than OpenClaw
- Anyone wanting a single-command, no-backend deployment
- Source review
- 38/100 · Major gaps 2 safety controls not found
What does this agent do, and when should you use it?
OpenClaw Monitor is an MIT-licensed, self-hosted monitoring dashboard for OpenClaw AI agents. It has three parts: a Vue 3 + Vite + Element Plus + ECharts frontend, a Node.js + Express backend monitor API with a WebSocket client, and helper scripts under openclaw-monitor/. All data comes from local session JSON files and history .reset files, with no cloud component, so the whole pipeline runs offline. At runtime the backend opens a WebSocket connection to an OpenClaw Gateway on port 18789, reads local session data, and exposes REST endpoints that the dashboard on localhost:5173/monitor-v2 consumes. The rendered output covers per-model prompt/completion token bar charts, a live session list, daily message trends for the past seven days, and system uptime and memory metrics.
The backend monitor API connects over WebSocket to the OpenClaw Gateway on port 18789, reads local session JSON files plus history .reset files, and serves the results as REST endpoints: GET /health, GET /api/gateway/status, GET /api/sessions/list, GET /api/metrics/system, GET /api/messages/stats and GET /api/models/current. The frontend polls those endpoints and renders a seven-day prompt/completion token bar chart split by model, a daily message count trend, and a live session list showing model, runtime and status. It also displays a cron task scheduling view alongside system uptime and memory usage. Model support is documented for Claude Code, OpenAI Codex, DeepSeek V4 and more; input is local session data, output is a browser dashboard.
- Developers already running an OpenClaw Gateway who want to see which model burned the most prompt/completion tokens over the last seven days.
- Teams juggling Claude Code, OpenAI Codex and DeepSeek V4 who want one panel comparing usage and message distribution across models.
- On-call or ops staff who need a live view of active sessions: which model each one uses, how long it has run, and whether it is healthy.
- Users who want to confirm that their scheduled agent tasks are laid out as expected via the cron task scheduling view.
- Privacy-sensitive users who want usage metrics to stay on the machine, since the dashboard reads local session JSON rather than a cloud service.
- Anyone debugging resource pressure who needs uptime and memory metrics side by side with session and message trends.
How do you install or deploy this agent?
Prerequisites: Node.js 18+ and an OpenClaw Gateway already listening on port 18789. On Windows, start everything from the repo root with the one-click script:
start-all.batTo run the two services manually, install and start the backend monitor API on port 3000 first:
cd backend && npm install && npm startThen, in a second terminal, install and start the frontend on port 5173:
cd frontend && npm install && npm run devUse stop-all.bat from the root to shut both down. The README does not document one-click scripts for Linux/macOS, nor any environment-variable or config-file reference.
How do you use this agent?
With both services up, open the dashboard in a browser:
http://localhost:5173/monitor-v2The backend API listens on port 3000; call it directly to sanity-check the data:
curl http://localhost:3000/health
curl http://localhost:3000/api/gateway/status
curl http://localhost:3000/api/sessions/list
curl http://localhost:3000/api/metrics/system
curl http://localhost:3000/api/messages/stats
curl http://localhost:3000/api/models/currentIf either port is taken you must change it yourself and keep the WebSocket connection from the backend to the Gateway on 18789 reachable.
What are this agent's strengths and limitations?
- Fully local data path: session JSON files and history .reset files only, so usage metrics never leave the machine.
- The seven-day prompt/completion token bar chart is broken down per model, which directly answers which model is burning budget.
- Documented multi-model display for Claude Code, OpenAI Codex and DeepSeek V4 in a single dashboard.
- Windows one-click start-all.bat/stop-all.bat plus a two-step manual path (npm install, npm start) for each service.
- Clean REST surface (/api/sessions/list, /api/metrics/system, /api/messages/stats and more) that is easy to scrape for your own alerts or reports.
- Hard dependency on an OpenClaw Gateway listening on port 18789; without it the dashboard has no live data source.
- Scope is limited to the OpenClaw ecosystem — no collection adapter for other AI runtimes is documented.
- You must run two processes (backend on 3000, frontend on 5173), and any port conflict has to be resolved by hand.
- The one-click start script is Windows-only; Linux/macOS users have to assemble the manual steps themselves.
- No Docker image, config file format or environment variables are documented, so containerised or centralised deployment needs extra work.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| OpenClaw Monitor This agent | 38 · Major gaps | Self-hosted serviceFree | ★ 12 | 4mo ago | JavaScript | — |
| AgentAcct | 61 · Some gaps | CLIFree | ★ 754 | 1d ago | Python | Codex · Claude Code |
| ClawMetry | 81 · Good | CLIFreemium | ★ 420 | today | Python | Codex · Claude Code |
| Agenttrail | 77 · Good | CLIFree | ★ 708 | 18d ago | JavaScript | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
README states data comes from local session JSON files, fully offline with no cloud, and includes an architecture diagram showing the browser→frontend→local API→Gateway WebSocket/local files flow, so data_flow_transparency scores 2. However, no permission declarations, least-privilege design, or user confirmation mechanism exist: the monitor implicitly reads local session files and connects to the Gateway WebSocket without documented scope limits, so least_privilege is 1; there is no confirmation before any action, so user_confirmation is 0. For sensitive data, session JSON may contain prompts and token details, yet README describes no redaction, access control, or storage protection, scoring 1. On dependency security, release.yml uses npm ci --ignore-scripts, a positive signal, but no lockfile evidence, dependency audit, or version pinning is provided, scoring 1. External effects: the release workflow creates GitHub Releases and tags, a real side effect, but CI-only and non-destructive by default, scoring 1. Rollback: no rollback, backup, or recovery guidance at all, scoring 0. Source attribution: README does not credit the upstream OpenClaw project or data-format origin; only LICENSE names a copyright holder, scoring 1.
Self-consistency: README API endpoints, architecture diagram, and project structure largely align, but release.yml packages a QUICK_START.md never mentioned in README, and the release notes' start steps (frontend via npm run dev) contradict the packaged frontend/dist static artifacts, an internal inconsistency, scoring 1. Dependency availability: only Node.js 18+ and OpenClaw Gateway port 18789 are declared; no concrete dependency versions or lockfile, so reproducible installation cannot be statically confirmed, scoring 1. Failure messages: README describes no error codes, log formats, or troubleshooting paths, scoring 1.
Audience and scenarios: README clearly targets developers monitoring OpenClaw agents, with a feature list and screenshot, scoring 2. Capability boundaries: only features are listed; unsupported models, platforms, or data-scale limits are not stated, scoring 1. Trigger precision: monitoring is passive reading with no trigger conditions documented; start-all.bat is Windows-only and cross-platform triggering is undefined, scoring 1. Environment fit: Windows batch scripts and local ports are explicit, but Linux/macOS support and port-conflict handling are unaddressed, scoring 1.
Information architecture: README has clear sections for features, tech stack, structure, quick start, API, architecture, and license, scoring 2. Install notes: prerequisites plus one-click and manual start paths with ports are provided, scoring 2. Naming stability: repo and product names match, but release tags use timestamps (v20260101-120000) rather than semantic versions, an unstable naming strategy, scoring 1. Examples and FAQ: only a screenshot and endpoint table; no usage examples, config samples, or FAQ, scoring 1. Known limitations: entirely absent, scoring 0. License: full MIT text present and consistent with README, scoring 2. Versioning/changelog: no CHANGELOG, only CI-generated timestamp tags, scoring 1. Maintenance responsibility: LICENSE copyright holder is Biglegs while the repository owner is flik2002, and no maintainer, contact, or contribution guide exists; publisher identity is unverified, scoring 1.
Output usability: the dashboard offers token usage, session lists, 7-day trends, and system metrics, directly usable by the target audience, scoring 2. Marginal value: functionality may overlap with OpenClaw built-ins or generic monitoring tools, and README does not articulate unique value versus alternatives, scoring 1. Cost-benefit: requires running both backend and frontend Node processes plus a Gateway dependency, a moderate deployment cost, while the benefit is read-only visualization; no resource-usage or performance data is given, scoring 1.
Claim traceability: README feature claims have no corresponding code snippets, tests, or evidence beyond a screenshot, so they cannot be traced item by item, scoring 1. Cross-source corroboration: only README, LICENSE, and a CI workflow are present, partially corroborating each other (MIT, Node version) but with no tests or docs for cross-validation, scoring 1. Fact/inference separation: README does not distinguish verified facts from planned features (e.g., demo.gif remains commented out), and makes no explicit statement either way, scoring 1.
- Not found in source: confirmation before actingTurn on (or add) a confirmation step before it acts, and try it in a sandbox or test environment before real data.
- Not found in source: rollback or recovery pathBack up first, or work on a git branch or snapshot, so its changes can be undone.
- Only README, LICENSE, and a CI workflow are provided; backend/frontend source, tests, and lockfiles are absent, so functionality and dependency security cannot be statically verified.
- The monitor reads local session JSON and connects to the Gateway WebSocket, yet permission scope, redaction, and access control are undocumented, so sensitive prompts and token data may be fully exposed.
- The release workflow references a QUICK_START.md absent from README, and the release notes' start steps contradict the packaged artifacts, so install steps may fail.
- The LICENSE copyright holder (Biglegs) differs from the repository owner (flik2002); publisher identity is unverified and maintenance responsibility and update path are unclear.
- No rollback, backup, or known-limitations guidance exists, and release tags use timestamps rather than semantic versions, leaving upgrades and reverts unsupported.