If you’re using multiple AI tools, the bill is usually the easy part. The hard part is figuring out which model, agent, or project burned the tokens, and whether that spend was worth it.
The fix is to track usage at the source, then roll it up by provider, model, platform, and use-case. That gives you a real cost picture, not a monthly invoice mystery.
Why multi-provider AI spend gets messy fast
Once you mix Claude Code, Codex, GitHub Copilot CLI, direct API calls, and a few wrappers in your own scripts, the same task can show up in five different places. One tool reports messages, another reports tokens, another only shows a subscription, and your actual cost is split across providers with different pricing rules.
That’s why a single dashboard is useful, but only if it starts from usage logs and token counts, not guesswork. If you want a broader market view while you compare your own spend, the State of AI page is a good companion read, and the AI Cost Index helps you see where blended pricing sits across model families.
The important thing is to separate three questions:
- What did I use?
- What did it cost at the current price for that model?
- Was it actually worth it for the task?
If you can answer those three, you can stop arguing with invoices and start making better routing decisions.
What “cost” should mean for developers
For LLMs, cost is always quoted per 1,000,000 tokens. That matters because the arithmetic is simple, but only if you keep the unit straight. The formula is:
(tokens / 1,000,000) × price_per_1M_tokens
So if a model charges $3 input per 1M tokens and you send 250,000 input tokens, the input cost is:
(250,000 / 1,000,000) × $3 = $0.75
That’s the kind of math your tracker should do automatically, because humans are bad at eyeballing token burn once context windows get large.
For comparison, here are a few current figures you can use as reference points, all quoted per 1M tokens:
| Model | Input | Output |
|---|---|---|
| gpt-4o-mini | $0.15 | $0.6 |
| deepseek-chat | $0.28 | $0.42 |
| gemini-2.5-flash | $0.3 | $2.5 |
| gpt-4o | $2.5 | $10 |
| claude-sonnet-4-5 | $3 | $15 |
| claude-opus-4-1 | $15 | $75 |
That table is already enough to explain why “the cheapest model” is the wrong question. Input-heavy workflows, output-heavy workflows, and reasoning-heavy workflows can land in very different places.
A worked example: one coding session, three models
Let’s say you ran the same coding task three times, once on each model, and the task used 400,000 input tokens and 80,000 output tokens. Here’s what that costs with the current prices.
gpt-4o
- Input: 400,000 / 1,000,000 × $2.5 = $1.00
- Output: 80,000 / 1,000,000 × $10 = $0.80
- Total: $1.80
claude-sonnet-4-5
- Input: 400,000 / 1,000,000 × $3 = $1.20
- Output: 80,000 / 1,000,000 × $15 = $1.20
- Total: $2.40
deepseek-chat
- Input: 400,000 / 1,000,000 × $0.28 = $0.112
- Output: 80,000 / 1,000,000 × $0.42 = $0.0336
- Total: $0.1456
That’s the same task, but the spend differs by more than 10x between the expensive and cheap ends of the range. If you only look at the final invoice, you miss the reason. If you track per model, you can see whether the higher-priced run bought you better output, faster completion, or fewer retries.
That’s also why a blended metric can be useful. The AI Cost Index gives you a quick market-level read, with a Frontier basket at $4.64 per 1M tokens and a Budget basket at $0.74 per 1M tokens, both blended 3:1 input:output. It’s not a substitute for your own logs, but it’s a clean way to compare where your stack sits relative to the market.
What to track if you care about real spend
Token count alone is not enough. A useful tracker should capture the parts that explain why a task got expensive or stayed cheap:
- Input tokens
- Output tokens
- Cache usage, when available
- Reasoning tokens, when available
- Latency
- Success or failure
- Provider, model, platform, and use-case
That combination is what lets you answer questions like, “Did the expensive model actually finish faster?” or “Did retries on the cheap model erase the savings?”
It also gives you a better basis for comparing model families. For example, if a workflow is mostly prompt-heavy and short on output, the input price matters more. If it produces long answers, code diffs, or step-by-step reasoning, output pricing can dominate. If cached tokens are involved, the effective cost can drop a lot, but only if you can see the cache hit pattern clearly.
If you want live model pricing instead of stale blog math, use live prices for 4,159 models. That’s the right place to check before you route a new workload or update a cost estimate.
How to track this without shipping your logs off-machine
The simplest way to start is to read the usage logs your coding agents already keep locally. Run npx mytokentracker and it prints a 30-day cost table at API prices, with usage data staying on your machine. No account is needed for that local view.
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. Only daily totals per agent and model are uploaded, never prompts, code, or file names.
It works with Claude Code, Codex, GitHub Copilot CLI, Antigravity, OpenCode, Amp, Qwen Code, and more. For wrappers, the idea is straightforward: auto-capture OpenAI, Anthropic, Gemini, and Mistral in Python with track_openai, track_anthropic, track_google, and track_mistral, or in Node with trackOpenAI and the equivalent helpers. For anything else, a single POST to the events API is enough.
That design matters because it keeps the data model consistent. Once every call becomes a normalized event, you can slice by provider, model, platform, and use-case without manually stitching together half a dozen dashboards.
How to read the numbers once you have them
When the data starts flowing, don’t just look for the lowest total. Look for patterns:
- Which agent is generating the most output tokens?
- Which model has the highest retry rate?
- Which use-case has the worst cost per success?
- Where are cached tokens actually reducing spend?
That’s where a value-for-money view helps. If you want the market-level version of that idea, the value-for-money view is useful because it pushes you toward capability per dollar, not just raw price.
Here’s a practical rule: if a cheaper model needs two or three retries to match one clean pass from a more expensive model, the “cheap” choice may not be cheap at all. The same goes for long-context workflows, where one oversized prompt can cost more than the actual task.
And if you care about the underlying data rather than the summary, the open data is what makes this kind of analysis auditable. That’s important for teams that want to build their own internal reporting or verify what a tool is claiming.
FAQ
Is token tracking useful if I already know my subscription price?
Yes. A subscription tells you what you paid the vendor, but not what each model or workflow consumed. Token tracking shows which tasks are expensive, which models are overused, and whether your usage pattern is drifting into a higher-cost zone.
Do I need to upload prompts or code to get a useful dashboard?
No. The local tracker reads the logs already on your machine, and the synced dashboard only uploads daily totals per agent and model. That’s enough to see spend trends without exposing prompts, code, or file names.
What’s the best metric for comparing AI tools?
Start with cost per successful task, then look at latency and token mix. A low token bill is not helpful if the tool fails often or takes too long. For model shopping, use per-1M-token pricing and a blended view like the AI Cost Index so you’re comparing like with like.
If you want to see your own 30-day cost table, install the tracker and let it read the logs you already have.
Run the tracker locally and see what your AI actually costs.