AUDR by Chargebee - Open standard for tracking agent run costs
by•
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.
Replies
Congrats on the launch, we created a service that has both x402 calls and non-x402 calls (mcp, api). The non-x402 calls are credit based. I'm trying to understand the advantage of using AUDR versus not using it (problem it solves for us). Thanks, in advance!!
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 love 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 can only get 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.
@dineshz Excited to be witnessing this from the trenches!
An open standard for tracking who started an agent run and what it cost across every system it touched is the kind of plumbing this space needs before billing can be trusted, and borrowing the call detail record idea is a smart frame. A shared run ID minted by the harness is the crucial part. Curious how quickly other harnesses have picked up the schema.
@karimbenkeroum 💯 - we're working with the rest of the industry to standardize agent run tracking. First thing though is to open the discussions around this topic.
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
@dineshz that answers it, the tool-call-span fallback is the part I was missing. means we don't need every vendor to adopt AUDR before it's useful, we can just wrap our own routing layer as the "calling side" and still get the rollup even when the far end has no idea AUDR exists. going to open that issue once I've mapped our handoff cases, thanks for the thorough answer
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.
Congrats on the launch, Krish, Akash, Sriram, Nikhil, and the Chargebee team. One authoritative source per field, with corrections as new records, is the right call for anything that ends up on an invoice. How should a router record failover inside one span? If a stream dies halfway on one provider and the retry lands on another, both burned tokens, so does the router mint a child span per attempt via parent_span_id, or does the harness own that split?
@genedai yes a new span is minted and the harness owns the split. The success/failure outcome is logged on `run.outcome`. The child span is minted and AUDR captures its usage and cost along with the outcome. Since even failed streams carry costs.