AUDR by Chargebee

Product Introduction

1. Definition: AUDR (Agent Usage Detail Record) is an open-source, vendor-neutral JSON schema standard for tracking and attributing the cost and usage of AI agent runs across disparate systems. It is a technical specification for observability and monetization infrastructure.
2. Core Value Proposition: AUDR exists to solve the problem of fragmented agent cost data by providing a common, durable record format that links raw usage (tokens, tool calls) with business context (customer, feature) across an entire agent workflow, enabling accurate cost allocation, unit economics analysis, and billing.

Main Features

1. Shared Run ID & Span ID: The core mechanism for correlating data. The initial system (harness) generates a unique run_id and passes it through the entire agent execution chain (e.g., via request metadata). Each component also generates a span_id for its specific operation. This creates a traceable lineage for every unit of work.
2. Clear Field Ownership & Schema: The specification defines a strict JSON schema where specific fields are owned by specific system components. For example, the attribution block (customer_id, environment) is owned by the application harness, while the usage block (input_tokens, model) is owned by the LLM router. This prevents conflicts and ensures data integrity.
3. Strict, Idempotent Merge Rules: A downstream "sink" system (like a billing engine or data warehouse) assembles complete records by merging partial records that share the same run_id and span_id. The rules reject merges with conflicting data for the same field, ensuring no silent overwrites. Corrections are handled by emitting a new, corrected record, preserving an audit trail.

Problems Solved

1. Pain Point: "Orphaned Usage Data." In modern AI stacks, a single agent run traverses multiple independent systems (app, router, tool servers). Each system logs its own metrics, but there is no reliable, standardized way to join these logs post-hoc to answer fundamental questions like "How much did this specific customer's agent run cost?" or "What is the profit margin for this agentic feature?"
2. Target Audience: Engineering and product teams building or monetizing AI agent applications; Platform engineers responsible for AI infrastructure cost governance; FinOps professionals managing cloud and AI spend; Billing and pricing strategists for AI-powered SaaS products.
3. Use Cases: Precise cost-per-customer calculation for usage-based billing of AI features; Internal unit economics analysis to determine feature profitability; Identifying cost-driving workflows or models for optimization; Auditing and reconciling LLM provider invoices against actual application usage.

Unique Advantages

1. Strengths & Limitations (Pros & Cons):

   • Pros: Vendor-Neutral & Open Standard (Apache 2.0): Not tied to Chargebee's commercial products. Asynchronous & Low-Latency: Emission does not block the inference request path. Complementary to Existing Tools: Designed to work atop OpenTelemetry and alongside standards like FOCUS. Clear Data Governance: Field ownership rules eliminate ambiguity in data provenance.
   • Cons: Early Adoption Phase: The ecosystem of native adapters is currently limited (primarily NeMo Relay). Implementation Overhead: Requires integration at multiple points (harness, router) in an application stack. Schema Evolution: While core rules are stable, the field schema will evolve, requiring maintainers to stay updated.

2. Key Alternatives & Differentiation:

   • OpenTelemetry GenAI SemConv: OTel provides foundational semantic conventions for instrumenting LLM calls. Differentiation: AUDR adds the rigorous rules, required fields, and delivery semantics needed for durable billing records, which OTel's observability-focused spans lack. AUDR can be emitted as OTel spans.
   • FOCUS (FinOps Open Cost & Usage Specification): FOCUS standardizes cost data from cloud providers. Differentiation: AUDR standardizes usage data from your application before it is priced. They are complementary: AUDR records can be rated and mapped into FOCUS cost reports.
   • Proprietary Vendor SDKs: Billing platforms often provide custom SDKs for tracking usage. Differentiation: AUDR is an open standard. It locks you into a universal schema, not a specific vendor's ecosystem, allowing you to switch billing backends or use the data for multiple purposes (analytics, billing, cost control).

Frequently Asked Questions (FAQ)

1. Is AUDR a Chargebee product? No, AUDR is an open standard stewarded by Chargebee but published under the Apache 2.0 license. The specification and SDKs contain no proprietary Chargebee logic, pricing, or concepts, ensuring it remains a vendor-neutral format for the community.
2. How does AUDR impact my application's performance and latency? In normal operation, AUDR has zero latency impact on inference. Records are emitted asynchronously after the request is complete. The only potential synchronous operation is an optional pre-flight budget check, which would add one external API call before a run starts.
3. Can I use AUDR without a billing system like Chargebee? Absolutely. The AUDR records are simply structured JSON logs. You can write them to files, stream them to a data warehouse (Snowflake, BigQuery), ingest them into an observability platform (Datadog, Grafana), or use them for internal cost analysis, without ever involving a commercial billing system.
4. Is the AUDR specification stable for production use? Yes, the three core architectural rules (shared Run ID, field ownership, strict merge) are stable and will not change without a major version. The field schema will expand to cover new LLM provider features and tool types, but this additive evolution will not break existing, compliant implementations.
5. Which AI frameworks and routers are supported by AUDR? Currently, a production-ready adapter exists for NVIDIA NeMo Relay. Adapters for LiteLLM, Vercel AI SDK, and OpenRouter are in active development. The open-source SDK is designed for other communities to build conformant adapters for their stack.