Proof / April 24, 2026
OpenUsage.sh capability matrix
This page exists to turn the product claim into something concrete. The point is not “local tracker.” The point is what the dashboard actually covers once the workflow spans more than one coding agent or provider.
Short answer OpenUsage.sh is strongest when the workflow needs more than one number across more than one tool. The matrix below shows the real surface area: quotas, resets, rate limits, spend, model activity, local history, integrations, and mixed-provider comparison.
Core capability matrix
| Capability | Why it matters | OpenUsage.sh coverage |
|---|---|---|
| Quotas and remaining credits | Users need to know what is close to exhaustion or reset. | Tracked where provider surfaces expose quota, plan, or credit data. |
| Resets and usage windows | Limits without reset timing are less actionable. | Included where provider APIs or local sources expose reset or billing-window information. |
| Rate limits | Useful for API-heavy workflows and operational awareness. | Included for supported providers where live headers or endpoints expose rate-limit data. |
| Spend and billing activity | Necessary when the question is not just quota but budget burn. | Included for supported providers and workflows where spend or credit data is available. |
| Model usage | Usage spikes usually require model-level explanation. | Included where provider or local telemetry exposes model-level usage or token data. |
| Local history | Without history, the dashboard cannot explain trends or burn rate. | Daemon-backed history stored locally in SQLite. |
| Compare and analytics views | Mixed-tool workflows need more than one static list. | Built-in dashboard, detail, compare, and analytics views in the terminal. |
| Local integrations and hooks | Hooks and local telemetry improve fidelity beyond provider dashboards alone. | Supported integrations for Claude Code, Codex CLI, and OpenCode. |
| MCP usage visibility | Tool usage matters when agent workflows call local tools and MCP servers. | Included where integrations expose the data. |
| Mixed-provider coverage | The real value appears when the user wants one dashboard across the whole stack. | Supports coding agents, API platforms, and local runtimes across 17 providers. |
Coverage shape
| Surface | Examples | Why it matters |
|---|---|---|
| Coding agents and IDEs | Claude Code, Codex CLI, Cursor, GitHub Copilot, Gemini CLI, OpenCode, Ollama | These are the tools most developers actually work inside, so the dashboard has to fit real day-to-day usage. |
| API platforms | OpenAI, Anthropic, OpenRouter, Groq, Mistral, DeepSeek, xAI, Z.AI, Gemini API, Alibaba Cloud | API spend and rate limits often live outside the coding agent surface, but still affect the same workflow. |
| Local-first workflow | Terminal UI, daemon-backed history, auto-detection, local SQLite | This keeps the product in the category of a local dashboard, not a hosted observability platform. |
What this matrix means
Related pages
OpenUsage.sh vs OpenUsage.ai
Use the direct comparison if the reader is deciding between the terminal-first mixed-tool category and the simpler menu bar limits-tracker category.
PositioningBest way to track coding agent usage and quotas across providers
Use the broader guide if the reader is still deciding what category of tool they need.