# The usage monitor reads provider credentials and never writes them back

> A MIT Rust taskbar widget for Windows that shows how much of your Claude Code, Codex, Cursor, Copilot and other allowances is left, and when each window resets. What makes it more than a status icon is how it treats credentials: every provider has a documented detection path, and nothing it reads is written back.

**CodeZeno/Claude-Code-Usage-Monitor** — Windows taskbar widget for Claude Code, Codex, Cursor and more. Track usage limits and reset times. Free and open source.

- Repository: https://github.com/CodeZeno/Claude-Code-Usage-Monitor
- Stars: 558 · Forks: 135
- Language: Rust
- License: MIT
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/codezeno-claude-code-usage-monitor

## Two rows, and not every provider fills both

The widget is not a single number per provider, which is the first thing to understand. It has a short-window row and a long-window row, and providers that bill differently populate one or both. Claude Code and Codex use both, and for those the long-window row also carries on-demand spending once any has been used. Grok Build reports one pool per billing period rather than a five-hour window, so it appears on the long-window row only and the short-window row stays empty. GitHub Copilot spends one premium-request pool per calendar month, so it is treated the same way. That is not a gap in the implementation, it is the billing model being reflected honestly, but it does mean a provider with an empty short row should not be read as broken. Copilot's metered chat and completion allowances, as on the free tier, are still available to themes through the `copilot.limits.chat` and `copilot.limits.completions` bindings.

## Usage direction is a per-theme display binding

Counting up or counting down is a display decision rather than a global preference, and the mechanism is more interesting than a checkbox. Under Settings, Display, Usage direction, the default theme and any other theme that supports it switch between showing what has been used and what is left, with Used as the default. Choosing Remaining makes a fresh limit read one hundred percent and drain as you work. For theme authors the opt-in is explicit: bindings such as `{claude.session.display:usage_line}` and `{claude.session.display:usage_badge}` select the form, while the existing `.percentage` and `.remaining` keys and unsuffixed usage summaries keep whatever meaning they already had. Warning thresholds are advised to keep using `.percentage`, which is the detail that stops a theme author from accidentally gating an alert on the wrong side of the switch. Themes ship built in and there is a visual Theme Studio for building custom layouts.

## OpenCode Go asks for a browser session cookie

Most providers are detected automatically once you have signed in. OpenCode Go is the exception and it is the one setup worth reading twice. You can set `OPENCODE_GO_WORKSPACE_ID` and `OPENCODE_GO_AUTH_COOKIE` as environment variables, or create a config file at `%APPDATA%\opencode-go\config.json`:

```json
{
  "workspaceId": "wrk_01...",
  "authCookie": "__Host-console_session=your-session-cookie-value"
}
```

The workspace ID is the identifier in the console URL, which takes the form `https://opencode.ai/console/<workspaceId>/go`. The cookie comes from an authenticated browser session on that site and has to include its name, so `__Host-console_session` with the equals sign is part of the value. A full Cookie header is also accepted unchanged, and bare legacy `auth` values still work, so both forms work whether you use the file or the environment variable. `OPENCODE_GO_CONFIG_FILE` points at a different path. Usage is then read from the console JSON API with those two values. Because that cookie is a live session credential stored in plaintext, the documentation says to protect the file the way you would protect a browser session.

## Grok Build needs a signed-in session, not an API key

Grok Build has the most specific rules of the seven providers. Usage comes from the session the CLI stores at `%USERPROFILE%\.grok\auth.json`, read through the same billing endpoint the CLI's own usage panel uses, so the numbers agree with what the tool already shows you. If the CLI keeps its home elsewhere, `GROK_HOME` points at it. The filter is narrow: only xAI sign-in entries are used, and corporate identity-provider tokens and stored API keys are excluded. That exclusion has a consequence worth stating plainly, because a bare `XAI_API_KEY` is not sufficient. The shared weekly allowance is only readable with a signed-in session, so an API-key-only configuration shows nothing. Run `grok login` in the Grok Build CLI first, then enable the provider in the dashboard, and the signed-in session is picked up automatically.

## Copilot reads the same endpoint its own editors read

The GitHub Copilot integration takes the same approach, using `api.github.com/copilot_internal/user`, described as the endpoint Copilot's own editors and CLI read, so there is no separate source of truth to disagree with. Authentication follows a documented search order and stops at the first login the endpoint accepts: the `COPILOT_GITHUB_TOKEN`, `GH_TOKEN` or `GITHUB_TOKEN` environment variable, then the Copilot CLI login, then the GitHub CLI login, with the last two read from Windows Credential Manager rather than from a file. Signing in through the Copilot CLI, running `copilot` and then `/login`, or through the GitHub CLI with `gh auth login`, both work and both are detected automatically once Copilot is enabled. Cursor follows the same shape, with `CURSOR_SESSION_TOKEN` available to override the automatically detected local session when you have more than one.

## Credentials are read, never rewritten

The privacy section is short and specific in a way that matters more than a general assurance. The monitor reads local sign-in credentials for whichever providers you have enabled and sends usage requests straight to those services. There is no backend service of its own, no telemetry and no analytics, and it does not upload credentials or project files. The part with teeth is the next sentence: credentials are read without modifying the provider files that contain them. That is demonstrated rather than asserted in one case. When Grok Build rejects a stored token, the monitor asks the Grok CLI to refresh its own session rather than rewriting `auth.json` itself, so the tool that owns the file is the one that writes it. Claude Code credentials are detected from the CLI, the desktop app or WSL. OpenCode Go is the exception to the reassurance rather than to the rule, since those credentials are plain text you paste in yourself.

## egui-directx11 is vendored and pinned to an exact version

The manifest says more about the engineering than the feature list does. The package is `claude-code-usage-monitor` at version 2.17.0, on Rust edition 2021 with a rust version requirement of 1.95 pinned rather than a floor, and the Windows resource metadata names a company, an internal name and an original filename of `claude-code-usage-monitor.exe`. The dependency list is small and the choices are annotated. `ureq` is taken with default features off and native-tls plus json on, with a comment explaining that ureq 3.4.0 gates its connector on native-tls and that native-tls-no-default alone panics. The rendering stack is eframe and egui with the glow backend, winit for the window, and the image crate for the four formats a widget actually needs. One entry stands out: `egui-directx11` is required at an exact version from a path inside `vendor/`, so a fork is shipped in-tree and pinned rather than pulled from a registry. Alongside `src/` and `tests/` the repository carries `build.rs`, `deny.toml` for dependency policy, a pinned `rust-toolchain.toml`, and a separate updater verification document describing the portable updater's integrity checks and its trust boundary.

## Conclusion

The monitor suits someone running several of these tools against metered allowances who wants the remaining budget visible without opening five dashboards. The two-row layout is the part to understand before you rely on it, because Grok and Copilot only populate the long-window row and leave the short-window row empty, which reads as missing data rather than as a different billing shape. Before you install, read the credential handling for each provider you enable: Copilot and Grok both read sign-in state that lives outside your account's own files, and OpenCode Go asks you to paste a browser session cookie into a plaintext config. That is a real trade for a tool that claims no telemetry, and it is the trade the documentation is explicit about. Then check the rust version requirement, which is pinned to a specific release rather than a floor.

## FAQ

### Which providers does Claude Code Usage Monitor support?

Claude Code, Codex, Google Antigravity, OpenCode Go, Cursor, Grok Build and GitHub Copilot. Claude Code and Codex support multiple accounts and fill both the short-window and long-window rows, while Grok Build and Copilot bill over longer periods and appear on the long-window row only, leaving the short-window row empty.

### How do I install and start Claude Code Usage Monitor?

With WinGet, using winget install CodeZeno.ClaudeCodeUsageMonitor, or by downloading claude-code-usage-monitor.exe from the releases page. Run claude-code-usage-monitor to start it, or claude-code-usage-monitor --dashboard to open the settings dashboard directly. Windows 10 or 11 is required along with at least one supported provider signed in.

### What credentials does Claude Code Usage Monitor read?

Local sign-in credentials for the providers you enable, sent only to those providers' own services. Copilot and Grok Build read sign-in state that belongs to their own CLIs, with Copilot also accepting a token from the environment. OpenCode Go requires you to supply a workspace ID and a browser session cookie, either as environment variables or in a plaintext JSON config file.

### Does Claude Code Usage Monitor send any telemetry?

No. It has no backend service, collects no telemetry or analytics, and does not upload credentials or project files. It also does not modify the provider files it reads, and when Grok Build rejects a token the monitor asks the Grok CLI to refresh its own session rather than rewriting its auth.json.

## Sources

- [CodeZeno/Claude-Code-Usage-Monitor on GitHub](https://github.com/CodeZeno/Claude-Code-Usage-Monitor)
- [Issues](https://github.com/CodeZeno/Claude-Code-Usage-Monitor/issues)
- [License: MIT](https://github.com/CodeZeno/Claude-Code-Usage-Monitor/blob/main/LICENSE)
- [README](https://github.com/CodeZeno/Claude-Code-Usage-Monitor/blob/main/README.md)
- [Releases](https://github.com/CodeZeno/Claude-Code-Usage-Monitor/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/codezeno-claude-code-usage-monitor