Kibble Blog

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

By Kibble · 29 August 2026 · 6 min read

To see Claude Code cost per engineer, start with the vendor's per-user analytics where your plan provides it. Add local usage counts when you need a shared view across Claude Code, Codex and repositories. Keep API-rate estimates separate from billed amounts. This guide compares the vendor view, local tools, gateways and a counts-only collector.

Why the invoice cannot show Claude Code cost per developer

Anthropic provides per-user Claude Code analytics, with reporting surfaces and API access that depend on the plan. Start there for a Claude-only organization. Its Usage and Cost APIs answer different questions: usage can be grouped by API key and model; cost reports provide workspace and service breakdowns. A shared key alone does not identify an engineer or repository.

For subscription seats, API-rate estimates are not the seat invoice. Check the actual plan, included usage and any extra-usage charges before treating a token total as money owed.

Kibble adds a shared Claude Code and Codex view by engineer, team, model and repository, with counts-only collection. Repository spend remains an estimate. Its value is that combined view and privacy boundary, not the absence of vendor analytics.

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.)

A local report does not by itself establish shared team identity, access control or billed reconciliation. You can build an aggregation pipeline, and community team tools exist. CI also has usage to collect when the runner retains supported logs. Compare the actual setup in ccusage for teams before deciding whether a hosted collector is useful.

For one person, ccusage may be sufficient. For a team, decide who owns collection, missing-machine checks, identity and permissions.

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           # manual push or retry; automatic collection starts at login

Each engineer installs the CLI and runs login; push is available for manual collection or a retry. 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. When automatic collection is enabled, login sends available usage immediately and schedules hourly pushes. The first sync includes today and the preceding 29 UTC days where local logs exist. If automatic collection is off, run kibble push manually.

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 laptops are estimates: tokens priced at list rates. Claude Console analytics, read with your organization's Admin API key, also reports estimated cost. Kibble prefers that vendor estimate for matching daily usage and keeps local estimates for uncovered usage. Overlapping sources are never summed; neither source establishes what your invoice charged.

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.