CodeCost vs ccusage: from one developer’s terminal to the whole org

ccusage is a handy way to see what one machine has spent on AI coding. Once the question becomes what a whole team or company spends — live, by team and repository, and whether the month will land on budget — you need a tool built for that question. This is what CodeCost adds, and why it is the one to run your org’s AI coding spend from.

By the CodeCost team · 6 min read

Credit where it is due

ccusage is a well-made, MIT-licensed CLI. It reads the usage logs coding agents keep locally and reports tokens and estimated cost for that machine. It needs no account and sends nothing anywhere. For a developer who wants a quick look at their own usage, it does exactly that.

It also proves the premise CodeCost is built on: the session file on the developer’s machine records every session in the same shape, with no proxy and no environment variable. Where the two differ is what happens next.

What CodeCost adds

A local CLI answers one person’s question about one machine. Whoever owns an engineering budget needs six more things, and CodeCost is built for them.

1. A live total for the whole org

With a CLI, an org total means every developer running a command, exporting the output and someone merging the files — which in practice happens once, for a slide. CodeCost runs as a background agent on each Mac and forwards usage as it happens. Sessions appear in the console as they run, and the month-to-date total refreshes every ten seconds.

2. People and teams

A local log does not know who you are or which team you are on. CodeCost enrolls each Mac to a developer from an invite, and teams are managed in the console, so spend by team is a real view rather than a spreadsheet join. A developer who uses Claude Code in the morning and Codex in the afternoon is one person with one total.

3. Cost by repository, across the org

Cost is explained by codebases. CodeCost attaches the repository name — never the file path — to every event, so seeing that most of a team’s spend lands in one legacy service is a click, not a script.

4. A forecast and alerts before the overrun

A report tells you what has happened. CodeCost projects the month from its first week and alerts the budget owner when the projection crosses a threshold, while there is still time to act. A second, faster check catches a runaway session within the hour.

5. A view for every role

The CTO sees the org, a manager sees their team and nobody else’s, and a developer sees their own usage. Developers also get a budget readout in the macOS menu bar, so the personal view a CLI gives you is still there — without running a command.

6. A written privacy boundary

Once data leaves a machine, the standard has to be an exact, published list of what leaves. CodeCost sends a fixed set of metadata fields: tokens, model, timestamps, cost, session and repository identifiers, tool names. Prompts, responses, API keys, file paths and the developer’s email never leave — much safer than collecting exported reports by hand.

Side by side

Built the way developers like their tools

What makes a local CLI easy to trust is that it stays out of the way. CodeCost keeps that on purpose:

• Zero config. No workflow changes, no environment variables, no config files. The agent reads the session files your tools already write.
• Code stays local. Prompts, code and keys never leave the machine.
• Fail open. CodeCost is not on the request path. If it stops, your AI tools keep working.

Which one is right for you

If all you want is an occasional look at your own spend on your own laptop, a local CLI answers that. If you are responsible for what a team or a company spends on AI coding — or you have tried collecting CLI reports from the team and given up — CodeCost is the tool built for the job, and every developer still gets their own view in the menu bar.

For the full picture of where AI coding spend numbers live and the ways to collect them, read How to track AI coding spend across your engineering org.