Claude Code Usage Monitor: a Windows taskbar widget for provider limits

The problem: rate limits arrive without warning

Claude Code, Codex and Cursor all enforce usage limits, and none of them put the remaining allowance in front of you while you work. You find out when a request is refused. The README frames the widget as a fix for that: it displays current usage and the time remaining until each limit resets, sitting in the Windows taskbar rather than in a terminal tab or a browser dashboard.

The audience is narrow and specific. You need Windows 10 or Windows 11, and you need at least one supported provider installed and signed in. The project supports Claude Code, Codex, Google Antigravity, OpenCode Go and Cursor, and multiple accounts for Claude Code and Codex. Anyone working primarily on macOS or Linux is outside the target: the badge at the top of the README says Windows, and no other platform is listed under Requirements.

How the widget gets your numbers

There is no backend. According to the README, the monitor reads local sign-in credentials for the providers you enable and sends usage requests directly to their official services. It states that it collects no telemetry and does not upload credentials or project files. Credentials are read without modifying the provider files that contain them.

Claude Code credentials can be detected from the CLI, the Claude desktop app, or WSL. Codex, Antigravity and Cursor each need their own client installed and signed in, then enabled under Providers in the dashboard. Cursor's local session is detected automatically, and CURSOR_SESSION_TOKEN can override it. OpenCode Go is the odd one out: it needs credentials you supply yourself, either through environment variables or a JSON config file.

The dependency list in Cargo.toml backs up the architecture. ureq handles HTTP with native-tls and JSON, eframe and egui_extras with the glow backend draw the interface, and the windows crate pulls in a long list of Win32 features covering Shell, Gdi, Dwm, Direct3D and DirectComposition. That is a native Windows application, not a web view. The build requires Rust 1.95 or later.

Installing from WinGet and opening the dashboard

The README gives WinGet as the primary install path. Run this in PowerShell:

winget install CodeZeno.ClaudeCodeUsageMonitor

If you prefer not to use WinGet, the README says to download claude-code-usage-monitor.exe from GitHub Releases and run it directly. There is no installer step documented beyond that.

Once installed, start the monitor from a terminal:

claude-code-usage-monitor

The same binary opens the settings dashboard when passed a flag:

claude-code-usage-monitor --dashboard

Use the dashboard to select providers, change the refresh interval, choose a display, enable startup, or customize the widget. In the default theme, left-clicking a provider tray icon shows or hides the widget and right-clicking opens the menu. If nothing appears, the README points to a diagnostic mode: running claude-code-usage-monitor --diagnose writes a log to %TEMP%\claude-code-usage-monitor.log, and application settings live in %APPDATA%\ClaudeCodeUsageMonitor\settings.json.

One setting deserves attention before you judge the display. Settings > Display > Usage direction switches themes between showing what has been used and what is left, with Used as the default. Selecting Remaining makes a fresh limit read 100% and drain as you work. If the widget looks wrong on first launch, that toggle is the first thing to check.

OpenCode Go credentials are plain text on disk

The OpenCode Go path is the weakest part of the design, and the README is honest about it. You set OPENCODE_GO_WORKSPACE_ID and OPENCODE_GO_AUTH_COOKIE, or write a config file at %APPDATA%\opencode-go\config.json:

{
  "workspaceId": "wrk_01...",
  "authCookie": "your-opencode-auth-cookie"
}

The workspace ID comes from the OpenCode Go workspace URL, and the auth cookie comes from an authenticated opencode.ai browser session. The README states plainly that credentials saved in this JSON file are plain text and should be protected like a browser session cookie. Set OPENCODE_GO_CONFIG_FILE to point at a different path.

That is a real trade-off, not a footnote. An auth cookie pasted into a JSON file is a credential with the same power as your logged-in browser session, and it sits unencrypted in your roaming profile. The other four providers avoid this because the widget reads credentials their own clients already stored. If you only use Claude Code, you never touch this file. If OpenCode Go is your main provider, weigh whether you want that cookie on disk.

The second limitation is platform. Windows 10 or 11 is a hard requirement, and the repository shows no cross-platform build configuration. The related searches for a macOS version have no answer in this repository.

How it differs from terminal and editor readouts

The obvious alternative is a terminal-based usage readout, the kind of thing people search for as a Claude Code usage monitor in the terminal. The difference is where the number lives. A terminal tool prints usage when you run it, in the window you are already using for Claude Code. This widget draws continuously in the taskbar, so the figure is visible while you work in any application, and it survives closing every terminal. The cost is that it only exists on Windows, whereas a terminal script is portable to any machine that runs the CLI.

An editor extension is the other comparison point. An extension lives inside one editor and disappears when you switch to a different one or to a browser. The taskbar widget is independent of the editor, which is the reason it can cover Cursor and Codex at the same time as Claude Code. The README also mentions built-in themes and a visual Theme Studio, with theme authors opting in through .display bindings such as {claude.session.display:usage_line} and {claude.session.display:usage_badge}. Existing .percentage, .remaining and unsuffixed usage summaries keep their meaning, and warning thresholds should continue to use .percentage. That theming layer has no equivalent in a shell script.

Maintenance, licensing and upgrade cost

The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is the whole of the licence implication here; nothing in the repository adds a second licence or a contributor agreement that would change it.

Maintenance looks current. The last push was on 2026-09-16, and the most recent release, v2.11.28, was tagged the same day. Two further releases, v2.10.26 and v2.10.25, landed on 2026-09-13 and 2026-09-12. The version string in Cargo.toml matches v2.11.28, so the packaged binary and the source tree are in step.

Upgrade cost is low for users and moderate for builders. WinGet handles the binary, and the README describes configurable update settings in the dashboard. Building from source requires Rust 1.95 or later and cargo build --release, which produces target\release\claude-code-usage-monitor.exe. The dependency surface is the part to watch: eframe, egui_extras and the windows crate are all version-pinned, and the windows crate feature list is long. A major bump in any of them is a real migration, not a one-line change.

Editorial conclusion

Adopt it if you run Claude Code or Codex on Windows 10 or 11 and want reset times visible without opening a terminal. Skip it if you need macOS or Linux, or if you cannot accept a plain-text auth cookie in %APPDATA%\opencode-go\config.json. Before installing, confirm which of the five providers you actually have signed in, and run claude-code-usage-monitor --diagnose first if you are unsure whether your credentials will be detected.

Frequently asked questions

Official sources

1. CodeZeno/Claude-Code-Usage-Monitor on GitHub
2. Issues
3. License: MIT
4. README
5. Releases