Token Budget Tracking and Cost Attribution for Agent Runs

Token budget tracking for agents is an architectural problem. A single run can spend across models, tools, retries, and subagents, so meaningful control requires costs to remain attached to that run throughout execution. Attribution must begin at the model call and reach the runtime controls that can stop further spending.

Why agent token costs defy standard infrastructure cost models

A containerized microservice or fixed-price API call can be capacity-planned against a defined workload. An agent chooses how much work to perform. It reasons, calls tools, re-reads accumulated context, and retries, potentially spending tokens dozens of times on one task. Prefactor’s token usage guide describes the multiplier behind this behavior. A small per-step inefficiency compounds across a fleet, making one task cost many times a single chat completion.

Coordinators spend tokens routing work to subagents and can consume a large share of the budget, separate from the workers producing visible results. Nor does a task have a reliably fixed execution path. The same task can vary by a large multiple in token consumption across runs without a strong correlation to output quality. Task descriptions and the agent’s own spending estimates therefore cannot serve as dependable budgets.

What the Uber and Microsoft overruns actually show

Uber used up its entire 2026 AI budget by April after Anthropic’s Claude Code spread across roughly 5,000 engineers faster than its finance models had predicted. CTO Praveen Neppalli Naga described the company as back to the drawing board on its assumptions. Heavy users were spending hundreds to thousands of dollars per month on agentic tools. Adoption had outpaced the budget model. Uber then set monthly limits for each employee’s use of agentic coding tools, tracking Claude Code and Cursor separately.

Microsoft’s Experiences & Devices division cancelled its Claude Code licences after costs escalated faster than budget projections anticipated. That differs from exhausting an annual budget. Both cases still show how hard it is to control agents’ changing usage with forecasts of how many people will use them. Knowing who has access does not explain which tasks justify the resulting spend.

Uber’s response also included prompt caching, smarter model defaults, and usage dashboards. The number of employees using frontier AI tools has since quadrupled while per-token costs fell. Its COO’s question about whether spending was visibly linked to consumer-facing output identifies the deeper governance gap. The missing connection was between consumption and useful work.

What runaway loops reveal about where attribution must live

Scale is not the only route to an overrun. An autonomous agent at SaaSNext entered a recursive tool-call loop with unlimited access to the model API and no circuit breaker. The agent repeatedly generated work for itself. A separate market research pipeline using LangChain agents coordinating through the A2A protocol entered an agent-to-agent feedback loop.

In both cases, the billing dashboard sat outside the runtime issuing calls. It could reveal spending but could not interrupt it. Prefactor identifies unusually high per-session token consumption as an early observable signal of a loop, provided session counts exist. Acting on that signal requires enforcement inside the runtime that issues tool calls. A control that permits another loop after the budget limit has been reached cannot reliably contain the failure.

What meaningful attribution actually requires you to track

Attribution attaches each model call to the agent, team, task, and user responsible for it. These dimensions form a chain. A user initiates a task, an agent handles it, and a team owns the agent. Keeping that chain intact links each token charge to a business outcome as well as to an account.

Token counts need their own breakdown because input, output, cached, and reasoning tokens can have different prices on the same model. Database queries, search APIs, and code execution should be assigned to the agent and task that initiated them instead of disappearing into infrastructure overhead. Prefactor’s cost attribution guide also includes escalation volume and resolution time, making human review visible as part of the work.

EmperorClaw’s cost tracking guide distinguishes reported costs supplied by the runtime from estimated costs calculated using a model price table. It separately identifies unpriced usage for which no usable price exists. Unknown does not mean free. Preserving that distinction prevents incomplete pricing from masquerading as a low-cost run.

Why native platform dashboards are not enough for run-level attribution

OpenAI’s usage dashboard provides total token consumption, monthly spend projections, and model breakdowns, with attribution by user, project, and API key. It does not support custom tags, environment labels, or workflow identifiers. Investigating a feature or agent spike therefore requires application logs outside the dashboard. The account view remains useful but incomplete.

Claude Code’s /usage command shows the session’s token counts and estimated cost, while Claude for Enterprise has dashboards and exports for chargeback that show how much each developer spends. Anthropic’s Admin Usage and Cost API also tracks how much is used across models, workspaces, and API keys. These tools answer legitimate administrative questions. However, provider billing does not preserve the full relationship among a customer, an agent run, and its individual steps, particularly when execution crosses providers.

How the three tool layers divide the attribution problem

Gateways sit between application code and model providers, where they can count tokens, apply budgets, route requests, and cache responses. Their natural unit is the request. They cannot infer that separate requests belong to one run, or identify subagents and retries, unless the application supplies that structure through tags. This position makes gateways suitable for centralized request admission and spending controls.

Tracing platforms instrument agent code and record model calls as spans nested within a run trace. They calculate costs per span and roll them up. Billing and FinOps tools instead reconcile provider invoices against the wider cloud bill, but cannot recover run context that providers have already aggregated away.

The practical choice follows the question being asked. A gateway can refuse a request. A tracing platform can explain a run. A billing tool can reconcile an invoice. Teams that need both spending limits and an explanation of what happened in a run should use a gateway with tracing. Neither layer replaces financial reconciliation across a mixed cloud estate.

Comparing the gateway and tracing tools available in 2026

LiteLLM is an open-source proxy and Python SDK with an OpenAI-compatible interface across providers. It records spend by virtual key, user, and team, and supports budgets that reject requests after a key reaches its limit. Requests remain separate records, however. A run making six calls appears as six rows unless a tracing backend supplies the relationship.

Helicone is an open-source proxy with a hosted version that logs requests and responses, calculates costs from a price table, and offers caching and rate limiting. It groups costs by model, user, and custom properties supplied through request headers. Session headers can join requests into sessions. Its run-level structure therefore depends on the headers the application provides.

Laminar is an open-source observability platform built natively on a telemetry framework, with cost tracking enabled for auto-instrumented providers and frameworks. Its spans record input, output, cache-read, cache-write, and reasoning tokens at their respective rates. Costs add up through traces and sessions, even when runs span subagents and providers. That automatic coverage is bounded by the providers and frameworks it instruments, and tracing does not replace request admission controls.

Langfuse has both tracing and evaluation, and its documentation explains how to instrument model calls and set up reported usage. LangSmith supplies tracing within the LangChain ecosystem, while Datadog Agent Observability places agent tracing within a broader observability suite. Braintrust Pro is another option with a higher monthly cost in the supplied comparison. These descriptions do not establish equivalent step-level attribution for every product. Databricks Unity AI Gateway is identified as a native cost attribution option, but the available detail does not establish its individual-run breakdown.

Prefactor’s SDKs capture input and output tokens, inputs, outputs, and tool calls within runs. Its judges assess runs using criteria based on a company’s knowledge and context, so cost can be seen alongside how well the task was done. Bigeye’s Agent Trust Hub shows costs for each agent, user, and conversation. Those are useful attribution dimensions, but conversation-level visibility alone does not establish a step-by-step run view. The selection criterion remains whether the tool preserves the user, run, and step relationships the application needs.

Building attribution into the agent architecture from the start

For a team preparing its first deployment, the implementation requirement is to tag model calls at the SDK call site. Every call should have the agent ID, team, task type, and run ID. Context lost there may not be recoverable later. Reconstructing ownership after a spending spike means working backward from records that may never have captured the necessary relationships.

Tag design should distinguish stable alerting dimensions from investigation identifiers. Low-cardinality fields such as feature, deployment, and prompt version support baseline comparisons. High-cardinality fields such as user ID and agent run ID support drill-down into a particular spike. A “pr-review” feature can therefore trigger an alert, while the run ID identifies the execution behind it.

The accounting record should keep input and output tokens separate, along with how long the run took, its outcome, and its tool use. Teams must use the same currency, reporting period, and cost basis before adding up totals across teams or agents. A gateway can inject tags and capture response metadata automatically. However, the tracing layer must receive those tags too, so request-level observations remain attached to the execution that generated them.

Turning attribution data into chargeback and governance policies

Chargeback makes each business unit pay for the resources its agents use, while showback shows those costs without charging the unit. Both depend on the same attribution foundation. If finance’s expense-processing agent and HR’s onboarding agent share infrastructure, costs should be split based on how much each uses. Otherwise, internal accounting obscures the behavior it is supposed to influence.

That ownership must translate into enforceable policies. A daily token budget for an agent or a monthly spending limit for a team gives the runtime a concrete boundary. Quarterly aspirations do not. GitHub Copilot’s move to token-based billing in June 2026 reinforces the mismatch between consumption-based workloads and seat-based governance. An agent’s access entitlement does not describe how much work it will initiate.

Anomaly detection complements those fixed limits by identifying changes that remain within a budget but deserve investigation. Examples include an agent consuming many times its normal tokens, a new agent accumulating significant costs immediately, or team costs growing faster than usage. These patterns can indicate loops, bugs, or misconfiguration. Attribution identifies the responsible execution and owner, turning an unexplained bill into a governable event.

Enforcement mechanisms that can actually stop a run

A runtime kill switch makes budget policy operational. It should watch token consumption, tool-call count, retry count, and span depth, stopping execution before another loop once a limit is crossed. Agent-level budgets should throttle or block further model calls until the budget resets or is manually increased. A dashboard alert cannot provide that guarantee because it waits for a human response.

Separate counters guard against different ways a run can get out of control. One production design uses turns per session, turns per task, repair rounds, and a wall-clock timeout, regardless of what the agent reports. Per-session and per-turn envelopes can also express strict, moderate, and relaxed operating limits. Turn-based limits stay the same when model prices change, while monetary budgets still control spending.

Routing and caching reduce normal consumption but serve a different purpose. Prefactor recommends smaller models for simple classification and more capable models for tasks requiring them. ProjectDiscovery’s Neo agent reused more of its cache and cut its total cost by moving dynamic variables to the prompt’s tail while keeping the static prefix. Neither optimization substitutes for stopping a malfunctioning run.

The same execution record can show cost per resolved ticket as well as raw token spend. Outcome metrics require the costs and results of each run to remain connected.