Compare
Kibble vs an LLM gateway vs a local usage tool
There are three ways to turn one vendor invoice into coding-agent spend per engineer, team, model and repo. They differ in what they can see, what they cost the team in privacy and setup, and whether the number they show is the one on the invoice. This page is the table; the reasoning is in the post.
What are the three options?
A local usage tool (ccusage, tokscale and the like) reads the transcripts Claude Code or Codex writes on one machine and prints that machine's tokens and estimated cost. An LLM gateway or proxy (LiteLLM, Helicone, Portkey, a homegrown one) sits between every agent and the vendor, forwards each request, and logs who asked, which model, how many tokens and, if configured, the content. Kibble runs a small open-source collector on each machine that reads the same local logs a usage tool does and sends per-day counts to one dashboard for the team, then merges in the billed figure from the organization's own Claude Console.
How do they compare?
| Question | Local usage tool | LLM gateway / proxy | Kibble |
|---|---|---|---|
| Spend per engineer, for the whole team | No, one machine at a time | Yes, if every agent is pointed at it | Yes, one dashboard |
| Per team, model and repo | Per model; repo on some | Per model; repo only if the client tags it | Per team, model and repo |
| This week against last, biggest mover named | No | Depends on the product | Yes |
| Covers CI runners and cloud boxes | No | Yes, if they are routed through it | Yes, the same package runs there |
| Sees prompts, code or diffs | Reads them locally, sends nothing | Yes, every request passes through it | No. Counts only: tokens, model names, opaque session ids, repo names |
| Changes how the agent talks to its vendor | No | Yes: base URLs, keys, an outage of the proxy is an outage of the team | No. Nothing is in the request path |
| Billed truth from the vendor | No, list-rate estimate | Its own count, not the invoice | Read from your Claude Console, merged per day, billed wins |
| What an engineer can verify | Everything, it is local | Whatever the operator says is logged | Every line of the collector on GitHub, MIT |
| Who sees what | Only the person at the keyboard | Whoever has the proxy's logs | Engineers see their own machines; owners see totals; managers see assigned teams |
| Setup per machine | Install, run it when you remember | Reconfigure every agent and CI job | npm install -g @usekibble/cli && kibble login, hourly push installs itself |
| Price | Free | Free to self-host, or a per-request fee | Free for one person; $50 a month for five people, then $10 per person |
When is a local usage tool the right answer?
When it is one person. A usage tool on the laptop is exact for that machine, sends nothing anywhere, and costs nothing. It stops being the answer at the second engineer, because the numbers live in two terminals and somebody has to keep the spreadsheet. Kibble's free plan is that tool with a memory: one person, two machines, thirty days of history, every agent.
When is an LLM gateway the right answer?
When you need every request logged, and the engineers have agreed to that. Compliance regimes that require prompt retention, or a platform team that wants to route between vendors, are gateway problems and a gateway solves them. The price is that the proxy sees content, that every agent has to be reconfigured to use it, and that its uptime becomes the team's uptime. If the question is only "what did this cost, and who spent it", a gateway is the most invasive way to get an answer.
When is Kibble the right answer?
When you want the team view without the content problem. The collector reads what the agents already wrote, sends counts, and the dashboard shows spend per engineer, team, model and repo, this week against last, with the billed figure from your own Console beside the estimate. Nothing is in the request path, nothing changes on the engineer's machine except a scheduled push, and what leaves it is a public program.
Questions
- Is Kibble a proxy or an LLM gateway?
- No. No request passes through Kibble and nothing changes in how an agent talks to its vendor. The collector reads the per-session logs Claude Code and Codex already write on the machine and sends per-day counts: token totals, model names, opaque session ids and repository names.
- What does an LLM gateway see that Kibble does not?
- Content. A gateway forwards every request, so it can log every prompt, every file the agent read and every diff it wrote. Kibble never receives any of that: its ingest schema is strict and rejects a request that carries a field it does not expect, and the collector is open source so what leaves each machine can be read line by line.
- Why not just run a local usage tool on every laptop?
- For one person that is the right answer, and Kibble's free plan is that tool with a memory. For a team it does not add up: twelve engineers means twelve terminals and a spreadsheet, nothing for CI or cloud boxes, and no billed figure to check the estimates against.
- Does Kibble replace the vendor's console?
- No, it reads it. Local rows are estimates priced at list rates; billed rows come from your organization's own Claude Console through an Admin API key you hold. Kibble merges the two per day, billed wins, and they are never summed.
Free for one person, about a minute to the first numbers.
Start free