Adopt new pricing models — tiered, volume, stairstep, usage-based, flat-fee, or any custom model, without outgrowing your billing system. Trusted by 6,500+ businesses globally, including world-class companies like Zapier, CodeRabbit, Gorgias, and DeepL.
This is the 6th launch from Chargebee. View more
AUDR by Chargebee
Launching today
AUDR (Agent Usage Detail Record) is an open standard, for capturing who initiated an agent run and what it cost across every system that run touches. Inspired by the telecom industry's Call Detail Record, AUDR defines a common JSON schema that any harness, router, or billing system can emit and ingest. Three core rules make it work: a shared run ID minted by the harness, clear field ownership, and strict merge rules where conflicts are rejected and corrections are new records.
Launch Team
A very important problem to address - Most teams I talk to build their own dashboards consolidating cost data from multiple sources but still don't get a clear picture of the actual cost to serve a customer. Knowing which cohort of customers is the most (or least) profitable can help make a lot of decisions in the product/GTM.
Excited about this launch, which helps make AI consumption explainable and not just measurable.
@sukanya_kuppuswamy thanks Sukanya! That's a fine way to sum up what AUDR can enable.
@mrakashsharma framing this
Great to see this live!
@astharattan likewise! what excites you the most about this launch?
@fmerian Love the standard it is proposing, would make things much simpler for teams.
@astharattan oss ftw!!
The Call Detail Record parallel is spot on. Telecom figured out decades ago that you don't need one switch to see the whole call. Also appreciate how precisely scoped this is against what already exists - that it sits on top of OTel's Gen AI conventions rather than competing with them, and it's explicitly the upstream half of FOCUS. Excited to see where this goes, especially with more teams starting to run multi agent stacks where the fragmentation only gets worse.
@kirthika_soundararajan Thank you, that is exactly the right framing. AUDR isn't meant to replace tracing or cost reporting; rather, it provides the attribution and cost data necessary to bridge them.
The run.trace_id cleanly links each record back to OTel. Multi-agent stacks are a primary reason we built this. By having spawned agents reuse the parent run_id, the whole execution tree rolls up neatly into a single, unified run.
rejecting conflicting records seems safer than silently picking a cost. when a router reports usage before the provider's final bill arrives, how do you tie the correction back without counting the run twice?
@jeetendra_kumar2 This is exactly why we reject conflicts. Router and provider records share the same merge key (run_id + span_id), so the sink merges them into one operation instead of adding them.
If a component needs to revise its own value, it emits a correction record that references the original record_id and fully replaces it, so the run is never counted twice.
does the shared run ID handle the nested case - one agent's run calling out to a second agent on a completely different harness, where the second system doesn't know or care about AUDR? trying to figure out if that shows up as two unlinked runs or if there's a parent/child convention for that handoff. we route calls through a few different vendors at Dial and attributing cost across a handoff like that is the part I haven't seen a clean answer for yet
@galdayan Yes. A spawned agent reuses the parent's run_id and links back via parent_span_id. If the second harness has an AUDR adapter, pass the run_id and parent span across the handoff and both sides land in one run tree. If it has no adapter, the calling side records the handoff as a tool call span with that vendor's cost, so it still rolls up to the parent run. Happy to dig into your Dial setup, so feel free to open an issue on Github. https://github.com/openaudr/audr/issues