Kibble Blog

How to see Claude Code cost per engineer, without reading anyone's prompts

By Nhan Duc Nguyen · 29 August 2026 · 6 min read

You rolled Claude Code out to the team in the spring. The invoice arrived in the summer. It has one number on it, and the question in the leadership meeting is "which of these is worth it?", which the invoice cannot answer. Here are the three ways to get to a per-engineer, per-repo answer, and what each one quietly asks you to give up.

Why the invoice is one number

Anthropic bills an organization. The Console can break that down by day, by workspace and by API key, and the Admin API will hand you the same report as JSON. That is billed truth and it is worth having. But an API key is not an engineer: the CI runner shares one, two people who set up on the same afternoon copied the same one, and nothing on the key says which repository the tokens went into or whether the week was heavier than the last.

If the team is on a Claude Max or Team seat instead of the API, there is not even a per-token number. There is a seat price, a usage limit, and an engineer who hit it on Thursday.

So the number you want, spend per engineer, team, model and repo, this week against last, is not in the vendor's dashboard and is not going to be. It has to be assembled from somewhere closer to the work.

Option one: a usage tool on each laptop

Claude Code writes a transcript for every session to ~/.claude/projects/, and each assistant turn in that file carries the model name and the exact token counts the API returned. Tools such as ccusage and tokscale read those files and print a daily table of tokens and an estimated cost at list price. They are open source, they run locally, and they answer the question for one person in about ten seconds. (We wrote up where those logs live and what is in them separately.)

What they do not do is add up. Twelve engineers means twelve terminals and a spreadsheet somebody has to keep, and a spreadsheet nobody keeps past the second week. There is also nothing in the files for CI, where the agent runs on a machine no engineer opens, and nothing that reconciles the estimate to what Anthropic actually charged.

It is the right answer for one person. It is not a team answer.

Option two: put a proxy in front of the model

The other common route is an LLM gateway: every agent on every machine is pointed at a proxy, the proxy forwards the request to the vendor, and on the way through it logs who asked, which model, how many tokens, and often the prompt and the completion too. Per-engineer spend falls out of the logs, plus rate limits, plus a single place to rotate keys.

The cost is the thing people underweight until an engineer asks about it. A proxy sees content. Every prompt, every file the agent read, every diff it wrote, passes through a box the company runs, and the moment that is true the tool stops being a cost report and starts being a monitoring system. Adoption of coding agents is fragile in exactly this way: an engineer who believes their prompts are being read will use the agent less, or use it from a personal account, and both of those make the number you were trying to measure wrong.

A proxy also changes how the agent talks to its vendor. Base URLs get overridden, some features do not work through a gateway, and every outage of the proxy is an outage of the whole team's tooling.

Option three: read the logs, send the counts

The third route is the one Kibble takes, and it is a compromise between the first two rather than a new idea. A small open-source collector runs on each engineer's machine, in CI, and on any cloud box that runs an agent. It reads the same transcript files the local tools read, sums them per day, per agent, per model, and pushes that summary to one dashboard. It sends token totals, model names, opaque session ids and repository names. It never sends a prompt, a file, a tool argument, a path, a hostname or a hardware id, and the server rejects any request that carries a field it was not expecting.

That gets you the team view without the proxy's content problem. The engineer keeps the guarantee they had with a local tool: what leaves the machine is counts, and they can read every line of the program that sends them. The lead gets the thing the invoice could not give them: a per-engineer, per-repo, per-model picture, with this week beside last and the biggest mover named.

Setting it up

npm install -g @usekibble/cli
kibble login          # opens a browser, links this machine to your org
kibble push           # sends today's counts now; the schedule does this hourly

Each engineer runs those three lines once. kibble login installs a background push (launchd on a Mac, cron on Linux, Task Scheduler on Windows) so nothing needs to be remembered. In CI, the same package runs with a link token after the job that used the agent. The first numbers land in about a minute.

What each role sees

• An engineer sees their own machines and nothing else, including what each one sent.
• An owner sees totals per person, team, model and repo, this week against last.
• A manager sees the teams an owner assigned to them, read-only.

Nobody sees content, because none was sent. The point of the design is that "visibility, never surveillance" is a property of the collector, checkable in its source, rather than a line in a policy.

What this route cannot do, honestly

Two things. First, the numbers from the laptops are estimates: tokens priced at list rates. The billed figure comes from your own Anthropic Console, read with an Admin API key you give Kibble, and the two are kept apart. Billed wins the day where it exists; the estimate fills the days and the seats where it does not. They are never summed, because a dashboard that adds an estimate to an invoice has a number on it that means nothing.

Second, repo attribution is a name and an estimate. The transcript records the working directory, the collector reduces that to the checkout's name (never the path) and attributes that session's tokens to it. It is good enough to tell you that the monorepo ate 60% of the week and the docs site ate 2%, and it will never reconcile to the cent, so the dashboard shows coverage and an unattributed remainder rather than pretending.

Which one

If it is just you, a local tool is enough, and Kibble's free plan is that tool with a memory. If you need every request logged for compliance and your engineers have signed up for that, a proxy is the only route that gets you content. If you need the team's spend per engineer, team, model and repo, and you would like the engineers to keep using the agent afterwards, read the logs and send the counts.