A little help, right when you need it.

Quick start

Install the connector, then open Connect your computer. The page automatically checks the local loopback endpoint and opens your dashboard after a verified response.

Nothing has to be installed first — no Node, no npm, no package manager. The script picks the build that matches your uname, checks its SHA-256 against /connector-version.json and stops if it does not match, then unpacks the connector and its usage engine into ~/.usage-radar-connector. It registers autostart — a LaunchAgent on macOS, a systemd user service on Linux — and waits until the connector answers before it claims success. It never asks for a password, never uses sudo, and the connector it starts binds loopback only: 127.0.0.1:41414, not your network.

On Windows, download the zip and run Install Usage Radar instead.

Local connector checks

The connector runs on port 41414 and re-scans usage every 60 seconds. Check its process state with curl -s http://127.0.0.1:41414/health. Restart it with ~/.usage-radar-connector/usage-radar-connector. Test the endpoint with:

A healthy response includes the installed connector and usage-engine versions.

Security & Loopback Restrictions

• Binds 127.0.0.1 only: The loopback connector is entirely unreachable from your external local network.
• Host validation: Requests must carry the exact host matching 127.0.0.1:41414 to block DNS rebinding.
• Origin allowlist: Browser calls are rejected unless they originate from the official Usage Radar domain.
• Aggregate-only browser response: The local API does not expose prompts, responses, or source code to the website.

Where your data lives

The connector reads supported agent logs locally and serves aggregate-only data over loopback. It keeps no copy of your usage — the logs your CLI already wrote are the durable copy. The only files it writes are a session key, after pairing, its workspace token, and a cached copy of the public model price list it fetches. The dashboard caches its latest normalized records in this browser's local storage.

Reasoning effort levels are read from those same local logs — Claude Code records one per message from 2.1.237, Codex one per turn — aggregated per day, agent and model, served over loopback only, and never leave the machine; they are not part of the hub sync payload.

What is and is not observable.Codex CLI and Codex-in-VS-Code threads that run locally are read from their rollout logs. Codex threads that run in ChatGPT's cloud — the ChatGPT desktop app's hosted Codex — execute on OpenAI's servers, and no token log is written to your machine. The connector detects those threads and counts them, but their tokens and cost are not observable locally, and the dashboard says so rather than silently leaving them out. Even the per-day count stays on your machine: the connector serves it over loopback only, and it is never part of the hub sync payload.

Hub pairing is off by default. If you pair a machine, the connector posts day, agent, model and token totals to the hub roughly every five minutes; a strict schema rejects any field it does not name. Those counters are stored server-side in plaintext — the sync is not end-to-end encrypted. Prompts, responses and file paths are never part of the payload.

Contact & Inquiries

For inquiries, partnerships, or support, reach out to us at abhijaypl@gmail.com