← BACK TO PROJECTS

OpenUsage Contributions

Local instrumentation for AI developer-tool quotas, spend, and model usage across fast-changing providers.

What I Built

OpenUsage is a desktop app for tracking usage limits, credits, and quota windows across AI coding tools. My contributions focus on provider integrations for tools whose usage data lives in local client state or authenticated provider endpoints.

The goal is practical: when builders use several AI coding products in parallel, they need to know which models are available, what limits are close, and whether a session is burning through scarce quota.

Why It Matters

AI developer tooling is fragmenting quickly. A single builder might use Codex, Claude Code, Cursor, Antigravity, OpenCode, Copilot, and provider-specific dashboards in the same week. Each has different quota windows, reset rules, and visibility gaps.

Good product work here is not just reading a number. It is making usage state understandable without asking users to centralize sensitive development activity in yet another service.

Product And Technical Decisions

I reframed provider work around authenticated local instrumentation: read what the user’s installed client already knows, show it clearly, and fail safely when the provider changes.

For Antigravity, the integration discovers the local service port, attaches the session headers expected by the local client, and queries status endpoints for model and quota state. For OpenCode Go, the integration reads local auth and session usage state. For Cursor-style usage displays, the work maps credit grants, billing periods, and prepaid balances into a single user-facing view.

The product tradeoff is maintainability. These provider integrations must be explicit about assumptions because local clients and private APIs change. The code and docs should make breakage visible instead of silently showing misleading quota data.

AI System Design

This project is not a model-serving app. Its AI relevance is the operating layer around AI tools: quota visibility, model availability, and provider-specific limits that affect how builders choose tools during a work session.

The most important design principle is privacy-preserving visibility. Where possible, usage is derived locally from the user’s machine and displayed locally in the desktop app.

Evidence / Outcomes

  • Contributions live in the patppham/openusage fork and provider documentation.
  • Antigravity and OpenCode Go provider work includes model-level usage and quota handling.
  • Provider docs describe detection, data sources, limit windows, and failure behavior so future maintainers can reason about compatibility.
  • Recent work added model breakdown text lines and session usage tracking for AI coding providers.

What I Would Improve Next

I would add provider conformance tests with captured, sanitized fixtures for common account states: fresh account, near-limit account, drained model, expired auth, and changed local service shape. That would make provider breakage obvious before users rely on stale numbers.