CCSeva puts your Claude Code usage in the macOS menu bar

What the menu bar item shows

The app is described as a lightweight, native Swift macOS menu bar app for tracking your Claude Code usage in real time, with token consumption, costs, session blocks and server-side limits in an elegant native interface. The features list starts with the thing you see without clicking anything. The usage percentage is shown right in the menu bar with a colour coded status. Clicking opens a popover with five tabs, Dashboard, Live, Analytics, Terminal and Settings, with the Analytics tab built on Swift Charts. Beyond that there is a five hour session block view with current block tokens, burn rate, an end of window projection and a reset countdown, a weekly usage history with week by week token and cost rollups matching Claude's weekly limits, and a per model and per project cost breakdown so you can see where the tokens and the dollars go.

Server truth, with a local estimate as the fallback

The most interesting design decision is where the numbers come from. The app reads Claude Code's OAuth usage endpoint for real five hour and weekly utilisation, including usage from your other devices, plus a predicted cutoff time, and it falls back automatically to local estimation when the endpoint is unavailable. That distinction matters more than it first appears. A locally computed figure can only see what is in the transcripts on this machine, so a Mac that has been idle while you worked elsewhere would report a lower number than the limit actually allows. The server figure is the one that matches the account, and the predicted cutoff is what tells you whether the current pace will finish inside the window. When the endpoint is unreachable, you are reading a local reconstruction, and the app is explicit that this is what it is doing.

The data source is your own transcript files

The app does not need a server to tell you what you have used, because Claude Code already writes the transcripts locally. The README says the app parses your `~/.claude` transcripts directly, and the tech stack line is more specific, native, ccusage compatible JSONL parsing with an incremental scan and dedup, plus the five hour block computation. The configuration is picked up automatically, since the app detects your Claude Code configuration from the `~/.claude` directory and refreshes on file changes, with a periodic fallback poll. The credit for the data model goes to the `ccusage` project, which the README credits for the usage data format and the five hour block algorithm, and the parsing is described as ccusage compatible, so the numbers line up with what the wider community already reports.

The optional sync, and what it refuses to send

There is an optional connection to a private usage dashboard, and the README is unusually explicit about its boundaries. In Settings you open claudecode.directory, choose Connect with GitHub, and the app opens a short-lived verification page in your browser and stores the resulting device credential in the macOS Keychain. Connected Macs sync idempotent daily and model aggregates in the background, and can be disconnected from either CCSeva or the website. The sync is local first and opt-in. CCSeva uploads token totals, estimated cost, date, timezone, harness, provider and model, and it never uploads prompts, responses, transcript content, project names or paths, request IDs, API keys, or Claude OAuth credentials. For local integration testing you set `CCSEVA_DIRECTORY_URL` to the dynamic directory server URL, while production builds default to `https://claudecode.directory`.

Installing the release, and the Gatekeeper dance

The recommended route is a release download from GitHub Releases, and for Apple Silicon the artifacts are `CCSeva-<version>-arm64.zip` or `CCSeva-<version>-arm64.dmg`. The catch is stated plainly. Until a Developer ID certificate is configured, release artifacts are ad-hoc signed, so the first time you open the app macOS Gatekeeper will block it, and the README gives you the two ways through. Either right click `CCSeva.app` and choose Open, then confirm, or remove the quarantine attribute:

xattr -dr com.apple.quarantine CCSeva.app

That second route is the one to understand before you use it. Stripping the quarantine attribute is telling macOS to stop asking, which is reasonable for a build you built yourself, and less reasonable for an artifact you downloaded from the internet. If the app is unsigned, you are trusting whoever produced that zip, and the README is honest that this is the current state rather than promising a notarised build.

Building the native app from source

The source route requires Xcode 16.4 with Swift 6.1 and macOS 14 or later, Sonoma, and the app itself lives in the `swift/` directory of the repository:

git clone https://github.com/Iamshankhadeep/ccseva.git
cd ccseva/swift
./scripts/build-app.sh        # release build → dist/CCSeva.app (ad-hoc codesigned)
mv dist/CCSeva.app /Applications/

The README points at `swift/README.md` for the full build, architecture and data pipeline details. The requirements list is short: macOS 14 or later, and Claude Code installed and configured with valid `~/.claude` data, since without those transcripts the app has nothing to read. The native app is roughly 3 MB installed with zero runtime dependencies, no Electron, no Node, and near-zero idle overhead, which is the argument for the rewrite.

The legacy Electron app is still in the tree

The repository carries two applications, and the README is clear about which one is going away. The original Electron app is now legacy and is being phased out in favour of the native Swift app, and it remains in the repository root, with `main.ts`, `preload.ts` and `src/`, for now, but new development targets the Swift app. The legacy version was built with Electron 36, React 19, TypeScript 5, Tailwind CSS 3 and Radix UI, using the `ccusage` package for data integration, and it has its own build and run sequence:

git clone https://github.com/Iamshankhadeep/ccseva.git
cd ccseva
npm install
npm run build
npm start

and a `npm run electron-dev` script for hot reload development. The legacy app requires Node.js 18 or later to build and runs on macOS 10.15 or later. The presence of both is a transitional cost, and a contributor has to know which tree they are editing.

Notifications, licence and where the project stands

Two small behaviours are worth knowing before you leave the app running all day. Native notifications fire at 70 and 90 percent thresholds with a cooldown, and only when the status worsens, so you are not woken for a level you already know about. Launch at login is an optional toggle in the Settings tab, and the popover can be refreshed or the app quit from a right click. The licence is MIT, with the details in the `LICENSE` file, and the project is at version 2.0.2 with the 2.0.0, 2.0.1 and 2.0.2 tags all published on 2026-08-03, while the last push to the repository was on 2026-08-03 as well. The README closes with the sentence that frames the whole project, noting that this is an unofficial tool for tracking Claude Code usage that requires a valid Claude Code installation and configuration. It is a community tool reading a local file format, not a first-party dashboard, and the difference matters for how much you should trust the numbers.

Editorial conclusion

Adopt CCSeva if you use Claude Code on macOS and want to see token consumption, cost and how close you are to the five hour and weekly limits without opening a terminal, since the app reads your local transcripts and can show the server's own numbers. Do not adopt it if you are on Linux or Windows, because the native build requires macOS 14 or later and the legacy Electron path was also macOS only. Verify first whether you want the local estimation or the server-truth gauge, since the app falls back to local estimation when the OAuth usage endpoint is unavailable, and decide about the optional sync before enabling it, because the app stores a device credential in your macOS Keychain.

Frequently asked questions

Official sources

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