Open-source AI billing delegation standard — thought this might be relevant to anyone building agent products with Archon

[MJohnstonAI]

Hi Cole,
I've been following Archon's approach to giving AI coding agents structured context and task management — really solid infrastructure thinking.

I wanted to share something adjacent that your audience might find relevant. Most developers building consumer-facing AI agents eventually hit the same wall: who pays for the inference? Right now it's absorb the cost yourself, force users into BYOK, or build a custom credit/quota system from scratch.

I've developed an open-source proposal called the Artificial Intelligence Billing Delegation Standard (ABDS) — an OAuth 2.0 profile that lets a user authorize bounded AI usage directly against their own provider subscription, enforced server-side by the provider rather than the developer building that infrastructure themselves.
Spec: github.com/MJohnstonAI/ai-billing-delegation

Given how much of your content is about making AI agent development practical and repeatable, I thought this might resonate — either as something worth a video, or just genuinely useful context as you think about how Archon-built agents handle cost at scale.
Either way, happy to hear your take if you have time to look at the architecture.

Marc Johnston
Founder, NeuroSync AI Dynamics

[richardchen874-sys]

The AI billing-delegation standard plus BYOK versus custom credit/quota infrastructure should be grouped by user, workflow, and model tier early, because those are the levers teams actually use to reduce spend.

A useful shape would be one usage event per model call, with provider/model, feature name, token fields, retry count, latency, and billing bucket all attached. Then cost can be traced back to product behavior instead of guessed from invoices.

I am working through similar issues while testing an OpenAI-compatible layer for official Chinese models, mainly around routing, cost visibility, and response-shape compatibility. In this case, is the main pain attribution by user/workspace, or just understanding which agent steps are consuming the most tokens?

[richardchen874-sys]

@MJohnstonAI That hierarchy is the right shape, and I would represent it with stable IDs rather than copying user/workspace/app objects into every event. One run-level reservation can then have append-only child events for agent steps, model calls, retries, and fallbacks, followed by a settlement record. That avoids double charging while preserving failed attempts for audit.

A standalone USAGE_EVENT_SCHEMA.md would make the v0.4 reservation/settlement work easier to review. At minimum, it should define correlation IDs, event ordering/idempotency, estimated-versus-provider-reported usage, pricing snapshots, reservation state, and how late or corrected usage is reconciled.

The OpenAI Support concerns reinforce the same boundary. A delegated grant needs an explicit spend ceiling, expiry, application/workload binding, and a consent receipt; each execution token needs a unique identifier and replay protection. High-volume traffic should remain attributable to both the delegated principal and the application that generated it, rather than making an individual user appear to be the sole source.

For provider-side evidence, are you leaning toward usage events signed by the provider, or gateway-attested events reconciled against the provider invoice?

[MJohnstonAI]

Hi Richard,

Thank you. Your latest comments align closely with the direction the repository has now taken.

Since my previous reply, the canonical draft has moved to v0.5. It now includes USAGE_ATTRIBUTION.md, RESERVATION_SETTLEMENT.md, separate Usage Event and Ledger Event JSON Schemas, machine-readable examples, and automated validation.

The current model uses stable references such as delegation_id, client_id, request_id, attempt_id, reservation_id, trace_id, and span_id, rather than copying user, workspace, or application objects into every event. Each physical attempt is recorded separately, while an idempotent settlement finalizes the reservation and references the relevant Usage Events.

I agree that the next important layer is formal evidence and consent receipts.

On your question, I am leaning toward a two-level model:

1. Provider-signed Usage Events or settlement receipts as the authoritative provider-native model.
2. Gateway-attested provisional events, reconciled against provider-reported usage or billing exports, as a transitional model for current APIs.

A gateway-attested event should not be presented as equivalent to authoritative provider evidence. It can establish what the gateway observed, but final settlement should be reconciled against provider records wherever those are available.

For high-volume systems, the provider would not necessarily need to sign every event individually. It could sign a batch manifest or Merkle root, with each event carrying sufficient information to verify its inclusion in the signed batch.

I also agree that the schema should distinguish between estimated, gateway-observed, provider-reported, reconciled, and corrected usage. Late or corrected usage should result in an appended reconciliation or adjustment event rather than rewriting the original record.

The next development area should therefore cover:

• evidence source and evidence status;
• provider request and event identifiers;
• event sequence and causal ordering;
• provider signatures or batch-verification proofs;
• reconciliation states and variance handling;
• explicit, versioned consent receipts;
• grant, Client, Beneficiary, workload, spend-ceiling, and expiry binding;
• unique execution-token identifiers and replay protection.

I also agree that high-volume traffic must remain attributable to both the delegated principal and the registered Client or workload. An individual user should not appear to be the sole source of traffic caused by application retry policies, routing decisions, fallback logic, or agent loops.

This may form the basis of a future v0.6 Evidence, Consent and Reconciliation profile.

I should mention that my available development time is currently limited because I am also working to migrate two mobile applications to the Google Play Store. This is one of the reasons I made ABDS an open-source project: I would like the proposal to benefit from practical review, experimentation, and contributions from developers with relevant experience.

Your feedback has already been extremely valuable, and you would be very welcome to open issues, propose refinements, or contribute directly to the repository where you see opportunities to strengthen the model. I may not always be able to respond or implement changes immediately, but I will continue reviewing substantive contributions as time permits.

Regards,
Marc

[richardchen874-sys]

@MJohnstonAI Moving ABDS to v0.5 while also migrating two mobile applications to Google Play is a substantial amount of parallel work. The separation between authoritative provider evidence and gateway-attested provisional events is a meaningful step forward, especially because it avoids presenting gateway observation as stronger evidence than it is.

The most useful role for NovaRouteAI here would be a bounded provider-side example rather than a broad rewrite of v0.6: one request with a fallback attempt, gateway-attested usage events, provider-reported usage, a versioned price snapshot, and an appended reconciliation result. That would test the evidence-source, evidence-status, and adjustment semantics against a real OpenAI-compatible multi-model route.

Would that be more useful as a focused issue with one machine-readable example, or as a PR adding the example beside the current Usage Event and Ledger Event schemas?

[MJohnstonAI]

Hi Richard,

Yes, I am still relatively new to mobile application development, and this is my first time taking applications through the Google Play Store publishing process.

As a self-funded startup founder, I am currently covering the company’s operating expenses from my salary. Getting these applications launched and generating revenue is therefore an immediate priority: their success will largely determine whether I can leave my current employment and work full-time on NeuroSync AI Dynamics as a solo entrepreneur.

That is why my available time for ABDS is limited at present, even though I remain committed to its development. It is also one of the reasons I made ABDS open source—I would be very grateful for experienced developers such as yourself to test the proposal, challenge its assumptions, and contribute focused implementations where you see value.

Your proposed NovaRouteAI example would be a particularly meaningful contribution because it would provide practical implementation evidence without requiring a broad rewrite of the project.

One small update: the canonical repository has now moved to v0.6, with v0.5 preserved as the underlying usage-attribution and reservation/settlement foundation. The main additions in v0.6 are Consent Receipts, evidence provenance, scoped event ordering, and append-only reconciliation.

I agree that NovaRouteAI would be most valuable as a bounded provider-side implementation example, rather than as a broader rewrite of the specification or schemas.

My preference would be:

1. open a focused issue first to confirm the event relationships and example scope; and
2. follow it with a small PR containing the machine-readable example and only the minimum supporting updates.

A suitable scope would be one logical request showing:

• the registered Client and delegated principal;
• a run- or request-level reservation;
• a primary model attempt and fallback attempt;
• one Usage Event for each physical attempt;
• gateway-attested provisional usage;
• later Provider-reported usage;
• the requested and resolved model or route;
• a versioned pricing snapshot;
• evidence source and evidence status;
• one idempotent settlement;
• an appended Re or request-level reservation;
• a primary model attempt and fallback attempt;
• one Usage Event for each physical attempt;
• gateway-attested conciliation Event;
• a compensating Ledger adjustment where the final Provider quantity differs;
• no silent change of funding bucket or payer.

The PR could add something such as:
examples/novarouteai-fallback-reconciliation.json
along with:
[ ] a short entry in EXAMPLES.md;
[ ] any necessary validator coverage; and
[ ] no schema changes unless the example exposes a specific interoperability gap.

It would also be important to keep the example safe for publication: no API keys, raw prompts, customer identifiers, confidential account data, or commercially sensitive contract pricing. Provider and upstream request identifiers can be sanitized or replaced while preserving their structural relationships.

The example should describe NovaRouteAI’s actual observations accurately, while avoiding any implication that OpenAI or another upstream model provider has adopted ABDS. NovaRouteAI would be demonstrating how an OpenAI-compatible multi-model gateway can map real routing and billing evidence into the ABDS v0.6 model.

Please feel free to open the focused issue and link this discussion. Once the scope is agreed, a compact PR would be very welcome.

Kind regards
Marc

[richardchen874-sys]

@MJohnstonAI Thanks for explaining the constraint of shipping mobile applications while funding the startup from your salary. A focused issue followed by a small example PR keeps the contribution useful without turning it into another broad implementation burden.

I agree with the bounded v0.6 scope: one logical request, a primary and fallback attempt, one Usage Event per physical attempt, gateway-attested and provider-reported usage, a versioned pricing snapshot, evidence provenance, and one idempotent settlement or appended reconciliation record. The example should contain no keys, prompts, customer identifiers, or confidential pricing, and should not imply endorsement by an upstream provider.

Before opening the focused issue, should the example use the current v0.6 canonical event names and validator entry points exactly as they exist, or is there a preferred examples directory and test command you want contributors to follow?

[MJohnstonAI]

Good news everyone. Preliminary feedback from OpenAI Support in their developer forum.

I received an email from OpenAI Support who have provided encouraging preliminary feedback on the AI Billing Delegation Standard.
They indicated that the proposal is technically plausible and that its use of OAuth-style grants, short-lived execution tokens, and externally managed quota state is consistent with established security patterns.

They also highlighted several areas that require deeper consideration, including misleading consent flows, token replay, high-volume traffic being attributed to individual users, and applications generating substantial costs without sufficiently clear user intent.

This feedback represents an informal response from OpenAI Support. It should not be interpreted as an endorsement, partnership, formal technical review, or official position of OpenAI.

The ABDS project welcomes community discussion and contributions addressing these risks.