Agent Cost Metrics: Per-Task, Per-User Framework 2026

Agent cost metrics are the operational backbone of any business shipping agentic features at scale. Without per-task, per-user, per-tenant attribution, token spend stays invisible until the quarterly bill arrives — at which point the user behavior is set, the margin damage is done, and the retrofit is painful. This framework is the prevention.

The pattern that keeps repeating across production deployments is simple. A team ships an agentic feature on a flat seat price, the top 5% of users consume 60% of inference budget, one feature silently absorbs the majority of spend for a minority of usage, and the unit-economics model collapses by month three. Every one of those problems is invisible without the right metrics — and every one is trivial to manage with them.

This guide is the eight-KPI cost panel we ship on AI transformation engagements when an agentic feature moves from beta to general availability. Per-task cost. Per-user cost. Per-tenant attribution. Tier budgets. Overage routing. Dashboard cadence. Each KPI with a formula, a target band, and the production failure pattern it surfaces.

The default state of a newly-shipped agentic feature is invisible. A user opens the chat surface, the agent fans out into three tool calls and a reasoning trace, and the meter spins — but the meter is a single line item on the monthly provider invoice. By the time finance asks why the AI line just doubled, the answer requires archaeology rather than a dashboard query.

The cost panel below replaces archaeology with attribution. Tag every model invocation at the SDK call site with three fields — feature, user, tenant — and the next time the bill spikes, the answer is one dashboard query away. The optimization passes that follow stop being guesswork. The pricing-page conversations stop being arguments.

There is a counter-argument worth taking seriously: that cost metrics add operational overhead and the agentic feature is fine without them. The evidence from the deployments behind this framework is the opposite. The telemetry layer pays for itself the first time it identifies a single feature consuming 60% of inference budget for 8% of usage. The pay-back window is typically measured in weeks, not quarters.

Eight KPIs make the panel. Per-task cost (§02). Per-user cost (§03). Per-tenant cost (§04). Tier-budget utilization (§05). Overage rate by tier (§06). Soft-cap degradation rate (§06). Top-feature concentration ratio. Cost-to-revenue ratio at the product level. Each one earns its place — drop any and the panel has a hole. The eight together produce the picture finance, product, and engineering can argue from.

Per-task cost is the foundational metric. Every model invocation costs a measurable amount of money; the question is which task it served. Three workload classes cover the space — single-turn chat, multi-step agent workflows, and retrieval-augmented turns. Each has a different cost structure and a different optimization lever.

The headline formula is the same one we use for tier sizing in the companion token-budget calculator — tokens = sessions × turns × (input + output × multiplier) — but applied per-task rather than per-user. Tag the workload class at the SDK call site and the panel resolves automatically.

The reason to split workload classes is that the optimization lever for each is different. Chat-heavy features benefit most from model routing (Sonnet to Haiku on routine turns); agent workflows benefit most from tool-call depth caps and reasoning-trace budgets; RAG turns benefit most from chunk-size and retrieval-quality work. A single per-task average masks all three patterns.

One trap to avoid: do not normalize per-task cost against user-visible turns alone. A multi-step agent may consume the model five times for a single user turn. The denominator that matters is the count of model invocations, not the count of UI interactions — otherwise the numbers undercount the most expensive workload class by a factor of two or three.

Per-user cost is the second metric the panel surfaces. The distribution of spend across users follows the standard power-law shape — top 5% account for 50 to 70% of feature-level cost, median user is within an order of magnitude of the bottom decile. Without per-user telemetry, that distribution stays invisible and the soft-cap pattern in §06 has nothing to act on.

Three aggregations are the floor. Total monthly spend per user. Spend trajectory (today vs the trailing 30-day median). Top-decile concentration ratio (what fraction of spend is concentrated in the top 10% of users). Together they answer the operational questions account managers and finance both ask — who are the heavy users, are they trending up, and how skewed is the distribution.

One operational note. Per-user cost telemetry must respect the customer-data boundary your product already enforces. For consumer products with strong privacy commitments, store the user_id as a hashed equivalent in the telemetry pipeline and keep the linking table inside the application database, not in the analytics warehouse. The aggregations work the same; the privacy posture stays intact.

For B2B SaaS, the user is not the unit of economic analysis — the workspace, account, or tenant is. A Team plan with twenty seats renews against workspace-level value, not against the heaviest individual user inside it. Per-tenant cost rollups answer the questions account managers actually ask, and they make the renewal-conversation math defensible rather than anecdotal.

The pattern that recurs across deployments: pool the per-user telemetry from §03 by tenant_id at the warehouse level, surface tenant-level dashboards to account managers and finance, and gate tenant-level overage alerts on workspace-admin email rather than individual user inbox. The mechanic is straightforward; the organizational discipline is harder than the engineering.

The cost-to-ARR metric deserves the most operational attention, because it is the one that translates directly into commercial decisions. A workspace running at 15% cost-to-ARR is not a crisis, but it is a quarterly check-in. A workspace running at 25% is a scheduled conversation at renewal — either expanding the contract value to absorb the actual usage, capping the agentic feature with tighter overage governance, or routing the workspace's heaviest workload to a budget model under contract amendment.

One trap to avoid: do not let per-tenant cost rollups drive individual-customer pricing rates. The right response to a single workspace running heavy is to renegotiate the contracted pool at the next renewal cycle — not to issue a one-off rate concession or an off-list overage rate mid-quarter. Personalized inference pricing is a sales-engineering anti-pattern that poisons the tier model and creates conversations that cannot be repeated at scale.

Four tier patterns cover the space of most SaaS products with an agentic feature: free, pro, team, enterprise. Each carries a different budget shape — different hard ceiling, different soft threshold, different model-tier policy, different overage pattern. The combination is what makes the tier model defensible against real user behavior rather than against an idealized average.

The bands below are calibrated to the production deployments behind this framework. Absolute numbers vary by product and workload class; the relative shape — order-of-magnitude jumps between tiers, soft-threshold at 70% of hard-cap, model-tier policy that escalates with the plan — is consistent across successful deployments.

The free-tier band is the hardest calibration decision. Too tight and the feature feels broken to evaluators; too loose and free users drain the budget that paid users are funding. The 50k ceiling on a Haiku-tier model is the floor we see working in practice — it funds roughly a week of real use, enough for an evaluator to genuinely see the product's value, not enough for indefinite daily chat-heavy use. Tighter than 25k and the feature feels constrained; looser than 100k and the free-tier conversion math stops working.

The pro-tier band is sized against the median-user formula from §02 with a 3× headroom multiple. If the median pro user generates roughly 160k effective tokens per month in real usage, the 500k hard-cap accommodates roughly 3× the median — which catches the 90th-percentile user without throttling them. The soft-threshold at 350k is the alert trigger; the degradation pattern in §06 takes over from there.

One operational detail worth surfacing. The tier-budget metric on the dashboard should display two numbers — actual utilization and projected utilization at month-end based on current pace. A user at 70% utilization on day three of the month is on a different trajectory than a user at 70% on day twenty-eight; the in-product alert copy and the dashboard view should reflect the pace, not just the absolute counter. "Projected to hit cap on the 14th" is more actionable than "at 70% of monthly budget".

Three patterns cover the space of what to do when a user or workspace hits the budget ceiling. Pick one per tier; never mix two patterns on the same tier — the customer will not understand which one applies, and the support burden of explaining a mixed-mode overage rule outweighs any flexibility it adds. The production defaults that recur across deployments: hard-cap on free, soft-cap-with-degradation on pro, pay-as-you-go on team and enterprise.

The companion token-budget calculator post walks the mechanics of each pattern in detail. The metric this section surfaces is the routing rate itself — what percentage of traffic on each tier is hitting which overage pattern — because the routing rate is the primary feedback signal on whether the tier ceilings are correctly calibrated.

Two operational details on the overage metrics. First, the routing rates should be displayed alongside the absolute spend view, not separately — the question "is our routing healthy" is meaningless without the context of how much spend is moving through each pattern. Second, the routing rate per tier should trigger an alert at the daily level if it crosses the band — a free-tier hard-cap rate above 25% for three consecutive days is a tier-design problem, not a transient anomaly, and the dashboard should flag it before the support queue does.

One additional metric worth surfacing on the panel: the conversion rate from each overage event to a tier upgrade. Hard-cap activations should convert to upgrades at 8 to 15% within thirty days on a well-designed free tier; soft-cap-degradation events should generate upgrade-to-team conversions at 5 to 10% on pro; PAYG overage at the workspace level should generate pool-expansion renewals at 30 to 50% at the next contract cycle. The conversion rates are the proof that the overage patterns are doing the commercial work they were designed for.

A cost panel without a review cadence becomes a dashboard nobody opens. Three rhythms cover the audiences that need different views of the same telemetry: a daily engineering rhythm focused on anomalies, a weekly product-and-finance rhythm focused on distribution and trajectory, and a quarterly strategic rhythm focused on tier redesign and contract cycles.

The daily rhythm is the load-bearing one. At scale, the cost-anomaly signal — a single user, feature, or workspace spending 5× their trailing-7-day average — is most useful when it is investigated within hours rather than days. The daily review is a fifteen-minute scan of the anomaly view by an on-call engineer; most days nothing is actionable, but the days something is actionable are the days the panel earns its keep.

The telemetry stack that hosts the panel matters less than the review cadence that wraps it. Most agent-observability platforms — LangFuse, Helicone, the observability stack we covered in the observability stack TCO calculator — produce the eight KPIs out of the box once the SDK call sites are tagged. The choice between platforms is a tradeoff on ingestion cost, self-hosting effort, and dashboard ergonomics. The choice that matters for cost outcomes is whether the daily, weekly, and quarterly rhythms are scheduled on calendars and attended by the right audiences.

One trap to avoid: do not let the daily rhythm devolve into a cost-only firefighting view. The anomaly signal is most valuable when it is read alongside the engagement signal — a user spending 10× the median for a week is a hot-spot to investigate, but the same user generating a 30× retention lift on the feature is a customer to protect, not a customer to throttle. The cost panel does not replace product judgment; it gives product judgment a real argument to work from.