AUDR by Chargebee

AUDR (Agent Usage Detail Record) is an open standard for recording who initiated your agent runs and how much each cost, across every system a run passes through. It defines a common JSON schema that any harness, router, or billing system can emit and ingest. The goal is to help businesses make sense of the economics at the run level, giving every team building or monetizing agents a reliable record of what an agent run consumed and who or what it was associated with. It was drafted at Chargebee and is being improved with collaboration across the ecosystem, stewarded by Chargebee under the Apache 2.0 license. The problem AUDR addresses is that a run can be fully observable at every individual layer and still leave you without a single end-to-end record of who ran it and what it cost. A single agent run touches multiple systems: the application knows the customer and the feature, the router knows the tokens and the cost, and the tools know what they executed. Without a shared way to join these, usage data is orphaned from the business context that gives it meaning. The telecom industry solved a similar problem with the Call Detail Record, an open standard carriers converged on so a call's attributes could be captured and exchanged in a common format, independent of any single carrier's systems. AUDR is built on the same principle: a common record for agent runs that any harness, router, or billing system can emit and ingest. AUDR adds three core rules that let reports from different layers come together into one record. The first is a shared run ID, minted by the harness, passed to the router in request metadata, and echoed back, so every system that touches the run carries the same ID. The second is clear authority per field: the harness owns attribution such as customer, environment, and initiator, while the router owns usage such as tokens and provider. Each fact has exactly one source. This ensures that a record can carry raw counts that drive cost—tokens, tool calls, seconds of compute—alongside the business context that says whose cost it is. The record structure includes a run block with run ID and span ID, an attribution block sourced from the harness, a usage block sourced from the router, and an emitter block that identifies the component that produced the record. The third rule is strict merge rules. The sink assembles records sharing a run and span ID, and no component rewrites another's block. Conflicts are rejected, and a correction is a new record, never a mutation. This makes the record durable and reliable, and ensures that retries remain idempotent. The example in the spec shows a run with a run ID minted by the harness, attribution sourced from the harness, usage sourced from the router, and the emitter identified as the router. Because each field has exactly one authoritative source, the merged record is consistent and auditable, and any correction is preserved as a new record rather than silently overwriting history. AUDR provides adapters for runtimes you already use, so you can register an adapter and get a usage record for every model and tool call, including the customer it belongs to. Available adapters include NVIDIA NeMo Relay, LiteLLM, Merge Gateway, Vercel AI SDK, and Mastra. The core SDK builds, validates, and delivers records straight from your own code, with Python and TypeScript packages. Sinks deliver records to destinations you already use: Chargebee and Lago for usage-based billing. Adapters read identifiers, usage, and timings, never prompts or outputs. Every package is Apache 2.0 and published to PyPI or npm. The architecture is runtime → adapter → core client → sink → destination. Support for OpenRouter is in development. You can write records to a local file to start, with no account, hosted backend, or pricing configuration needed. AUDR is designed to sit on top of OpenTelemetry, not compete with it. OTel's GenAI semantic conventions provide the foundation for describing model calls and usage, and AUDR reuses them. An AUDR record can be emitted as an OTel span, and the OTel collector is a first-class sink. What OTel does not define is the set of rules needed when usage becomes a durable record: which attributes are required, how attribution is handled when it's missing, how retries remain idempotent, or how corrections are made. Observability can tolerate a dropped span, but a usage record cannot. AUDR adds those requirements and delivery semantics on top of OTel. It also complements standards like FOCUS, which standardizes billing data received from providers; AUDR standardizes the usage emitted when an agent run happens, before that usage is priced. The benefits are practical. With AUDR, you can answer questions like: How much does this agentic feature cost? What does this customer's agent usage look like, and how much does it cost? What are the unit economics and margins per customer for my agentic features? Which workflows or models are driving our costs? Which power users are driving our costs? Because records are emitted asynchronously and out of band, recording usage adds no synchronous work to inference in the normal request path. The only exception is optional pre-flight budget gating, which makes a single check before a run starts. You can store records locally, send them to a warehouse, feed them into an observability system, or use them for internal cost analysis or future projections. Use cases include usage-based billing, where records are delivered to a Chargebee site's usage-ingest batch endpoint or Lago's batch event endpoint. Teams can also use AUDR for internal cost analysis, to understand unit economics and margins, to identify which workflows or models drive costs, and to track power users. It supports cost governance by providing a common record that any system can emit and ingest. You can write records to a local file to start, with no account, hosted backend, or pricing configuration needed. For observability, the OTel collector acts as a first-class sink, and records can be used for future projections. AUDR is aimed at teams building or monetizing agents, developers, platform engineers, and billing teams. It does not assume what you do with the data after it is emitted; a billing system is just one possible consumer. It carries no prices or rating logic, and the SDK has no concept of plans, invoices, or how a customer should be charged. It records what happened and who it happened for. You can point the records at Chargebee, a competing rating engine, your own, or a warehouse for analytics. The spec is Apache 2.0, stewarded by Chargebee, and the goal is to move cost governance to an independent foundation as adoption grows. Contact is audr@chargebee.com. The three core rules are stable and will not change without a major version, while the field set will continue to grow as providers introduce new things to measure. In summary, AUDR is an open standard that provides a common language for recording agent run usage and cost across every system a run passes through. By combining a shared run ID, clear field ownership, and strict merge rules, it turns orphaned usage data into a durable, end-to-end record that supports cost analysis, usage-based billing, and agent unit economics. It is open, neutral, and community-owned, with packages published under Apache 2.0.