What Is AUDR by Chargebee
AUDR stands for Agent Usage Detail Record. Drafted by Chargebee, it is an open standard for recording AI agent runs. The problem it addresses is this: a single agent run passes through multiple systems such as the application, router, and tools, and while each layer is individually observable, there is no end-to-end record that answers "whose run was it, and how much did it cost." AUDR draws on the Call Detail Record (CDR) concept from the telecommunications industry to define a unified record format for agent runs.
Core Mechanisms
According to the official site, AUDR adds three rules on top of existing reporting:
- Shared run ID: Generated by the harness, passed to the router via request metadata and returned, so that every system touching that run carries the same identifier.
- Authoritative field ownership: The harness owns attribution information (customer, environment, initiator), while the router owns usage information (tokens, provider). Each fact has exactly one source.
- Strict merge rules: Sinks assemble records by run ID and span ID. Components do not overwrite each other's fields; conflicts are rejected, and corrections appear as new records rather than in-place modifications.
Records contain the raw counts that drive cost (tokens, tool calls, compute seconds) along with business context (customer, feature, environment). The official site emphasizes that adapters only read identifiers, usage, and latency, not prompts or outputs.
Published Components
Five adapters, two sinks, and core SDKs have been announced so far, covering Python, TypeScript, or both:
- Adapters: NVIDIA NeMo Relay, LiteLLM, Merge Gateway, Vercel AI SDK, Mastra
- Sinks: Chargebee (usage batch endpoint, for usage-based billing), Lago (batch event endpoint)
- Core SDKs:
audr(Python) and@openaudr/audr(TypeScript); OpenRouter support is in development
All packages are released under the Apache 2.0 license on PyPI or npm. The official examples show that you can get started by writing to a local file (FileSink) first, with no account, hosted backend, or billing configuration required.
Use Cases
The typical questions listed on the official site include: how much does a given agent feature cost, what is a single customer's agent usage and cost, what is the unit economics and gross margin per customer, which workflows or models are driving up costs, and which heavy users are driving up costs. Beyond billing systems, records can also be stored locally, in a data warehouse, or in observability systems for internal cost analysis and forecasting.
Relationship to Other Standards
AUDR is designed to build on top of OpenTelemetry rather than replace it, reusing its GenAI semantic conventions. Records can be emitted as OTel spans, and an OTel collector is a type of sink. What AUDR adds is the required attributes, missing-attribution handling, retry idempotency, and correction semantics needed when usage becomes a persistent record. Regarding its relationship to FOCUS: FOCUS standardizes the billing data received from vendors, while AUDR standardizes the usage data emitted at the moment a run occurs. The two are complementary.
Performance and Pricing Notes
The official site states that the normal request path incurs no added latency, with records emitted asynchronously out of band. The only exception is an optional pre-run budget gating check. On pricing: AUDR itself has not published a pricing plan, and the official site explicitly states that writing to a local file requires no account or billing configuration. Whether commercial charges are involved has not been confirmed.