TokenBar totals what every coding agent on your Mac is costing

What you are spending, across every agent you run

TokenBar sits in the macOS menu bar and reports what you are spending across more than twenty-five AI coding agents, reading the figures on the machine from each tool's own local session logs. No dock icon, no telemetry, no account.

The problem is fragmentation rather than absence. Most agents can tell you what a session cost, and each tells you separately, in its own units, for its own sessions. Someone running three of them has three partial answers and no total. Reading every tool's logs and presenting one number is the part nobody else does.

The menu bar item is configurable in what it displays: today's tokens, today's cost, a live rate in tokens per minute, or how much subscription quota remains, shown as signal bars, a ring, or a shape that visibly depletes as the window drains. A running cat moves faster the more you spend, and the README credits the earlier project that idea comes from by name, which is the right way to borrow something.

The audience is anyone paying for more than one coding agent, or on a subscription with a quota they would rather not discover by hitting.

A Rust core behind a Swift interface, and the seam is handled carefully

The construction is unusual for a menu bar utility and the reasons show in the build files.

The project is a Rust workspace producing a static library, linked into a Swift application, with the parsing and accounting living on the Rust side and the interface in Swift. That split makes sense for something reading many log formats quickly while presenting a native interface.

What makes it worth mentioning is a comment in the build configuration addressing the hazard that arrangement creates: the library is called across a C interface from Swift, and a panic must not unwind across that boundary. That is precisely the failure mode of Rust-to-Swift interoperation, and knowing it, writing it down at the point where the setting is configured, and citing the compiler version where the behaviour changed is the mark of someone who has thought about the crash rather than the feature.

The build instructions carry a second practical note in the same spirit, stating that build order matters because the static library must exist before the Swift build links, and that commands must run from the repository root because a library path is relative. Both are the sort of thing a contributor discovers painfully, documented in advance.

Installing it, or building it

The packaged route is a single cask install.

brew install --cask nanako0129/tokenbar/tokenbar

Updates arrive through an appcast file in the repository, meaning the application checks for and applies its own updates rather than waiting on a package manager.

Building from source is a short sequence, and the project's own task file spells out what each step does.

make                        # cargo build --release, then swift build
make run                    # build + launch TokenBar
swift run TokenBar --smoke  # run the FFI smoke test

Shipping a dedicated smoke test for the foreign function interface, as a runnable target rather than as part of a test suite, tells you where the author expects breakage to occur, and it gives a contributor one command to confirm the two halves still speak to each other.

The requirements are narrower than the install suggests. The badges state macOS 14 or newer and Apple Silicon, so Intel Macs are not covered, and the glass interface styling is tied to a much newer system version. The repository also uses submodules for a vendored dependency, so a clone that skips them will not build.

Twenty-five integrations is the feature and the liability

Supporting more than twenty-five agents is the reason to install this and the reason to expect maintenance friction.

Each supported tool writes its own session logs in its own format, in its own location, with its own accounting of what a token is and how a cached read is priced. None of those formats is a published interface, so each is an implementation detail of another project that can change without warning. Twenty-five of them means twenty-five independent sources of breakage, and the surface grows every time a new agent is added.

The most recent release illustrates the cost directly. Its notes open with a warning that turn counts for one agent jump from zero to thousands and that the first launch rescans that agent's transcripts once. That is a correction to how one integration counted, disclosed before the change rather than discovered afterwards by a confused user.

Putting that warning at the top of the release notes rather than in a changelog entry is the correct handling. It does mean a prospective user should expect numbers to move as integrations are corrected, and should treat the tool as a good relative signal rather than an accounting record.

Version numbering supports that reading, at 1.18.0 published on 2026-09-16 with the last push on 2026-09-17.

What it reads, and what it does not send

The privacy position is stated plainly: figures are read on the device from local session logs, with no telemetry and no account.

That is the correct architecture for this problem and it has a corollary worth stating. Reading local session logs means the application has access to files containing your prompts and your agents' output, because that is where the usage figures live. The processing stays local and the tool is doing something with material most people would consider private.

Given that, the absence of telemetry is not a nicety but the central claim, and the fact that the source is available under a permissive licence is what makes it checkable rather than merely asserted.

A second consequence is coverage. Anything that does not write a local log cannot be counted, so usage through a web interface or another machine is invisible. The number is what this machine spent, which is the right scope for a menu bar item and is not a complete bill.

The repository carries contributor documentation and instruction files for coding agents alongside fixtures, which for a project whose correctness depends on parsing many log formats is the right thing to have: fixtures are how you keep twenty-five parsers honest.

A usage command line tool is the alternative, and the split is ambient against on-demand

The alternative is a command line usage reader, or the cost command each agent provides for its own sessions.

The difference is when you find out. A command line tool answers precisely when asked, composes into scripts and reports, runs anywhere, and requires you to remember to ask. That last point is the whole problem, since nobody checks their spend before the session that overruns it.

TokenBar is ambient. The figure is in front of you continuously, the rate display shows spending as it happens, and the quota display answers the question you would otherwise ask only after being refused. In exchange it is a graphical application on one operating system, restricted to one processor architecture, and it cannot be scripted.

They also differ in scope. A per-agent command reports that agent. This aggregates across every agent it can parse, which is the number that matters when the spending is spread out.

Take the command line tool when you want usage inside automation or a report. Take this when the problem is that you are not looking, which for subscription quotas and running meters is usually the actual problem.

MIT terms and what to check first

The project is MIT licensed, the permissive choice, and for a desktop utility it raises nothing in review. The vendored dependency brought in as a submodule carries its own terms and is worth a glance before redistribution. This is not legal advice.

The repository is well furnished for its size: a Rust workspace with the interface crate and a vendored core, Swift sources and a package manifest, a task file, fixtures, an update feed, contributor documentation and agent instruction files. Three releases are visible and the cadence is quick.

Two checks before installing. Confirm your hardware and system version against the requirements, since Apple Silicon and macOS 14 are hard floors and the glass styling needs considerably newer. Then, if the reason you want it is a subscription quota rather than API cost, verify that the agents you actually use are among the supported set and that their quota reporting is one of the things parsed, because the coverage claim is about token accounting across many tools and the quota display is the narrower feature.

Editorial conclusion

TokenBar fits anyone running several coding agents on an Apple Silicon Mac who wants one continuously visible figure rather than three tools each reporting their own, and particularly anyone on a subscription quota they would rather watch than discover. A command line usage reader remains the better choice when you want the number inside a script or a report. Check the hard floors of Apple Silicon and macOS 14 before installing, and expect figures to shift as integrations are corrected, since the most recent release opens by warning that one agent's turn counts jump from zero to thousands and that the first launch rescans its transcripts once.

Frequently asked questions

Official sources

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