# CodexBar CodexBar is a free, open-source usage monitor for AI coding tools that puts quota windows, reset times, balances, spend, and provider status into a macOS menu bar, Linux desktop app, and CLI. It is designed for developers juggling multiple coding-agent subscriptions rather than for writing code itself. Canonical URL: https://aiidelist.com/ide/codexbar Language: en Updated: 2026-09-25 ## Overview - Category: Developer Workflow Tools - An open-source multi-provider usage and quota monitor for developers who want one place to track AI coding subscriptions, limits, spend, resets, and provider status. - Editor base: Standalone - Platforms: macOS 14+, Linux - Open source: Yes - Local model support: No - Bring your own API key: No ## Quick verdict CodexBar fits developers who want a single, inspectable monitor for many AI coding subscriptions and API accounts. Its breadth and scriptability are useful in mixed-tool workflows, while users who only need one or two providers may prefer a narrower tracker with less setup. ## Best for - Developers using several AI coding tools and subscriptions - macOS users who want quota and reset information visible without opening provider dashboards - Developers who want machine-readable usage data for shell scripts, dashboards, or CI - Users who need to compare remaining limits, balances, and spend across providers ## Strengths - Unusually broad coverage across AI coding subscriptions and API providers - Free and MIT-licensed with active public development - Works as a visual monitor and a scriptable CLI - Can reuse existing provider authentication instead of requiring a separate CodexBar account - Useful for both quota limits and spend or credit visibility ## Limitations - Users looking for an AI code editor or coding agent - Windows users who require an officially supported native first-party app - Users who only track one provider and prefer the smallest possible configuration surface - Users unwilling to grant optional browser, Keychain, or local-file access required by some provider integrations - The native macOS experience is more mature than other platforms - Windows is not an officially supported first-party platform - Some providers rely on browser sessions, local credentials, or provider endpoints that can change - Advanced multi-provider setups can require more permissions and configuration than single-provider trackers - It monitors AI tools but does not generate, edit, or review code ## Why Choose CodexBar? CodexBar is most useful when the problem is not choosing an AI coding model, but managing several of them at the same time. A developer may have a Codex subscription, Claude Code access, Cursor credits, Copilot allowances, an OpenRouter balance, and one or more API accounts. Each service exposes usage differently: rolling windows, weekly caps, monthly credits, prepaid balances, or spend-based budgets. CodexBar acts as a normalization layer so those limits can be checked from one workflow instead of opening multiple billing and usage pages. That distinction matters. CodexBar is not another assistant competing with Cursor, Claude Code, or Codex CLI. It sits beside them. Its value increases as the number of paid AI tools in a developer's stack grows, especially when a long coding session can be interrupted by a rolling quota reset or when several subscriptions overlap. ## Core Workflow The practical workflow is source-first rather than account-first. Each provider can expose data through a different path: an OAuth session, an installed CLI, a provider API key, a browser session, or a known local data file. CodexBar selects an appropriate fetch strategy, converts the response into a common usage representation, and then exposes that same state through the desktop UI and CLI. This design has two practical consequences. First, data quality depends on the source available for a specific provider. A first-party OAuth or documented API path is generally easier to maintain than a browser-session integration. Second, the same provider may expose richer information through one source than another. For example, a lightweight local or CLI source may be enough for quota state, while an optional web-backed source may expose additional billing details. For a stable setup, use the least invasive source that provides the information actually needed. Start with OAuth or an existing provider CLI when supported. Add browser-cookie access only when the extra dashboard data is worth the additional permission surface. API keys should be scoped and handled as credentials, not as ordinary configuration values. ## Use Cases **Multi-subscription planning** is the clearest use case. Before starting a long agentic refactor, a developer can check which service has the healthiest remaining window and when constrained providers reset. CodexBar does not automatically route work between agents, but it makes the information needed for that decision much easier to see. **Spend awareness** matters for users mixing subscriptions with metered APIs. Subscription quotas and API balances are different resource types; putting them in one operational view helps prevent the mistake of treating an apparently available model as cost-free simply because a subscription product is also installed. **Automation and internal dashboards** are where the CLI becomes more valuable than the menu bar. JSON output can be consumed by shell scripts, status lines, dashboards, or CI checks. This makes CodexBar useful even on machines where the graphical interface is not the primary interaction surface. **Troubleshooting provider access** is a secondary use case. Because CodexBar distinguishes data sources and stale states, it can help determine whether a missing number is caused by expired authentication, a provider-side outage, or a local integration problem rather than simply presenting an unexplained empty value. ## Comparison to Alternatives CodexBar's main differentiator is breadth. Narrower quota trackers are often easier to understand because they focus on Claude Code, Codex, or a small set of providers. CodexBar instead accepts a larger configuration surface in exchange for supporting a much wider mixed-provider stack. That tradeoff affects the buying decision. A developer who only wants a single Claude or Codex percentage in the menu bar may find a focused utility simpler. A developer rotating among several coding agents, API gateways, model providers, and prepaid balances is more likely to benefit from CodexBar's normalized view and shared CLI. OpenUsage, AI Usage, UsageBar, QuotaBar, and terminal-oriented usage dashboards belong to the most relevant comparison class because they address the same operational problem: making AI quota and spend state visible without repeatedly opening provider dashboards. Useful comparison dimensions include provider coverage, operating-system support, authentication approach, history depth, source reliability, and whether automation-friendly output is available. ## Best Configuration Avoid enabling every provider simply because it is available. A cleaner configuration is to enable only services that are actually part of the daily development stack, order them by importance, and keep the highest-signal limits visible. This reduces background requests and makes the interface easier to scan. On macOS, a merged-icon layout is practical when several providers are active and menu-bar space is limited. For users who primarily consume the data programmatically, the CLI can instead be treated as the operational interface while the graphical app remains a convenience layer. After changing providers, credentials, or configuration files, validate the resolved configuration rather than debugging malformed settings indirectly: ```bash codexbar config validate --format json --pretty ``` When diagnosing unexpected behavior, inspect the normalized configuration without manually reconstructing defaults: ```bash codexbar config dump --pretty ``` These commands become more useful as a setup grows because CodexBar supports many provider-specific settings and authentication strategies. ## Migration Notes Newer CodexBar installations use `~/.config/codexbar/config.json`, while existing installations using the legacy `~/.codexbar/config.json` path are still recognized. Users migrating between machines should treat either file as sensitive because it can contain provider tokens, manual cookie headers, account selections, and other authentication-related settings. The project is also evolving quickly. Provider implementations can move between native code and bundled plugins without changing the high-level user workflow. Provider count therefore should not be treated as a guarantee that every integration has identical depth or stability. The more useful question is whether the specific provider and authentication method required by a workflow are documented and actively maintained. Linux support has expanded beyond a headless CLI into a Qt desktop integration, but the macOS app remains the reference native experience. Users standardizing across mixed operating systems should test the exact providers they depend on before assuming UI and authentication parity across every platform. ## Features ### Usage & Limits - Tracks provider quota windows and reset times - Shows balances, spend, and local cost history where available - Surfaces provider status incidents and stale-data states ### Interfaces - Native macOS menu bar app - Linux Qt desktop and tray integration - macOS/Linux CLI with text and JSON output - WidgetKit widgets on supported Apple platforms ### Provider Connectivity - 84 provider integrations in v0.66.0 - Supports OAuth, device flow, API keys, browser sessions, CLIs, and local data sources - Plugin architecture for provider-specific usage fetchers ### Configuration - Per-provider enablement, ordering, and display controls - Adaptive or fixed refresh cadence - Config validation and machine-readable CLI workflows ## Installation ````````sh brew install --cask codexbar ```````` ## Pricing open-source - Free & Open Source: $0 — MIT-licensed software. Provider subscriptions, API usage, and third-party service charges are separate. Pricing checked: 2026-09-25 ## Privacy and data handling CodexBar performs on-device parsing by default and reads only documented provider-specific locations when those integrations are enabled. Browser-cookie access is optional, some Chromium imports can involve macOS Keychain access, and provider tokens or token-account settings may be stored in CodexBar's local config with restrictive file permissions. Provider requests still send the relevant credential to that provider's endpoint, so users should enable only the data sources they need. ## Alternatives - OpenUsage - AI Usage - UsageBar - QuotaBar - OpenUsage.sh ## Sources - [Official website](https://codexbar.app/) - [Documentation](https://github.com/steipete/CodexBar/tree/main/docs) - [Installation](https://codexbar.app/) - [Download](https://github.com/steipete/CodexBar/releases/latest) - [Pricing](https://codexbar.app/) - [Changelog](https://github.com/steipete/CodexBar/blob/main/CHANGELOG.md) - [Official GitHub repository](https://github.com/steipete/CodexBar) - [Provider documentation](https://github.com/steipete/CodexBar/blob/main/docs/providers.md) - [CLI documentation](https://github.com/steipete/CodexBar/blob/main/docs/cli.md) - [Configuration documentation](https://github.com/steipete/CodexBar/blob/main/docs/configuration.md) - [Linux integration guide](https://github.com/steipete/CodexBar/blob/main/Integrations/Linux/README.md) - [GitHub releases](https://github.com/steipete/CodexBar/releases) - [MIT license](https://github.com/steipete/CodexBar/blob/main/LICENSE) Last checked: 2026-09-25 ## Update history - 2026-09-24: CodexBar 0.66.0 expanded the project to 84 providers, moved more built-in integrations onto bundled provider plugins, added several new provider integrations, and reduced unnecessary background cache writes.