The 5 Metrics Every AI Team Needs in Their Cost Dashboard
Total spend is the least useful number in your AI cost dashboard. Here are the five metrics that actually tell you what's happening — and what to do when any of them moves.
Why total spend is the wrong metric
"$12,000 this month" tells you almost nothing actionable. You can't tell which project caused it, which model is the problem, whether it's growing or stable, or whether it maps to any business outcome. The engineering manager who discovers a $12K AI bill at invoice time has already lost — the decisions that drove that number were made weeks ago.
The five metrics below give you earlier signals, better attribution, and faster time-to-action. They work together: anomalies that are invisible in total spend appear in one of these breakdowns within hours.
Metric 1: Cost per request by project
What it is: The average cost of a single AI API call, broken down by the internal project or feature that generated it.
Why it matters: Aggregate spend is a sum of all projects. Cost-per-request-by-project tells you which project is expensive per call and which is high-volume but cheap. Those two situations require different responses.
When it moves: A spike in cost-per-request for one project almost always means a code change: longer prompts, a model upgrade, a new system prompt, or an added retrieval step that concatenates documents. Correlate with deploy timestamps.
How to get it: Attribution requires a projectId and operation on each call. With Model Meter, these come from the SDK's init() configuration and the optional modelMeter.operation field — not a manual tagging step per call.
Metric 2: Provider spend share
What it is: The percentage of total AI spend going to each provider (OpenAI, Anthropic, Google, Groq, etc.) over time.
Why it matters: Provider share shows you which vendor is growing. A provider you thought was a small experiment can quietly become your second-largest cost driver if a new feature ships without attribution.
When it moves: A provider's share growing faster than its call volume means its average cost-per-call is increasing — often a sign that higher-tier models are being used in that integration. A sudden jump in absolute spend on a provider that wasn't active usually means a new feature went to production without cost review.
How to get it: Any cross-provider dashboard needs provider identity on every request. Proxy-based tools get this from the call path. Model Meter gets it from the OpenTelemetry gen_ai.system span attribute emitted by the Vercel AI SDK.
Metric 3: Request volume vs. cost trend
What it is: A dual-axis view of request count and total cost over time — specifically, whether they're growing at the same rate.
Why it matters: Volume and cost should track roughly together. When cost grows faster than volume, your average cost-per-request is rising. That can mean intentional model upgrades, but it can also mean a misconfiguration — a longer system prompt, a context window that isn't being truncated, or a retry loop.
When it moves: Volume flat, cost rising: cost-per-call is drifting up — investigate recent code changes. Volume rising, cost flat: you're scaling efficiently, likely due to caching or model optimizations. Both rising proportionally: normal growth.
The number to watch: Cost growth rate / volume growth rate. Anything above 1.1× (cost growing 10% faster than calls) over a week warrants investigation.
Metric 4: Error rate with cost attribution
What it is: The rate of failed or errored AI calls as a percentage of total calls, broken down by project and provider.
Why it matters: Failed API calls still consume tokens in many cases. Rate-limited requests that fire before the limit backoff, requests that time out mid-stream, and malformed requests that are rejected after tokenization all incur partial input token charges. A 3% error rate isn't just a reliability metric — it's a cost leak.
When it moves: Error rate spiking on one provider usually means rate limits or a provider incident. Errors concentrated in one project usually means a code issue — malformed prompts, missing required fields, or context that exceeds the model's context window.
The rule: Any project with >1% error rate and >$100/month spend has a meaningful cost-leak worth investigating.
Metric 5: Budget utilization by project
What it is: Current-month spend for each project expressed as a percentage of its allocated budget — updated in near real-time, not at month-end.
Why it matters: All four previous metrics are diagnostic — they tell you what's happening. Budget utilization is the control metric. It tells you how much runway you have before a project exceeds its allocation. Seeing a project at 70% budget by day 15 is actionable. Seeing it at 102% after the billing cycle closes is not.
When it moves: Fast budget consumption early in the month (>50% by day 10) on a project that isn't growing in users or features usually means a runaway process, a loop, or a dev environment accidentally pointing at production.
Prerequisites: Useful budget utilization requires per-project budgets set in advance. This is a forcing function for a conversation engineering teams often skip: "how much should this feature cost per month?"
Getting all five metrics in one place
The five metrics above require cost data attributed by project, provider, operation, and error status — in near real-time, not from a monthly invoice export.
Model Meter's SDK captures all of this from your existing Vercel AI SDK calls via OpenTelemetry instrumentation. Install the SDK, call init() with your projectId, and the dashboard surfaces cost-per-request, provider share, volume-vs-cost trend, error attribution, and budget utilization without any additional instrumentation.