Token and Compute Cost Attribution per Agent Session and Developer

Coding agents began running multi-step loops instead of answering single prompts, so token and compute costs no longer behaved like a predictable line item. A chatbot session costs roughly what it looks like it costs: one question, one answer, one token count. An agent session does not work that way, because the LLM API underneath it is stateless. By the twentieth step of a loop, the agent is paying for the same system prompt and the same history twenty separate times. The dominant cost driver is what the model reads on each call, not what it writes, a ratio that runs opposite to how most engineers think about where to optimize.

The usage pattern changed, and the billing environment changed with it. For the platforms that made the switch, the era in which an organization could treat AI tooling as a predictable per-seat cost ended. Every tool call resends accumulated context, and agentic systems need governance infrastructure that tracks cost at the session level because of that non-linear consumption pattern. Platforms such as Ellipsis tag every request with its developer and trigger at the moment of execution, so you can see the cost of a twenty-step loop before the invoice arrives.

What happens when costs scale before attribution does

Without attribution at the session level, a cost overrun is visible only as a surprise on an aggregate bill, not as a traceable event an engineering team can act on. Nobody adjusted the budget because nobody had a number to adjust it against.

Retry loops make the same problem worse in a quieter way. That absence also breaks the accounting itself: developer-side agent usage belongs on R&D, production agent usage belongs on COGS, and without tagging at the moment of the request, neither can be allocated correctly. Both keep growing in ways nobody notices until month-end.

BCG's framing of the underlying productivity question shows what is actually at stake. The numerator of any ROI calculation should count code that ships and survives review; the denominator should include the full cost of getting there, specification, review, correction, testing, and approval time. That calculation is impossible without per-session cost data tied to outcomes. An organization that cannot attribute cost to a session cannot run this calculation. It cannot answer whether an AI coding agent's work is actually worth what it costs.

Attribution at the moment of the request, not after the bill arrives

The information needed to assign cost accurately, which developer triggered a session, which repository it touched, which pipeline step it ran inside, exists at the moment the request is made and nowhere else. Reconstructing it after the fact is not a matter of better reporting tools; the data required simply does not survive into the billing layer in a usable form.

Two naive fixes get tried and both fail for structural reasons. Averaging the cost across every touched repo fails in the opposite direction: it undercharges complex codebases and overcharges simple ones, and neither number gives a finance team anything it can act on.

Provider billing data does not solve this on its own. But none of the major providers offer flexible tagging for team, environment, or cost center as a built-in feature, so the raw billing data still has to be enriched before it means anything to a budget owner.

Direct attribution at the gateway layer is the working answer. Every LLM request carries mandatory metadata, developer identity, project ID, team, pipeline step, cost center, injected at the moment the request is dispatched, so the full cost of that request books to exactly one owner the instant it is incurred. Post-hoc reconciliation fails for the reason stated above: the metadata is gone by the time the invoice is generated. Production-grade agent governance systems solve this by tagging every request at the gateway with its originating developer or trigger and logging it immutably, so every tool call and every token can be attributed the instant it runs rather than reconstructed later from an aggregate number.

Proportional allocation still has a place, but a narrower one than most teams assume. For everything that can be tagged at the point of the request, direct attribution is the only approach that produces a number anyone can act on. The practical pattern most production systems converge on is a hybrid: direct attribution wherever a request can be tagged at dispatch, proportional allocation reserved for the narrow category of overhead that genuinely cannot be split that way.

The metadata a session tag must carry to be useful downstream

A session tag earns its keep only if it is defined before the session starts, not reconstructed from logs afterward. Each one exists because something specific breaks without it.

Developer or service identity separates a human engineer's exploratory session from a CI agent running on a fixed schedule, and the two have different budget owners, different risk profiles, and different ROI expectations. Anthropic already exposes spend per API key on every plan with no tagging work needed, and on Enterprise plans you can get per-email-address spend too, through a separate Analytics API. Session-level tagging builds on top of it to capture what an API key alone cannot carry: which repo, which trigger, which task.

Trigger type matters because it determines who owns the cost and what scope applies to it. A session that starts from a pull request push has a natural owner, the PR author, and a natural scope, the files that PR changes. Tagging the trigger at the start prevents misattribution in the common case where a single API key is used across multiple trigger types over the course of a day.

Repository and project scope gives the tag its shape. Claude Code already stores usage locally in per-project JSONL files, recording input tokens, output tokens, cache creation tokens, cache read tokens, model identifier, and timestamp for every session. That local-first structure is the reference implementation for what per-project attribution should look like, and a gateway-level tag should carry the same dimensions.

The budget envelope field is what makes everything else actionable. The tag has to reference the specific constraint in force for that session, a session cap, a daily cap, a developer-level cap, so that downstream enforcement logic can act on the number before tokens are consumed. How cache writes get attributed is one quieter design choice that deserves attention. Charging a cache write to the project that triggered it, instead of to whichever later session benefits from reading that cache, decides whether prompt caching is a real cost to the session that paid for the write or a hidden subsidy to every session that reads from it afterward. That choice changes what the numbers mean, and it has to be made deliberately.

Budget enforcement that acts before tokens are spent, not after

Billing alerts that fire once a threshold has been crossed arrive too late to matter. Enforcement has to sit upstream of consumption, not downstream of the bill.

The enforcement hierarchy should mirror the budget hierarchy an organization already has. Each level needs its matching field in the session tag. The tagging schema and the enforcement architecture have to be designed together from the start.

Model routing counts as enforcement in its own right. Retry loops need a separate circuit breaker: a session that fails repeatedly on a large context is the single most damaging runaway pattern available, and a breaker that detects the repeated failure and halts the loop acts on behavior, a different control from a plain session cap.

Ellipsis builds this enforcement model directly into agent configuration. The budget block in an agent's YAML sets both a per-session spend limit and a daily limit, enforced before tokens are consumed. Teams can set per-developer, per-team, or per-session limits directly in config, so if there is an overrun, it triggers an alert or a throttle before it compounds into a surprise at month-end.

Agent configuration files and auditable attribution and enforcement

A session tag that application code injects at runtime is only as trustworthy as the code that injects it: it can drift, get skipped, or be overridden by whoever has access to change the running system. A tag that instead comes from a YAML file committed to a repository and reviewed through a pull request is a different kind of object entirely: a governance artifact with a history, not a value assembled fresh at runtime and gone once the session ends.

The agents-as-code pattern applies this logic directly: agents get defined as declarative configuration files checked into the repository, which brings the same review discipline, version history, and change tracking that engineering teams already apply to infrastructure. NVIDIA's OpenShell, launched at GTC 2026, applies the same idea one layer down, using declarative YAML security policies to govern the kernel-level isolation an agent runs inside, version-controlled in repositories using the same infrastructure-as-code idioms engineers already use elsewhere.

Version control of agent configuration also makes the attribution metadata itself auditable. A team can reconstruct which budget envelope applied to any given session, who last changed it, and when, which is the evidence chain compliance work requires. When the tag originates from a committed config file instead of being assembled on the fly at runtime, rejecting untagged requests outright becomes far easier to enforce and far harder to work around than silently assigning them to a default bucket. The EU AI Act's Article 12, scheduled to reach full enforcement on December 2, 2027 for Annex III standalone high-risk systems following the Digital Omnibus delay, requires a queryable record of AI-driven decisions, including which governance policies applied at the moment of execution. A committed, versioned agent config file is the most direct way to answer that question for any specific session, since the policy in force is written down, dated, and tied to a specific commit.

What the session log must capture for usable attribution

If a tag assigns cost to an owner without a record of what the session actually did, you get accountability without understanding. Answering those questions makes an AI coding agent's work visible step by step as it happens.

The minimum useful session log captures input tokens broken into fresh, cache read, and cache write; output tokens; per-tool-call token counts; the model used at each step; session duration; the trigger source; the final outcome, whether completed, halted by a circuit breaker, halted by a budget cap, or ended in error; and the diff or artifact the session produced. Ellipsis exposes this same depth of detail as downloadable session output, with retention configurable from zero hours up to one year, and every tool call, diff, and token tied back to the session and to whichever person or trigger started it.

Cache token breakdowns earn their place in the log because they point you straight at an optimization target. Engineering leaders can also take one heavy consumer as a reference point and study that developer's session pattern closely enough to judge whether it shows efficient use or signals that something in the workflow needs attention.

If you don't carry identity through the full chain of a session, none of this holds together. That is the reason continuous session logging is not optional: the log has to carry the originating identity through every tool invocation in the chain, not just the top-level call, because the sessions most likely to produce unexpected cost are exactly the ones where that chain runs several layers deep.

Putting session attribution to work: the practical workflow for engineering teams

Session attribution becomes something a team can actually run, rather than an idea on a whiteboard, once the tagging schema, the enforcement hierarchy, the agent configuration, and the session log get designed as one connected system from the outset rather than stitched together from separate tools after costs have already run out of control.

Step one is the tagging schema. Define the mandatory fields, developer or service identity, trigger type, project scope, cost center, budget envelope, and enforce them at the gateway so that any request arriving without them gets rejected rather than defaulted silently into some catch-all bucket. This is a one-time design decision, but it pays back repeatedly: every later optimization, every audit, every ROI calculation depends on these tags being accurate from the start.

Step two is the agent configuration. The budget block sets pre-execution caps directly: a session limit that stops any single run from overrunning, a daily limit that constrains total spend across a team, and a model-tier gate that blocks calls to a premium model when the task's assigned envelope only covers a lighter one.

Step three is the enforcement gate. TrueFoundry's production implementation shows this pattern directly: hard cost budgets and separate token-based rate limits by team, application, model, user, and agent, with requests that exceed those limits blocked or rerouted at the gateway itself.

Step four is the session log.

Step five is the review loop.

Ellipsis provides managed infrastructure across this entire stack: agents defined in YAML with budget caps attached, running in isolated cloud sandboxes with credentials minted per session and revoked once the session ends, and full session logs available for download and retained according to each team's own policy. The tagging, enforcement, configuration, and logging described across these five steps exist as a single platform rather than a set of separate tools a team has to assemble and maintain on its own. A team adopting this approach can define an agent, set its budget, and run it with a complete audit trail starting from its very first session, rather than retrofitting governance onto a system that has already been running unmeasured for months.