If you run more than one coding agent, the only sane way to understand your AI bill is to track usage at the agent and model level, then convert tokens into dollars with the right price per 1M tokens. Otherwise you are guessing from invoices, and invoices hide the actual workload.
The good news is that multi-agent tracking does not need to be invasive. You can read the logs your tools already keep locally, compute cost from token counts, and only sync daily totals if you want a dashboard. That gives you real visibility without shipping prompts, code, or filenames anywhere.
What multi-agent tracking actually needs to capture
A multi-agent setup is usually a mess of overlapping tools, different vendors, and slightly different logging formats. Claude Code might handle one chunk of work, Codex another, GitHub Copilot CLI a third, and a wrapper script may call raw APIs in the background. If you only look at one dashboard, you miss the rest of the picture.
The minimum useful dataset is straightforward:
- Agent or platform name, so you can separate Claude Code from Copilot CLI from custom scripts.
- Model name, so you can compare like with like.
- Input tokens, output tokens, cache tokens, and reasoning tokens when available.
- Latency and success, so you can tell whether a cheap run was actually productive.
- Daily totals, so you can roll up spend without exposing the underlying prompts.
That is enough to answer the questions that matter: which agent is burning tokens, which model is worth the premium, and whether a workflow is cost-effective or just noisy. If you want the market context around those numbers, the AI Cost Index gives you a blended view of frontier and budget pricing, while the live model prices page is where you sanity-check individual models.
Why local logs beat invoice archaeology
Most developer tools already write usage logs locally because they need them for debugging, retries, or session continuity. That is the right place to measure cost too. When you rely on invoices alone, you lose the shape of the work: one long refactor, ten tiny fix-ups, or a burst of retries can all collapse into the same monthly number.
Local tracking also avoids a common privacy trap. Prompts can contain secrets, code snippets, customer data, or just embarrassing half-finished ideas. Usage logs can stay on the machine, while the tracker only needs enough metadata to aggregate spend. For teams that care about reproducibility and auditability, that is a much better default than scraping a vendor dashboard.
The useful unit is not “how much did I pay this month,” it is “which agent, model, and use-case produced this cost.”
There is also a practical reason to keep the math close to the source. Price catalogs change, models get renamed, and different providers bill input and output differently. If you capture token counts first, you can reprice historical usage later. That makes your data resilient instead of brittle.
A worked example: one coding session, real token math
Here is a simple example using only the prices we know are current. Suppose a coding session used 120,000 input tokens and 30,000 output tokens on gpt-4o. The price is $2.5 per 1M input tokens and $10 per 1M output tokens.
The arithmetic is:
Input cost = (120,000 / 1,000,000) * 2.5 = $0.30
Output cost = (30,000 / 1,000,000) * 10 = $0.30
Total cost = $0.60Now compare that with gpt-4o-mini on the same token counts. Its price is $0.15 per 1M input tokens and $0.6 per 1M output tokens.
Input cost = (120,000 / 1,000,000) * 0.15 = $0.018
Output cost = (30,000 / 1,000,000) * 0.6 = $0.018
Total cost = $0.036Same workload, very different bill. That is why cost tracking should live at the token layer, not the invoice layer. If your workflow is mostly short prompts and short answers, a cheaper model may be plenty. If you are doing longer synthesis or code generation, the output rate starts to matter quickly.
Comparing models without fooling yourself
For multi-agent systems, the wrong comparison is “which model is cheapest.” The right comparison is “which model is cheapest for this workload, with this input/output mix, and this success rate.” A model with a low input price can still be expensive if it rambles. A model with a higher sticker price can be efficient if it finishes in fewer turns.
| Model | Input price per 1M | Output price per 1M | What it means in practice |
|---|---|---|---|
| gpt-4o-mini | $0.15 | $0.6 | Very cheap for high-volume, low-risk tasks |
| deepseek-chat | $0.28 | $0.42 | Low-cost option when you care about both sides of the exchange |
| gemini-2.5-flash | $0.3 | $2.5 | Cheap input, pricier output, watch long generations |
| claude-sonnet-4-5 | $3 | $15 | Much higher per-token cost, so use it where quality justifies it |
That table is not the whole market, but it shows the shape of the problem. If you want a broader view of value across the ecosystem, the value-for-money view is the right lens, because raw price alone does not tell you whether a model is efficient for your workload.
Also note the AI Cost Index numbers. The Frontier basket is $4.64 per 1M tokens, blended 3:1 input to output. The Budget basket is $0.74 per 1M tokens, also blended 3:1. Those are useful anchors when you want a quick read on whether your stack is living in budget territory or frontier territory.
How to structure tracking for multiple agents
The cleanest mental model is to separate collection, normalization, and reporting.
- Collect locally. Read the logs your agents already write. Do not force developers to copy and paste receipts.
- Normalize events. Convert each tool’s format into a common schema with agent, model, tokens, latency, and success.
- Reprice with a catalog. Use a daily-synced price table so historical usage can be recalculated if prices move.
- Roll up by dimensions. Aggregate by day, agent, model, provider, and use-case.
- Review outliers. Large spikes usually mean retries, a long context window, or a prompt that got too chatty.
That workflow is especially useful when you are mixing hosted models, wrappers, and custom API calls. You do not need every tool to speak the same native language. You just need a common event shape and a consistent pricing layer.
For teams that want to share numbers or build on top of them, the open data approach matters too. The underlying data is available under CC BY 4.0, which makes it easier to build internal dashboards, compare tools, or run your own analysis without being trapped in a black box.
How to track this with MyTokenTracker
The simplest way to try it is npx mytokentracker. It reads the usage logs coding agents already keep locally and prints a 30-day cost table at API prices. Usage data never leaves your machine in that mode, which is ideal if you just want a private sanity check.
If you want a dashboard, create a free account and run npx mytokentracker init. It asks for the API token, uploads history, and then syncs every 30 minutes. It works with Claude Code, Codex, GitHub Copilot CLI, Antigravity, OpenCode, Amp, Qwen Code, and more. Only daily totals per agent and model are uploaded, never prompts, code, or file names.
MyTokenTracker also supports drop-in wrappers for OpenAI, Anthropic, Gemini, and Mistral. In Python, that means helpers like track_openai, track_anthropic, track_google, and track_mistral. In Node, the equivalents are trackOpenAI and friends. If you use a different provider, a single POST to the events API is enough.
That matters because the product tracks the things developers actually need: cost, input/output/cache/reasoning tokens, latency, and success, broken down by provider, model, platform, and use-case. Actual cost is used when known, otherwise an estimate comes from a daily-synced price catalog. If you want the install details, use the install page.
FAQ
Do I need to send prompts or code to track usage?
No. The local mode reads logs already stored on your machine and prints a cost table. If you choose to sync, only daily totals per agent and model are uploaded, not prompts, code, or file names.
What if my provider is not built in?
You can still track it. The supported wrappers cover OpenAI, Anthropic, Gemini, and Mistral, and any other provider can be sent through a single POST to the events API. The important part is that the event carries the token and cost metadata you need for aggregation.
Should I optimize for the cheapest model?
Not blindly. Cost per 1M tokens is the right unit, but the best choice depends on output length, retries, latency, and whether the task actually succeeds. A slightly more expensive model can be cheaper in practice if it finishes in fewer turns.
If you want to see how your own stack compares, run the local tracker and then inspect where your tokens are really going.