The device
An ESP32-S3 with a 480×480 capacitive panel. Ships pre-flashed. No soldering, no terminal — plug in USB-C and it boots to a setup screen.
How it works
Three parts, all on your side.
A desk display, a small server that runs on your own laptop, and a one-line plugin that ties them together. Here's the whole data path — and exactly what leaves your machine and what never does.
On your laptop
Your CLIs + the broker
Claude Code, Codex and Gemini already log usage locally. The tokenmonitor-mcp broker reads those logs and serves a tiny JSON dashboard.
Wi-Fi LAN
signed requests
On your desk
The device
The 4″ panel polls the broker over your network and draws the numbers. It holds no provider credentials of its own.
Internet
read-only
Ambient only
Time & weather
The device's only direct internet calls: a public time server and Open-Meteo for the weather strip + sunrise/sunset.
What the broker reaches out to
Each provider's own usage API (using the login your CLI already has), a public model-price list, and GitHub to check for firmware updates. No analytics, no telemetry, no phone-home.
What the device reaches out to
Your broker on the LAN, plus pool.ntp.org (clock) and open-meteo.com (weather for your city). It never contacts an AI provider.
The pieces
What you actually install.
The tokenmonitor-mcp broker
A small open-source (Apache-2.0) server you run on your laptop. It reads your CLI logs and answers the device's polls. Pick the Go, Python or JS build — they're interchangeable.
The MCP plugin
Installed into Claude Code, Codex or Gemini from the public marketplace. It registers the broker and adds the /tokenmonitor:configure and theme skills, so you pair and manage the device by just asking your AI.
Transparency
What data goes where.
The full picture. The broker talks to the same provider APIs your CLI already uses, with the login you already have — it doesn't hand your data to anyone new. It is a new local service on your machine, which is exactly why it's open source and auditable.
| Path | What's sent | What's never sent |
|---|---|---|
| Broker → provider usage API | Your existing CLI login token, plus an account / project id where the provider needs it, to read your real quota. | Your prompts, your code, your files. |
| Broker → price list | A plain request for a public model-price table (LiteLLM). Cached locally for a day. | Anything identifying you. |
| Broker → GitHub | A version check for firmware releases. | Any usage or account data. |
| Device → broker (LAN) | A signed poll asking for the current dashboard numbers. | Leaves your network — it doesn't. |
| Device → time / weather | The clock request, and your city's coordinates for the weather strip. | Any AI usage, tokens or account data. |
On your logs: the broker parses the token-count fields out of your CLI
transcripts to total your usage. It isn't built to read or transmit the prompt and code
inside those logs — and it has no endpoint that would send them anywhere. It's open source,
so you don't have to take our word for it.
The three numbers
Real, local, and estimated.
%
Real — from the provider
Usage limits
The percentage bars are your provider's own reported quota, fetched live from its usage API (about every 90 seconds). Not a guess.
tok
Local — from your machine
Token counts
Totalled from the CLI logs on the computer running the broker. They reflect what that machine actually used.
$
Estimated — list prices
Spend
Token counts × a public price list — a useful estimate, not a bill. On a Pro/Max plan it's a notional list-price value, not money charged to you.
Security model
What protects it — precisely.
No hand-waving. Here's what the link actually does, and where the limits are.
Authenticated requests
Every device → broker request is signed with HMAC-SHA256 (a per-device key) over the method, path, timestamp and a one-time nonce. Stale timestamps (> 60 s) and reused nonces are rejected, so a captured request can't be replayed.
Encrypted config
Sensitive control-plane payloads — key rotation, settings pushed to the device — are AES-256-CTR encrypted with your device key. (The signature covers request headers, not bodies; we don't claim the whole link is confidential, because it isn't.)
Not internet-exposed
The broker listens on your LAN so the device can reach it — there's no port to forward and nothing is published to the internet. Pairing won't accept a loopback-only address by mistake.
Keys at rest
On the device, the key lives in NVS (encrypted at rest on production units). On your laptop it's stored in a 0600 file under ~/.config/tokenmonitor/ — readable only by you.
Signed firmware
OTA updates arrive over your LAN through the broker. Each is an Ed25519-signed manifest, verified on the device before the boot slot switches; if a new image doesn't check in healthy, the bootloader rolls back automatically. A version floor blocks downgrades.
Open & auditable
The broker and plugin are Apache-2.0 and public. The part that runs on your machine and touches your logs is the part you can read line by line.
The limit, stated plainly: the broker runs as you, with your permissions, and uses
your CLI's login to read your real usage. That's the price of accurate numbers without a
second API key. Open source is how you keep that honest — not a claim that it's risk-free.
Before you buy
What it needs to work.
- A laptop or always-on machine that runs your AI CLI, with the
tokenmonitor-mcpbroker running on it (it can sleep with the machine — the dashboard simply freezes until it's back). - The device and that machine on the same 2.4 GHz Wi-Fi / reachable LAN (port
8765open between them). - Internet for the live percentages, the weather strip and clock sync. Without it, the LAN dashboard still draws your local token totals.
- A supported runtime for the broker (one of Go / Python / Node — pick whichever you already have).
- One broker reads one machine's usage. Two laptops means two brokers; the device can point at whichever you configure.
Like how it's built?
Early-access units are a small first batch — the waitlist locks the launch price for the first 100. Setup is five steps, mostly waiting for it to boot.