onWatch: A Local Quota Daemon for Eleven AI Coding Providers

The gap onWatch targets: snapshots versus per-cycle history

Provider dashboards answer one question well: what is my usage right now. They answer badly the question that matters when you are deciding whether to start a long refactor or a batch job: how much quota did I burn in the last cycle, and at what hour. onWatch positions itself in exactly that gap. The README states it "fills the gap between 'current usage snapshot' and the historical, per-cycle, cross-session view that developers actually need." The audience is narrow and identifiable. You are a developer who pays for more than one AI coding subscription, you work across several editor tools (Cline, Roo Code, Kilo Code, Claude Code, Codex CLI, Cursor, GitHub Copilot, MiniMax Coding Plan, Grok CLI, Antigravity are all named), and you want one local place where the numbers accumulate instead of resetting every time you open a different vendor tab. The project is explicitly in beta, so treat the feature set as moving.

Polling daemon, SQLite file, localhost dashboard

The architecture described in the README is three pieces. First, a background agent that polls provider APIs using the keys you supply. It is a single Go binary, and the README gives a memory figure: under 50 MB RAM with all providers polling in parallel. Second, storage in SQLite, which is what makes the per-cycle history possible; the daemon writes samples and the dashboard reads them. Third, an HTTP server that renders a Material Design 3 dashboard with dark and light modes. Every configured provider is polled in parallel, so adding a key does not serialize the others. The README also states zero telemetry and that all data stays on your machine, which follows from the local SQLite file plus the absence of any hosted backend in the install instructions. There is a second ingestion path called API Integrations, for pushing local telemetry from your own API-driven workflows so token use and spending from your own scripts land in the same store. That is the part of the design most worth noting: onWatch is not only a scraper of vendor endpoints, it can also be a sink for data you generate yourself.

Installing onWatch: four paths and the keys each expects

The README documents four installation routes. The one-line install for macOS and Linux is `curl -fsSL https://raw.githubusercontent.com/onllm-dev/onwatch/main/install.sh | bash`. It downloads the binary to `~/.onwatch/`, creates a `.env` config, sets up a systemd service on Linux or a launchd agent on macOS, and adds `onwatch` to your PATH. Homebrew users get `brew install onllm-dev/tap/onwatch` followed by `onwatch setup` for an interactive wizard. Windows has a PowerShell one-liner, `irm https://raw.githubusercontent.com/onllm-dev/onwatch/main/install.ps1 | iex`, which lands the binary in `%USERPROFILE%\.onwatch\` and runs the same kind of interactive setup. Docker is the fourth route: copy `.env.docker.example` to `.env`, then `docker-compose up -d`, or use `./app.sh --docker --run`. The Docker image uses a distroless base of roughly 10 to 12 MB, runs as non-root, persists data through a volume mounted at `/data`, and logs to stdout, so `docker logs -f onwatch` is the way to watch it. An Alpine variant with shell access exists at `ghcr.io/onllm-dev/onwatch:alpine`. Building from source needs Go 1.25 or newer and follows `git clone`, `cp .env.example .env`, then `./app.sh --build && ./onwatch --debug` (or `make build && ./onwatch --debug`).

Config keys and the token auto-detection caveat

Configuration lives in `~/.onwatch/.env`, or `.env` in the project directory when built from source. The README lists `SYNTHETIC_API_KEY`, `ZAI_API_KEY`, `ANTHROPIC_TOKEN`, `CODEX_TOKEN`, `COPILOT_TOKEN`, plus `ONWATCH_ADMIN_USER` and `ONWATCH_ADMIN_PASS` for the dashboard. At least one provider key is required, and any combination can be tracked together. Two details deserve attention before you commit. Anthropic tokens are auto-detected from Claude Code credentials, which the README locates in the macOS Keychain, the Linux keyring, or `~/.claude/.credentials.json`; that is convenient but it means the daemon reads a credential file you may not think of as shared state. Codex-only setups can set `CODEX_TOKEN` in `.env`, and the README notes onWatch re-reads it at runtime, though the sentence is cut off in the material available to me, so the exact refresh behaviour is not confirmed here. `COPILOT_TOKEN` is a GitHub PAT that needs the copilot scope, and the README marks Copilot support as beta. For Gemini CLI, Cursor, Grok and Kimi Code the README points to separate files (docs/GEMINI_SETUP.md, docs/CURSOR_SETUP.md, docs/GROK_SETUP.md, docs/KIMI_SETUP.md) rather than inline instructions, and Gemini CLI is labelled legacy.

Where onWatch is the wrong tool

The clearest limitation is stated by the project itself: it is in active development, and features and APIs may change. That is not boilerplate here. A monitoring daemon that writes to SQLite and exposes a dashboard is only useful if the schema and the HTTP surface stay stable enough that your history survives upgrades, and a beta label is a direct warning that they might not. The second boundary is provider coverage. Eleven providers are listed, and anything outside that list is simply not tracked; if your spend sits with a vendor that is not named, onWatch has nothing to poll. Third, this is a single-user local tool. The admin user and password gate a dashboard that the README describes as local, and nothing in the material suggests multi-tenant accounts, shared dashboards, or team roles. A team that wants one shared view of collective spend is looking at the wrong shape of product. Fourth, the Copilot path is beta and depends on a PAT scope you have to get right, which is a common source of silent failure: the daemon runs, the provider shows no data, and the cause is a token missing a scope rather than a bug.

Compared with a hosted LLM observability platform

The obvious alternative category is a hosted observability or gateway product, the kind you point your application at so every request is logged server-side. The difference in approach is structural, not cosmetic. A gateway sees traffic that flows through it, which means it captures per-request token counts and latency for the applications you route through it, and it stores that on someone else's infrastructure with a team-facing UI. onWatch does the opposite: it polls provider quota endpoints from a daemon on your machine, stores the result in a local SQLite file, and never sends anything out. Two consequences follow. onWatch cannot see requests that never touch a provider quota API, so per-request cost attribution inside your own application is out of scope unless you feed it through API Integrations yourself. And a gateway cannot tell you what your Claude Code or Copilot subscription has left in the current billing cycle, because that number lives with the provider, not in your request stream. If your problem is "how close am I to throttling across subscriptions I already pay for," the polling daemon is the right shape. If your problem is "which customer or feature is burning tokens," you need the gateway, and onWatch is a complement at best.

Licence, maintenance and what an upgrade actually costs

onWatch is GPL-3.0. For individual use that changes nothing. If you intend to embed the daemon in a product you distribute, or to link it into a proprietary service, the copyleft terms are the thing to read before you build on it; that is a question for your own counsel, not for this review. On maintenance, the repository shows a steady release rhythm around v2.14.x, including beta previews such as v2.14.0-beta.4, which suggests the author ships frequently and tags pre-releases separately. The practical upgrade cost is not the binary, it is the SQLite file. A version that changes how samples are written can leave you with history that the new dashboard reads differently or not at all, and the README does not document a migration or export path. Before upgrading across a minor version, copy the database file. If you run Docker, that file is under the `/data` volume; if you used the install script, it sits under `~/.onwatch/`. The VS Code Marketplace extension published under `onllm-dev.onwatch` is a separate distribution channel with its own update cadence, so an editor-side update and a daemon update can drift apart.

Editorial conclusion

Adopt onWatch if you personally hold two or more of the supported coding subscriptions and want per-cycle history rather than a single usage snapshot. Skip it if you need a shared team view, a hosted service, or coverage for a provider outside the eleven listed. Before installing, read docs/WINDOWS_SETUP.md on Windows, confirm the COPILOT_TOKEN PAT carries the copilot scope, and check that your Go version is 1.25 or newer if you plan to build from source rather than use a release binary.

Official sources

1. License: GPL-3.0
2. onllm-dev/onWatch on GitHub
3. Project website
4. README
5. Releases