CodexBar shows provider limit windows in the menu bar, using sessions you already have

Merge Icons collapses every provider into one switcher

The menu bar can show one status item per provider, or Merge Icons mode, which collapses them behind a single icon with a provider switcher. Icons are dynamic, there is no Dock icon, and the app targets macOS 14 Sonoma and up. Each provider panel lists session, weekly, and monthly windows with countdowns to the next reset, so the number you act on is the time left, not a percentage.

What the collapsed view gives up is at-a-glance identity. With Merge Icons on, you cannot see which of your providers is close to its limit until you open the switcher and look, which defeats the point of a glanceable indicator for someone juggling several subscriptions. If you subscribe to two or three providers, per-provider items cost more menu bar width but keep the countdown visible without a click.

Each provider hands over a different kind of credential

There is no single login, because there is no single API. Codex reads an OAuth API or the local Codex CLI, with optional OpenAI web dashboard extras from cookies. Claude accepts an OAuth API, browser cookies, or a CLI PTY fallback. Cursor and OpenCode read browser session cookies. Devin takes a Chrome localStorage session or a manual Bearer token. Manus uses a browser `session_id`, Kimi a JWT taken from the `kimi-auth` cookie, Copilot the GitHub device flow, Gemini an OAuth-backed quota API built on Gemini CLI credentials with no cookies at all.

That spread has two consequences. Coverage is uneven, because a provider whose only route is a browser cookie gives you nothing once that cookie is rotated on a fresh sign-in. And Antigravity is flagged experimental, with a local language server probe, an `agy` CLI HTTPS source, and a Google OAuth fallback. Plan on re-authenticating rather than on a permanent connection.

The config path moved and the old one still loads

Provider toggles and API keys live in a resolved config file. New installs use:

~/.config/codexbar/config.json

Installs that predate the move keep reading `~/.codexbar/config.json`, so two layouts exist in the field at once, and a script that writes the new path directly will not affect a machine still resolving the legacy one. Check which file your install resolves before you script provider changes.

The same toggles are available from the CLI, which is the part worth scripting:

codexbar config providers
codexbar config enable --provider grok
codexbar config disable --provider cursor

--api-key leaks into shell history, --stdin does not

API key providers can be configured without opening Settings:

printf '%s' "$ELEVENLABS_API_KEY" | codexbar config set-api-key --provider elevenlabs --stdin

set-api-key trims the piped value, stores it with restrictive config file permissions, and enables the provider by default. Two details matter when you script this. The default enable means a command you ran only to stage a key also switches the provider on, so pass `--no-enable` when you want the key stored and nothing else. The alternative `--api-key <key>` is described as fitting one-off local scripts where shell history is not a concern, which is exactly the case where it is the wrong choice on a shared machine, since the key lands in your history file in clear text.

Linux requires glibc 2.39, Qt 6.4, and a separately installed CLI

The desktop build is a separate Qt 6 application for Linux, supporting Wayland and X11, with usage and spending windows, its own settings, desktop notifications, and an optional tray icon. Published archives target x86_64 and ARM64 and require glibc 2.39 or newer, Qt 6.4 or newer, and a CodexBar CLI installed separately. Python 3 runs the per-user installer, which keeps the CLI resource bundle beside the executable and installs a launcher with optional login startup.

Install paths are three: a Homebrew formula for Linux today, the Arch User Repository with `yay -S codexbar-cli`, or tarballs from releases, including static musl builds for Linux alongside the glibc ones. GNOME may need a tray extension, although the app windows work without one. No Windows artifact appears anywhere in that list, so on Windows there is nothing to install from this project, and a feature comparison document tracks the gaps between the Linux and macOS builds.

Cost numbers exist only where the source exposes enough detail

The app shows credit balances, Admin API spend dashboards, provider billing summaries, and local cost scans, with the qualifier that local cost scans apply where the source exposes enough detail. That qualifier is where the limits are. OpenCode Go keeps local SQLite cost history, and Vertex AI derives token cost tracking from local Claude logs, so those two can report spend that no remote endpoint returns. Other providers report through their own usage APIs, and some entries are explicitly fallback based, such as OpenAI, where Admin API key usage and cost graphs sit next to a legacy credit-balance fallback.

So the figure in one provider panel and the figure in another are not the same kind of number. Comparing a monthly credit total from one provider against a derived local estimate from another tells you less than it looks like it does.

make start-release hardcodes the maintainer's home directory

The Makefile is mostly thin wrappers over scripts in Scripts/, including build, test, lint, and format, but one target is machine specific. start-release runs `./Scripts/package_app.sh release`, kills any running CodexBar process, and then does this:

cd /Users/steipete/Projects/codexbar && open -n /Users/steipete/Projects/codexbar/CodexBar.app

The packaging step is portable; the launch step is not. On a clone under any other home directory the target packages successfully and then fails at the open command, which reads as a build problem when it is a hardcoded path. Use Scripts/package_app.sh directly if you want the artifact without the launch.

The test targets encode the same kind of local knowledge: test-tty suppresses keychain access with CODEXBAR_SUPPRESS_TEST_KEYCHAIN_ACCESS=1, while test-live requires CODEXBAR_ALLOW_TEST_KEYCHAIN_ACCESS=1 and LIVE_TEST=1 before running LiveAccountTests. Account-dependent behaviour is opt-in, so a normal test run does not touch real credentials.

Three releases in four days is the update cadence

CodexBar 0.81.0 shipped on October 24, 0.82.0 on October 26, and 0.83.0 on October 31, with a push to main on October 31, 2026. The repository carries appcast.xml alongside version.env and CHANGELOG.md, which is the layout of an app that publishes updates through a feed rather than waiting for a store review.

The practical effect is that a build installed a week ago can be several releases behind, and each release adds or changes providers. Since the app's value is reading live session state, an old build is also an old view of how a provider reports that state. Check the releases page before you conclude that a provider panel is broken, and read CHANGELOG.md for the provider list rather than assuming the panel set you saw at install time still exists.

Editorial conclusion

CodexBar fits a person with several AI coding subscriptions who wants to see when the weekly window resets before starting a long task, and it does not fit anyone who wants a Windows build or a vendor-neutral usage report. Before you rely on it, check which credential each provider you care about needs, since several providers read a browser cookie or a local session that expires on its own, and treat the cost numbers as provider-by-provider rather than comparable across providers.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. steipete/CodexBar on GitHub