OpenUsage shipped 22 release events in 30 days, then landed a ground-up 0.7.0 rebuild that moved the app deeper into native macOS territory. That is the story here. This is not a generic subscription tracker with AI labels taped on. It is a fast-moving, open-source menu bar instrument for developers who now juggle Claude Code, Codex, Cursor, Devin, Grok, OpenRouter, Antigravity, and soon GitHub Copilot usage in the same workday.

What OpenUsage is actually trying to measure

The official OpenUsage site frames the product as an “AI Limits Tracker for Cursor, Claude Code, Codex and more.” The page is blunt about the pain: developers pay for several AI coding subscriptions, each provider exposes limits differently, and hitting a cap mid-session feels stupid because the information existed somewhere. OpenUsage puts those limits in the macOS menu bar instead of making users dig through separate dashboards.

The GitHub repository says the same thing in more operational terms. OpenUsage tracks AI coding plans from the macOS menu bar, showing session and weekly limits, credits, and spend in one popover. Users can pin the most important metrics straight into the menu bar, up to two per provider according to the README excerpt.

That narrow product definition matters. The tool is not trying to become a general billing warehouse, FinOps suite, or vendor-neutral observability backend. It is a local utility for AI coding tool usage, built around the idea that your limit state should be glanceable while you work.

The repository and website both describe a native macOS app. The README says installation is available through Homebrew Cask or a universal DMG, with signed and notarized Sparkle updates. It requires macOS 15 Sequoia or later. GitHub identifies the repository language as Swift, and the README describes a SwiftPM executable with SwiftUI hosted in an AppKit-owned NSStatusItem and NSPopover, using Swift 6 strict concurrency.

The supported provider list is already broad for such a focused app. The repository lists Antigravity, Claude, Codex, Cursor, Devin, Grok, and OpenRouter. The v0.7.1-beta.1 release adds a GitHub Copilot usage provider. The release notes also show pricing updates for GLM 5.2 in the Cursor spend manifest, which is a small but telling detail. This app has to chase provider quirks, not just render a pretty meter.

OpenUsage is OSI-approved open source under MIT, according to the ToolVitals openness field and the repository license signal. That wording is safe here because the payload classifies it as osi_approved_oss and the GitHub API reports an MIT License. There is no hosted pricing tracked in the ToolVitals payload, and the official site presents the app as free for macOS.

The 0.7.0 rebuild is the main signal

The v0.7.0 release notes call it “a brand-new OpenUsage.” That line is not just marketing copy. The release says the app was rebuilt from the ground up to be faster, lighter, and more at home on Mac. It also says usage and sign-ins are still read from the machine, while the app and look are new.

That combination tells a clean product story. OpenUsage is keeping the local-first credential model while replacing the app shell and interaction model. For a usage tracker that reads local auth files, keychain state, app state, provider APIs, and ccusage data, continuity around local sign-ins is more important than visual polish. A pretty rewrite that breaks credential behavior would be a disaster. The release notes explicitly try to calm that fear.

The new release adds or highlights more providers: Claude, Codex, Cursor, Grok, Devin, and Antigravity in one place. It adds usage trend sparklines for Claude, Codex, Cursor, and Grok. It adds pacing, including an estimate such as “Limit in 3h 45m.” It improves spend display by pairing cost and tokens and using clean zero states. It also adds Codex limit resets in the menu bar and popover.

Those are not random features. They all point toward the same product bet: AI coding subscriptions are becoming operational capacity. Developers do not just need to know what they spent last month. They need to know whether the current session, weekly quota, credit pool, or daily spend trend will interrupt the next hour of work.

The beta history around v0.7.0 reinforces that direction. v0.7.0-beta.12 added an “Always Show Pacing” setting, extended usage trend sparklines to Cursor and Grok, added usage trend sparklines for Claude and Codex, clamped quota percent meters to 0-100, fixed Codex session usage percent, and scoped snapshot freshness to the running session. That is a lot of work on measurement semantics, not just layout.

v0.7.0-beta.13 added expandable dashboard metrics, unused session states for Codex and Claude, a resizable menu-bar panel, Claude credential fallback behavior, pace marker fixes, and cleaner right-click menus. It also carried an Early Access warning that beta updates reset settings because migrations were not shipping during that phase. That warning is rough for users, but honest. It tells buyers not to confuse beta channel velocity with enterprise-grade migration stability.

v0.7.0-beta.16 added Antigravity, opt-out anonymous PostHog usage analytics, crash and uncaught-exception reporting, and fixes for discontinued Sonnet weekly limits and ccusage day buckets. The ccusage fix is especially important because “no fabricated $0.00 for unreported days” is a data integrity issue. A usage tracker must prefer missing data over false reassurance.

ToolVitals metrics say velocity first, maturity second

ToolVitals gives OpenUsage a hot score of 214.6, a health score of 84, a shipping score of 95, and a ToolVitals score of 90. It tracks 3,036 GitHub stars, 30 GitHub releases in 90 days, and 22 release events in 30 days, with data confidence at 88. GitHub commits over 30 days and active contributor counts are not present in the payload, so they should not be inferred.

The release velocity is the cleanest quantitative signal. Twenty-two release events in 30 days is not maintenance mode. Thirty releases in 90 days means OpenUsage is pushing frequent user-facing packages, not only merging private work. The shipping score of 95 agrees with that picture.

The health score of 84 is strong, but it should be read with care. ToolVitals can see release activity, stars, SSL and uptime style signals depending on the collector path, and public repository evidence. It cannot prove the app works correctly against every provider account state. It cannot verify whether Cursor, Claude, Codex, Devin, Grok, OpenRouter, Antigravity, or Copilot responses stay stable after vendor-side changes.

That distinction matters because OpenUsage lives on unstable ground. Its value depends on provider-specific scraping, local credential reuse, vendor APIs, ccusage behavior, and price manifests. A conventional desktop app can be stable for months. A tracker for AI coding subscription limits can rot when one provider changes auth, naming, limits, pricing, or reset semantics. High shipping velocity is not vanity here. It is part of the survival strategy.

The star count is also easy to misread. 3,036 GitHub stars is meaningful for a young macOS utility, but it is not the same kind of signal as 140,397 stars on Next.js. OpenUsage is a focused finance and billing tool for AI coding usage. It does not need framework-scale adoption to be useful. It needs enough users across enough provider plans to expose edge cases quickly.

For a skeptical engineering lead, the right read is this: OpenUsage has enough public traction and release activity to evaluate, but not enough evidence to treat it as a settled procurement default. Test it with your actual provider mix, especially if you depend on Cursor spend, Claude local spend, OpenRouter API keys, or Codex reset behavior. The metrics say the maintainers are moving fast. They do not say your account state will be measured perfectly.

The local API is the sleeper feature

The official website describes OpenUsage as a weather station for AI usage. The app measures usage, then other surfaces read the forecast through a local API. The site shows curl examples for localhost:6736/v1/usage and localhost:6736/v1/usage/claude.

The README says the API is loopback-only at 127.0.0.1:6736, serves usage numbers rather than credentials, and keeps the same format as the original app. It also warns that browser pages can read it, with a linked privacy note. That warning is good. A local HTTP API is powerful, but it creates a local data exposure surface if treated casually.

This API changes the product from a menu bar widget into local infrastructure. A terminal prompt, editor status line, shell script, dashboard, or automation agent can read usage state without handling provider credentials. That is exactly the kind of small local primitive developers will wire into personal workflows.

The design also fits the open-source license. If a team wants different display rules, alert thresholds, or editor integrations, the local API gives them a stable enough boundary to build around. ToolVitals cannot verify API stability from the payload, but the README and website both treat it as a named feature, not an accident.

The privacy model deserves careful reading. The repository says most providers reuse credentials already on the machine, such as keychain entries, auth files, or app state. OpenRouter is the exception because the user supplies an API key. The README says nothing leaves the Mac except the same API calls the vendor tools make. That is a strong positioning claim, and it is central to why a local app makes sense in this category.

Recent releases show provider churn, not just UI polish

v0.6.28 added a retirement notice banner to the overview, Codex rate limit resets, and a weekly menu bar metric preference. It also patched security vulnerabilities through dependency updates and overrides, patched Rust security vulnerabilities through cargo update, and fixed several Codex auth recovery paths. That release sits right before the Swift flip and shows why this project needs frequent releases.

The v0.7.0 line then shifts from old-app maintenance into the new native app. v0.7.0-beta.14 and beta.15 were heavy on menu bar panel behavior, Liquid Glass-related UI details, settings naming, panel resizing, and Cursor balance fixes. That pattern is normal for a Mac rewrite, but it is not the whole story. Provider correctness kept showing up alongside interface work.

v0.7.1-beta.1 is the clearest post-rebuild direction marker. It adds GitHub Copilot usage, restores widget removal undo behavior, prices GLM 5.2 in the spend manifest, brings back provider quick-link buttons, and adds a per-provider Copy as Image card. Copilot support is the notable one. It moves OpenUsage closer to covering the default AI coding stack many teams actually pay for.

There is an important maintainers’ lesson in this release stream. ToolVitals is detecting velocity, but the public release notes are also doing product education. Keep separating provider behavior changes from UI changes. Keep calling out cases where vendor data is delayed, unavailable, or intentionally hidden to avoid misleading numbers. For this product, credibility comes from explaining uncertainty before users catch it.

What ToolVitals cannot tell you

ToolVitals cannot tell whether OpenUsage parses every provider correctly today. It cannot see private crash rates, user retention, revenue, or how often provider APIs break. It cannot prove that anonymous telemetry is implemented exactly as described. It cannot tell whether the app feels light on an older Intel Mac running macOS Sequoia.

ToolVitals also cannot judge code quality from the supplied payload. The repository says the app uses Swift, SwiftUI, AppKit status items, provider runtime protocols, normalized MetricLine values, and Swift 6 strict concurrency. Those are useful architecture clues, but they are not a code audit. A high score is a health signal, not a guarantee.

The payload has gaps. It does not provide 30-day commit count or active contributor count. It gives recent release events, release descriptions, stars, openness, and scores. The safe conclusion is that OpenUsage is shipping quickly in public and has a clear product direction. The unsafe conclusion would be that the implementation is bug-free or that all providers have equal data fidelity.

The local excerpts also show one healthy contradiction to handle conservatively. Earlier beta notes warned that beta updates reset settings because Early Access shipped without migrations. The v0.7.0 release later says settings now stick. The best reading is chronological: that was a beta-channel limitation during the run-up, and the stable 0.7.0 release claims the migration pain was addressed. It is not proof that future migrations will always be smooth.

Comparisons: small tool, big-tool velocity

Among related tools in the payload, Next.js is still the gravity well: 140,397 GitHub stars, a 229.2 hot score, a 100 shipping score, and 44 release events in 30 days. OpenUsage is nowhere near that adoption scale. But OpenUsage posts 22 release events in 30 days and a 95 shipping score with only 3,036 stars. Relative to its scope, that is aggressive.

Paseo is the closest metric twin in the related set. It has the same 214.6 hot score and the same 22 release events in 30 days, but 9,387 stars and a 100 shipping score. That makes OpenUsage look less like a broad popularity story and more like a focused velocity story. It is keeping pace on release events with a larger tracked tool while serving a narrower macOS-specific use case.

The finance-category comparison is also useful. QuantDinger has 8,949 stars, a 194.9 hot score, a 94 shipping score, and 17 release events in 30 days. OpenUsage has fewer stars but a higher hot score, a slightly higher shipping score, and more 30-day release events. In the ToolVitals view, OpenUsage is one of the more active finance and billing tools right now, even though its domain is AI subscription usage rather than traditional accounting or markets.

Recommendation

If your team uses more than one AI coding subscription on macOS, evaluate OpenUsage because its product focus matches the real failure mode: developers do not run out of tokens in a spreadsheet, they run out while working. The menu bar view, pacing estimates, reset countdowns, provider grouping, and local API all aim at that moment.

Do not evaluate it like a finance system of record. Evaluate it like a local instrument panel. Install it on a few real developer machines, connect the providers you actually use, compare its readings against vendor dashboards for a week, and decide whether the menu bar and local API reduce surprise limits enough to keep.

For individual developers, the bar is lower. If you pay for Claude Code, Codex, Cursor, Grok, Devin, OpenRouter, Antigravity, or Copilot and keep guessing where your quota went, OpenUsage is worth testing now. The MIT license, free macOS distribution, native Swift direction, and 22 recent release events make the downside small. The main risk is provider churn. The project appears to understand that risk, which is exactly why the release cadence matters.

Sources