AAuth Budgets

AAuth Budgets Hellō

dick.hardt@gmail.com

Security TBD agent authorization budget metering http resource This document defines AAuth Budgets, an extension to the AAuth Protocol () that carries a spending ceiling from a person server to a resource. A budget is a ceiling on what an agent may consume at one resource, denominated in a unit the resource declares, carried as a claim in the auth token, and enforced by the resource. Budgets are structurally parallel to scope: the agent asks, the resource offers, the person server and access server may narrow, and the auth token carries what was granted. The extension adds a budget claim to resource tokens and auth tokens, a budget_consumed claim reporting what the presented auth token consumed, a budget_units field and a usage_endpoint to resource metadata, and an AAuth-Budget response header reporting what a request cost and what remains. Discussion Venues Note: This section is to be removed before publishing as an RFC. This document is part of the AAuth specification family. Source for this draft and an issue tracker can be found at https://github.com/dickhardt/AAuth.

Introduction Status: Exploratory Draft The AAuth Protocol () lets a person server (PS) decide whether an agent may access a resource, and lets the resource express what access it offers. Neither party has a way to say how much. For a resource that meters and charges per call, that omission is the whole authorization decision. An agent harness calling a model inference endpoint on a person's account can spend without bound: the scope inference.completions is either granted or not, and once granted it says nothing about whether the agent may consume ten cents or ten thousand dollars of the person's money. The person's only controls are outside the protocol — a provider dashboard, a card limit, a bill that arrives after the fact. This document defines a budget: a ceiling on what an agent may consume at one resource, denominated in a unit the resource declares, carried as a claim in the auth token, and enforced by the resource. A budget is an authorization, not a hint. The PS has authorized the agent to spend up to a stated amount, and the resource is the party that counts. That distinction determines nearly every design choice in this document, in particular why the balance cannot be reported through RateLimit () — see . The granted budget is an allocation, not the person's ceiling. The ceiling is the person server's own state: no claim carries it, and it may not be shared with the agent. The PS sizes each auth token against what the work has cost so far, and the token's expiry or its budget's exhaustion — whichever comes first — brings the agent back for the next allocation. That return is the supervision point, and the PS's options there are the subject of . Nobody knows at mission approval what an agent's work will cost; a figure fixed once up front is either too small to finish or too large to be a control . Metered inference is the initiating use case, and covers it as a named deployment pattern. The mechanism is general: any resource that meters and charges per call uses it unchanged. TPX profiles the same grant for OAuth 2.0: a person grants a human-driven app a metered inference budget — "a damage cap, not a payment" — from a provider the person chooses and pays. This document is the AAuth counterpart: the same grant, carried to an autonomous agent through the narrowing chain, and generalized beyond inference to any resource that meters. A provider implementing both accepts two authorization envelopes over one meter .

Non-Goals

Not a mission aggregate. A budget covers a single resource in a single unit. It does not express a cross-resource total such as "$5,000 for the Japan trip." Mission-wide totals require aggregation across resources that meter in different units, which this document does not define.
Not a rate limit. A budget is cumulative consumption, not per-window throughput. RateLimit and RateLimit-Policy () cover throughput. Both MAY appear on the same response as AAuth-Budget, meaning different things.
Not pricing. The resource prices its own service. A budget bounds spend at whatever prices the resource charges; this document defines no way to express a price.
Not composite. A budget is one amount in one unit. A resource that meters several quantities at different rates — input tokens, output tokens, cache reads — collapses them to one billing unit, typically currency, before denominating a budget.
Not payment or settlement. No funds move. 402 Payment Required and the resource's commercial arrangement with the person are untouched.
Not PS-enforced at request time. The PS authorizes a number. The resource counts against it. The PS is not in the request path.
Not an OAuth extension. This document defines claims in AAuth tokens (aa-resource+jwt, aa-auth+jwt), fields in aauth-resource.json, a resource endpoint, an AAuth capability value, and an AAuth response header. It registers nothing in an OAuth registry. The documents surveyed in are cited as prior art and are non-normative.

Conventions and Definitions {::boilerplate bcp14-tagged}

Terminology

Budget: A ceiling on what an agent may consume at one resource, expressed as an amount in a unit the resource declares.
Unit: A resource-declared identifier for what is being metered — a currency code, a token count, a call count.
Scale: The number of decimal places implied by a budget amount, carried as decimals. An amount of 5000000 with decimals of 6 is 5.000000 of the unit.
Granted budget: The budget claim of an auth token. The figure the resource enforces against.
Consumption: What the resource has metered against a granted budget, in the same unit and scale.
Consumption record: A {jti, consumed} pair reporting what the resource metered against one auth token's budget, as of the resource token that carries it. Carried in the budget_consumed claim of a resource token.
Usage counters: Calendar-aligned consumption totals a person server reads at the resource's usage_endpoint.

Budget Model

A Budget Is Structurally a Scope The AAuth Protocol defines scope in three positions with a narrowing rule (, Scopes). A budget occupies the same three positions, plus the PS-to-AS hop in four-party access:

Position	`scope`	`budget`
Authorization endpoint request	what the agent asks for	what the agent asks for
Resource token	what the resource will grant	what the resource will grant
PS-to-AS token request	(n/a)	what the PS will allow
Auth token	granted, MUST NOT be broader	granted, MUST NOT exceed

The base protocol's rule that a resource token MUST only include resource scopes the resource has declared in its scope_descriptions metadata has a direct parallel here: a resource token MUST only name a unit the resource has declared in budget_units . This extension therefore introduces one new claim shape and no new authorization semantics. Every party that already knows how to narrow a scope knows how to narrow a budget.

The Narrowing Chain Each stage MUST NOT exceed the previous stage. There is one asymmetry between the amount and the denomination: the resource settles the denomination, and no later party may change it. | | | | | sets unit and decimals, | | | MAY lower amount | | | | | | resource token (budget) | | |<----------------| | | | | | | | resource token | | | |-------------------------------->| | | | | MAY lower | | | | amount | | | | | | | budget (four-party only) | | | |--------------->| | | | | MAY lower | | | | amount | | | auth token | | | |<---------------| | auth token (granted budget) | | |<--------------------------------| | ]]> {: #fig-narrowing title="Budget narrowing. Only the resource sets the unit and scale."}

The agent requests. OPTIONAL. A budget object in the authorization endpoint request . Omitting it means the resource applies its own default. Requesting more than the resource will allow is NOT an error; the resource narrows.
The resource sets the unit and scale, and MAY lower the amount. The resource is the enforcer and the only party that knows its own pricing, so it settles the denomination. It MAY change unit from what the agent requested — for example converting a request denominated in tokens into a currency amount. After this stage, unit and decimals are fixed for the life of the grant.
The PS MAY lower the amount. The PS MUST NOT change unit or decimals. It is applying the person's policy to a figure the resource denominated; a PS that redenominated would be stating a budget in something the resource may not meter in.
The AS MAY lower the amount (four-party only), for its own credit or risk reasons. The same prohibition on changing unit or decimals applies.

Because the resource MAY change the unit, an agent MUST NOT assume the granted budget is directly comparable to what it requested. The agent reads what it actually got from the budget claim of its auth token. The resource token carries one figure, not both the agent's request and the resource's own maximum. It is the minimum of the two, exactly as scope is. What the agent originally asked for has no bearing on the PS's decision; an agent that wants the PS to know it belongs in justification (, Auth Token Endpoint).

Value Representation A budget amount is a non-negative integer in a scale the resource declares. It is not a floating-point number and not a decimal string. The value of a budget is amount divided by 10 raised to the power of decimals, in unit. An amount of 5000000 with unit of USD and decimals of 6 is five US dollars. The scale is declared per unit, not globally. A resource metering US dollars per inference call wants decimals of 6 to represent micro-dollars; a resource metering Japanese yen wants 0, matching the ISO 4217 minor unit; a resource metering tokens wants 0. decimals is the name x402 and ERC-20 use for this quantity. ISO 4217 and ISO 20022 call it the minor unit. This document does not introduce a third name. See for why the value is an integer and for why the scale travels with the amount rather than being derived from the unit identifier.

Range Limits Two carriers bound the representable range:

A Structured Field Integer (, Section 3.3.1) is limited to 15 digits, which bounds remaining, cost, and reserved in the AAuth-Budget header .
A JSON number is exact only to 2^53 (approximately 9.0 x 10^15), which bounds the amount member of the budget claim.

US dollars at decimals of 6 therefore top out near 10^9 per budget, which is well beyond any plausible grant. Implementations MUST NOT issue a budget whose amount exceeds 999,999,999,999,999 (15 digits), so that the amount and every derived figure remain representable in both carriers. If assets requiring 18 decimal places come into scope, both carriers break and amount would have to become a string, as it is in x402. This document does not define that change.

The Budget Object One shape appears in every position — the authorization endpoint request, the resource token, the PS-to-AS token request, and the auth token: Members:

amount (REQUIRED). A non-negative integer, subject to .
unit (REQUIRED). A string identifying what is metered. For currency, the value SHOULD be an ISO 4217 alphabetic code. Units are resource-declared; this document establishes no registry of unit values, for the same reason the base protocol establishes no registry of scope values.
decimals (REQUIRED). A non-negative integer giving the scale of amount. When unit is an ISO 4217 code, decimals is NOT constrained to that currency's minor unit; see .

The object appears alongside scope wherever both are present:

Resource Metadata Extensions This document extends the /.well-known/aauth-resource.json document defined in AAuth Protocol () with two fields: budget_units (OPTIONAL). An array of objects, each declaring one unit the resource will denominate a budget in. Each object contains:

unit (REQUIRED). The unit identifier.
decimals (REQUIRED). The scale the resource uses for this unit. A resource MUST use this value in every budget it issues for this unit.
max (RECOMMENDED). A non-negative integer, in this unit's scale, giving the largest amount the resource will accept on a single auth token. It lets an agent on the proactive path request something the resource will honor rather than discovering the ceiling by having its request narrowed.
description (OPTIONAL). A Markdown string describing what the unit meters, for display at a consent screen. Implementations MUST sanitize the Markdown before rendering to users.

A resource that declares budget_units MUST NOT issue a resource token whose budget.unit is absent from the array, and MUST set budget.decimals to the value declared for that unit. usage_endpoint (OPTIONAL). The HTTPS URL where a person server or access server queries usage counters . The URL MUST conform to the requirements the base protocol places on endpoint URLs (, Endpoint and Other URLs). The example also carries revocation_endpoint, which the base protocol recommends for a resource that accepts person tokens, as a metered resource does (, Resource Metadata). Settlement of a revoked token depends on it . A PS or AS that receives a resource token carrying budget already fetches {iss}/.well-known/aauth-resource.json to discover the resource's JWKS, per the dwk claim (). The unit declarations arrive in a fetch it was already making, so the cross-check in costs no extra round trip.

Authorization Endpoint Extensions An agent MAY include a budget object in the authorization endpoint request body alongside scope: The agent presents a person token at the authorization endpoint, as the base protocol requires (, Authorization Endpoint). budget (OPTIONAL). The ceiling the agent is requesting. All three members of the budget object are REQUIRED when budget is present. The resource MUST NOT reject the request because budget.amount exceeds what it will grant; it narrows instead . The resource MAY reject a budget whose unit it has not declared . When the agent obtains its resource token from a 401 challenge rather than the authorization endpoint (, Auth Token Required), it has not stated a budget and the resource sizes the resource token on its own. This is why max in budget_units matters: it is what makes the proactive path useful on a first attempt. How an agent knows an operation is metered before its first call is answered by R3 (): a resource MAY annotate individual operations in its vocabulary with a budget annotation, and an agent that reads one knows to include budget in this request. The annotation states the fact of metering; budget_units states the units and ceilings.

Resource Token Extensions This document extends the resource token (a JWT with typ: aa-resource+jwt) with two optional claims.

budget (OPTIONAL): A budget object . The ceiling the resource is willing to have granted. Subject to the rules in .
budget_consumed (OPTIONAL): A consumption record for the auth token presented on the request this resource token answers — what it has consumed to date. Not a grant.

This example is the resource token a resource issues on a challenge to a request presenting the auth token of once that token's grant is spent, so presented_jti and the record both name that token.

The Consumption Record budget_consumed is a single consumption record with two members, both REQUIRED:

jti: The jti claim of the auth token presented on the request this resource token answers. This is the value the resource token carries as presented_jti (, Resource Token Structure).
consumed: What the resource has metered against that token's budget, as of this resource token's iat: a non-negative integer in the unit and decimals of the budget claim in the same resource token.

A resource MUST NOT include budget_consumed unless budget is present in the same token, and MUST omit it rather than state it in another scale — a record carried in a stale scale is the thousandfold error in miniature. The record exists for one figure the issuer needs and cannot compute. budget-exhausted implies the whole grant was spent, but under insufficient-budget , and on a token that expired with budget left, the token's spend to date is a number only the resource holds — and without it the issuer accounts for the allocation as fully consumed when most of it may remain. A resource issuing a resource token on a challenge to a request that carried an auth token SHOULD include the record. A resource issuing one on a person token, at its authorization endpoint or on the first challenge of a grant, has no auth token to report on and omits the claim. In four-party access the resource token travels to the AS inside the PS's token request, so the record reaches both issuers without a usage query. The record is as of the resource token's iat. It is a snapshot: the token it names is still valid, since a resource issues a resource token only on a request carrying a valid person token or auth token, and the token may spend more before it expires. A later record for the same jti supersedes an earlier one. A token's final figure is settled by the usage reading . A record is deliberately two members and no more. The jti it names is a token the PS issued — or, in four-party access, relayed from the AS — so the issuer already holds the granted amount, the mission, the scope, and the issuance time, and joins them from its own ledger. Carrying those values again would duplicate what the issuer knows and put more of the person's financial detail into a token the agent also reads. What the issuer cannot know, and what the record supplies, is what the resource actually metered. The record rides in the resource token because it already travels resource → agent → PS at exactly the moment the PS re-decides: no extra round trip, resource-signed, and interpretable without a metadata fetch. It names the presented token and nothing else. The spend under a person's other tokens is served at the usage endpoint , which answers that question better — per key, per mission, over calendar periods — on a channel the agent is not on. An earlier revision carried up to twenty records; says why one is enough.

Auth Token Endpoint Extensions No new request parameter is defined for the agent's request to the PS's auth_token_endpoint. The budget reaches the PS inside the resource token. An agent seeking a larger budget obtains a fresh resource token from the resource — stating the larger figure in the authorization endpoint request , or being handed one on a 401 — and SHOULD explain the need in the justification parameter of the auth token request. When the PS issues the auth token itself (three-party), it applies the person's policy and issues per . When it federates (four-party), it proceeds per .

What the PS Is Deciding The resource token's budget states what the resource will allow. It is an offer, not a request the PS is obliged to answer in full. Against that offer the PS holds a ceiling for the person at this resource — a standing limit, a mission's stated intent, an organizational policy, or a figure the person supplied when asked. The ceiling is PS state. This document defines no wire format for it, no claim that carries it, and no way for the agent to read it. What the PS issues is an allocation drawn against it. Sizing the allocation is where the PS's supervision happens. A PS that issues the resource's full offer every time has authorized the resource's maximum and learns nothing until the money is gone. A PS that issues a fraction sees the agent again when that fraction is spent, with the token's consumption record in hand, and decides then whether the work is going as the person expected. The interval is not fixed by the clock. An auth token expires within an hour, and its budget is exhausted after however much work it took to spend — whichever comes first returns the agent to the PS. A mission running cheaply reports on the hour; one running expensively reports in minutes. The PS sets that frequency by sizing the allocation, and no party configures it .

What the PS Reads Four inputs are available at the moment of the decision, and a PS applying the person's policy SHOULD use all of them:

budget_consumed in the resource token the agent just presented: what the token it was presenting has cost so far, resource-signed, arriving at no round-trip cost.
Usage counters at the resource's usage_endpoint: totals over calendar periods, and for a mission query the mission's total to date — the figures that cover the stretch when the agent was not talking to the PS.
The mission log (, Mission Log): every prior token request, justification, and clarification in this mission, which is what makes "faster than expected" a judgement the PS can actually make.
The justification parameter of this request: why the agent says it needs more.

The first two are the spend; the second two are the context. A budget escalation is not interpretable without both.

How the PS Responds Six responses are available. None is new to this document; the base protocol defines each, and this section states which apply to a budget decision.

Response	Mechanism
Grant the offer	Issue an auth token with `budget` equal to the resource token's
Grant less	Issue a lower `amount`
Ask the agent	`202` with `requirement=clarification`
Ask the person	`202` with `requirement=interaction`
Decline with a figure	Error response carrying `suggested_budget`
End the work	Terminate the mission

Granting less needs no signalling: the amount in the issued claim is the answer, and the agent reads it from the token it received . Clarification is the response for an escalation the PS is not ready to refuse or approve. A PS that sees consumption running ahead of what the mission implies MAY return 202 with requirement=clarification (, Clarification Required), putting a question to the agent before deciding. This is the channel that lets the PS tell an agent it is overspending, which narrowing alone cannot do — a smaller amount is silent, and the agent cannot distinguish a PS applying pressure from a resource lowering its own offer. The agent's three replies are already defined and all three are useful here: a clarification_response explaining the spend, an updated_request carrying a fresh resource token for a smaller figure with the presented_token it used to obtain it (, Updated Request), or a DELETE withdrawing the request. The base protocol's limit on clarification rounds applies (, Clarification Limits). An agent that did not declare the clarification capability cannot be asked, and the PS decides without it. Asking the person is the same mechanism one step further out, and is the right response when the answer is the person's rather than the agent's — a ceiling raise rather than an allocation. A PS that puts a budget to the person for consent MUST present the amount as a human-readable figure in its unit — "$5.00", not {5000000, USD, 6} — visually distinct from any resource-supplied description, which is Markdown and MUST be sanitized before rendering . The amount is the decision the person is making. Ending the work is the response to an agent whose spending the PS cannot account for. Terminating a mission is not a budget mechanism and this document defines nothing about it; it is named here because a budget escalation is one of the few signals that reliably surfaces an agent behaving unlike its mission.

PS-to-AS Token Request Extensions This document extends the PS-to-AS token request (, PS-to-AS Token Request) with one parameter, used in four-party access only. budget (OPTIONAL): A budget object carrying the ceiling the PS will allow. The PS MUST copy unit and decimals from the resource token's budget claim unchanged, and MUST NOT set amount higher than the resource token's budget.amount. The AS MUST NOT issue a budget claim exceeding this parameter, and MAY lower it further. When the AS returns an auth token, the PS MUST verify, along with the checks of the base protocol's Auth Token Delivery, that the token carries a budget claim when the PS sent a budget parameter, that the claim has the unit and decimals of that parameter and an amount no higher, and that the token carries no budget claim when the PS sent no budget parameter. A token without a budget claim would leave the resource to apply its own default, which can exceed what the PS allowed. A token that fails is an auth token that fails delivery verification, and the PS answers the agent as_unreachable (, Auth Token Delivery). This is the budget counterpart of the base protocol's check that the AS's scope is no broader than the resource token's. When the resource token carries budget and the PS omits this parameter, the AS MUST NOT issue a budget claim. A PS that grants the resource's full offer says so by echoing the resource token's budget; omission is what a PS that does not implement this extension sends, and it MUST NOT be read as a grant. The auth token then carries no allocation, and the resource applies its own default to it . Reading omission as the full offer would turn a PS's non-participation into the maximum grant, the opposite of what ignoring an unrecognized claim is meant to do.

Auth Token Extensions This document extends the auth token (a JWT with typ: aa-auth+jwt) with one optional claim. budget (OPTIONAL): A budget object . This is the granted budget and is authoritative. Issuer rules:

The issuer MUST copy unit and decimals from the resource token's budget claim unchanged.
The issuer MUST NOT set amount higher than the resource token's budget.amount, or, in four-party access, higher than the budget parameter of the PS-to-AS token request .
An issuer MUST NOT include budget in an auth token when the resource token carried no budget claim. The resource, not the PS or AS, denominates.

Resource rules:

A resource that issued a budget in a resource token and receives an auth token without a budget claim MUST treat the request as carrying no budget authorization under this extension and apply its own default.
A resource MUST enforce against the auth token's unit and decimals, not against its own current budget_units metadata. Auth tokens live up to an hour and metadata can change within that hour; see .

AAuth-Budget Response Header AAuth-Budget is a response header carrying the remaining balance of the granted budget. It is a Dictionary (, Section 3.2), matching AAuth-Requirement. Members:

remaining (REQUIRED): A non-negative Integer, in the granted scale, giving what is left of the budget on this auth token, net of reservations for requests in flight . It is a floor — committed consumption will not exceed the grant — though the figure may lag metering. Exhaustion is signaled by the requirement=auth-token challenge, as a 401 or a 202 , for which the agent stays prepared regardless.
cost (OPTIONAL): A non-negative Integer, in the granted scale, giving what this request cost. A resource sends it in the header when it knows the figure as it writes the response, in a trailer when it learns the figure after , and not at all when it will not learn it in time to do either. The third case is bounded by .
reserved (OPTIONAL): A non-negative Integer, in the granted scale, giving what the resource has held against the grant for this request and not yet committed . Meaningful only where cost is not yet known, so in practice it accompanies a streamed response. It is a statement about this request, not a running total, and is never revised. REQUIRED where cost is omitted .
required (OPTIONAL): A non-negative Integer, in the granted scale, giving the maximum cost the resource computed for a request it refused under reason=insufficient-budget . Sent only with that refusal, where it is RECOMMENDED. It is what the request needed, not what the resource is asking the PS to grant next; see .
unit (OPTIONAL): A String naming the unit. decimals (OPTIONAL): an Integer giving its scale. Both are informational, and they are a pair: a sender MUST include both or neither. They exist for readers that never parse a JWT — proxies, logs, dashboards. Those are the same readers that would misinterpret an amount carrying a unit with no scale, by a factor of 10^decimals.

Recipients MUST ignore members they do not recognize. The header carries no granted member, no cumulative consumption figure, and no token reference. The agent holds the auth token it signed the request with and reads granted from there; what it needs per response is what this call cost and what is left, which is what the field carries. Cumulative consumption is an issuer-facing figure, reported in the resource token and at the usage endpoint ; see for why it is not also reported to the agent. The scope of the reported figures is this auth token's budget, because the budget expires with the token .

Sending Rules A resource that granted a budget SHOULD include AAuth-Budget on every response to a request bearing that auth token — success, error, and the challenge, 401 or 202 , where it reads remaining=0 beside the AAuth-Requirement header . This is SHOULD rather than MUST because the failing layer may sit below the metering layer: a gateway timeout, a crashed worker, or a fault in metering itself produces a response no budget figure can ride on. A resource MUST NOT omit the field for any other reason. An agent that misses the field learns the balance from its next response, and until then applies . That the field appears on every response regardless of status is the point of putting it in a header. The agent reads the same field whether the body is JSON, a server-sent event stream, a streamed completion, or a problem document . Intermediaries MUST NOT add, alter, or remove AAuth-Budget. The field reports the state of an authorization the resource issued; an intermediary rewriting it is asserting authorization state it does not hold. This is the inverse of the RateLimit rule permitting intermediaries to tighten values () — see . Recipients MUST ignore AAuth-Budget on a response served from cache with a positive current_age (, Section 4.2.3). This is the one RateLimit rule that carries over unchanged.

Denomination Conflict The auth token's budget claim is authoritative. A recipient MUST NOT act on a header unit or decimals that disagrees with the budget claim in the auth token it presented, and SHOULD treat the whole field as unreliable for that response. Including the pair makes the field self-describing for proxies and logs that never parse a JWT, at the cost of duplicating signed values; the conflict rule is that cost made explicit.

Streaming Response headers are written before the body, and a streamed response's actual cost is known only when the stream ends. The resource therefore cannot state cost in the header. What it can state is what it has held: it reserved before serving , and remaining is already net of that reservation. A resource serving a streamed response SHOULD send reserved in the header and cost in a trailer. A resource that cannot send trailers sends reserved alone . The agent computes the balance after the request as remaining + reserved - cost. Here that is 1,778,800: the 431,200 held was not all spent, and the unspent 210,000 returns to the grant.

When cost Is Omitted Not every resource can send a trailer. Trailers exist only on a chunked or HTTP/2-and-later response, and several widely deployed server runtimes provide no way to emit one at all. A resource in that position knows the cost of a streamed response only after its last opportunity to report it. Such a resource omits cost and MUST send reserved in the header. The agent recovers the figure from the following response: cost = previous remaining + reserved - current remaining The subtraction works because remaining is already net of reservations : the earlier figure is net of the hold, the later one reflects the commit and the release of the unspent remainder. reserved is the term that connects them, which is why it stops being optional here. It recovers one request's cost only where requests on that token are serial. An agent with several requests in flight on one token recovers the net of everything that settled between the two responses, not the cost of any single one, because every concurrent request moves the same remaining. An agent that wants per-request figures from a resource that omits cost serializes its requests on that token; an agent that only needs the balance does not have to. Until that next response arrives the agent applies and treats the request as having cost the full reserved amount. That is the conservative direction, and it is the same rule the agent already applies to a response it never received. A resource MUST NOT omit both cost and reserved. That combination reports that a metered request happened and gives the agent no figure for it, neither exact nor conservative.

Trailer Rules A resource MAY send AAuth-Budget as a trailer field, subject to three rules:

The response MUST list AAuth-Budget in a Trailer header field (, Section 6.6.1).
A trailer instance MUST NOT restate a member the header instance carried. It carries cost and nothing else.
A recipient MUST NOT treat the trailer as necessary. A response that never delivers one is complete.

Rule 2 is what makes the field safe under either way a recipient handles trailers. A recipient that discards trailers keeps the header's remaining, which is a floor and therefore correct if conservative. A recipient that merges trailer fields into the header set produces a single Dictionary whose keys do not collide, because no key appears twice. Restating a member is the case that would break: AAuth-Budget is a Dictionary, duplicate keys resolve last-wins (, Section 3.2), and which value won would then depend on whether the recipient merged — a difference no sender can observe or control. Rule 3 follows from trailers being droppable in transit (, Section 6.5.2) and from trailers existing only on a chunked or HTTP/2-and-later response. The figure a trailer would have carried is also in the next response's remaining, so nothing is lost that is not recovered on the following call.

Ambiguous Failures A request whose response never arrives — a dropped connection, an aborted stream — leaves the agent unable to say whether it was metered. No trailer arrives on an aborted stream, and the header that would have carried cost is on the response that was lost. The agent MUST assume the request cost as much as the resource had held for it: reserved where it saw one, and otherwise the request's maximum cost as the resource would have bounded it . It carries that assumption until a later response's remaining supersedes it, and it SHOULD NOT retry a chargeable request before then. Assuming the maximum is the conservative direction: an agent that under-assumes plans spending it does not have and discovers the shortfall as a 401 . Inference APIs commonly emit final usage in the stream's terminal event. That is application-layer and does not provide the application independence this header exists for, so a resource that emits it and can also send a trailer SHOULD send both. What it does mean is that the exact number exists when the stream ends, and a resource whose runtime offers no trailer has it and no protocol carrier for it until the next response .

Budget Exhaustion Auth token expired. The budget expires with the token. The base protocol has the agent refresh an auth token when fewer than five minutes remain and not present it inside that margin (, Expiry and the Refresh Margin). An expired token presented anyway is answered 401 with Signature-Error: error=expired_jwt, and the resource issues no resource token. Either way the agent re-authorizes with a person token at the authorization endpoint (, Re-authorization). No consumption record rides on that path, and an allocation that expired unreported settles from the usage reading . Budget exhausted, token still valid. 401 with AAuth-Requirement: requirement=auth-token; resource-token="...". The base protocol already permits a resource to return requirement=auth-token with a new resource token to a request that already carries an auth token, when the request needs more authorization than the token provides, and requires agents to be prepared for this step-up at any time (, Auth Token Required). Budget exhaustion is that case, and the agent's action is the same as for any step-up: take the fresh resource token to its PS, with the exhausted auth token as presented_token. The resource token's consumption record is the exhausted token's spend to date. The auth token issued against it expires no later than the exhausted one (, Auth Token Structure), so a step-up renews the allocation but not the token's lifetime. A full-length token comes from re-authorizing with a fresh person token. Request exceeds the remainder. The budget has remainder, but this request's maximum cost exceeds it . The same 401 challenge, with reason=insufficient-budget. The agent has a second move here that exhaustion does not offer: lower the request's bound to fit the remaining reported beside the challenge, and retry on the token it already holds. The required member is what makes that move a calculation rather than a search. A request refused under this section MUST NOT draw down the budget or appear in the record and counters. The resource declined to serve it; metering the refusal would make exhaustion self-perpetuating. A refusal therefore carries no cost; required is the figure a refusal reports. The fresh resource token SHOULD carry the presented token's consumption record , its spend to date — the context for deciding whether to authorize more, and the figure that tells the issuer how much of the refused allocation was actually consumed.

The reason Parameter A resource challenging because the budget is exhausted rather than because the token expired SHOULD include a reason parameter on the requirement member: reason is a Token. This document defines two values:

budget-exhausted: The granted budget is spent.
insufficient-budget: The budget has remainder, but this request's maximum cost exceeds it .

For either value, the enclosed resource token MAY carry a budget sized for what the resource would need to see granted. The denial is itself the re-authorization offer.

Refusing a Request That Does Not Fit A resource refusing under insufficient-budget has computed the request's maximum cost — requires it to, before serving — and SHOULD report that figure as the required member of AAuth-Budget: The agent now knows both halves of the refusal: it has 0.15, and the request needed 0.40. Without required it knows only the first, and the move offers it — lower the request's bound and retry on the token it already holds — becomes a search. It cannot compute the figure itself, because the bound is the resource's own calculation against its own pricing, and no part of this specification requires a resource to publish what an operation costs. required is not the same figure as the budget claim of the enclosed resource token, and the two SHOULD differ. The resource token's budget is a re-authorization offer addressed to the PS, and a resource sizing it for exactly the refused request hands back a grant good for one call. required is a fact about the request that was refused, addressed to the agent. The header carries it because the agent is the party that acts on it, and because the retry path it enables does not involve the person server at all. A resource MAY refuse without required — where the operation has no cost bound it is willing to state, or where stating it would disclose pricing the resource does not publish. The agent then falls back to remaining alone. No new requirement value is minted. The base protocol says an agent that does not recognize a requirement value MUST NOT treat the response as satisfiable and surfaces it as an error, while recipients MUST ignore unknown parameters on the requirement member (, Requirement Responses). A new value would hard-fail every budget-unaware agent on a condition that plain auth-token resolves correctly. That asymmetry — unknown values fail, unknown parameters are ignored — is why this extension extends by parameter. An agent that understands the reason values knows what to do beyond re-authorizing: for budget-exhausted, request a larger budget and say why in the justification it sends to its PS; for insufficient-budget, either that, or shrink the request and retry without involving the PS at all. An agent that understands neither ignores the parameter and re-authorizes, which is always correct.

Deferred Delivery A resource MAY deliver either refusal as a 202 deferred response rather than a 401, holding the invocation (, Deferred Delivery). The AAuth-Requirement header is the same, reason included, and so is the enclosed resource token with its consumption record . What differs is what becomes of the request. Under the 401 the resource holds nothing, and the agent sends the request again. Under the 202 the resource holds the invocation, and the agent does not send it again: it obtains an auth token and polls the pending URL, and the resource executes the held invocation on the first poll that presents a valid auth token. A resource holding an invocation under this section follows four rules:

Nothing is reserved while it is held. For the held invocation, the resource MUST NOT reserve against or meter to the token presented on the original request. For that token the 202 is a refusal like the 401, and any remainder it has stays available to the agent's other requests.
It meters against the completing token. The held invocation is metered against the auth token presented on the poll that completes it. The resource applies to that token before executing: it reserves the invocation's maximum cost against that token's remainder, serves, and commits.
A completing token that does not fit does not complete it. If the invocation's maximum cost exceeds the remainder of the token presented on the poll, the resource does not execute it. It answers the poll with another 202 carrying requirement=auth-token, reason=insufficient-budget, and a fresh resource token whose presented_jti names that token, and continues to hold the invocation.
A replay is not metered again. A resource answering a repeated presentation of the completing token from the stored result, as the base protocol requires, MUST NOT meter the invocation a second time. The AAuth-Budget on the replay reports that token's current remaining, so that the figure is still a floor, with the invocation's cost where the resource has it and no reserved.

AAuth-Budget on the 202 reports what it would report on the 401: the remaining of the token presented on the request, required under insufficient-budget , and unit and decimals. It carries no cost and no reserved, because nothing was served or held against that grant. A later 202 answering a poll that bore an auth token reports on that token the same way . The response to the completing poll carries AAuth-Budget for the completing token, as any response to a request bearing it does. Under insufficient-budget, the agent's other move — lower the request's bound and retry on the token it already holds — abandons the pending URL. The agent sends a new request with the smaller bound and does not poll the pending URL again. The held invocation is never executed, and since nothing was reserved for it (rule 1), abandoning it costs the grant nothing. The resource discards it when the pending URL's lifetime ends (, Pending URL Security).

Boundaries 429 Too Many Requests is not used by this document. The base protocol gives it two meanings already — slow_down on a pending URL, which asks a polling agent to lengthen its interval, and rate_limited at a revocation endpoint, which refuses work a caller has sent too much of (). Neither is a budget condition. A budget refusal is about what the next request would cost, not about how often requests arrive, and the agent answers it by re-authorizing rather than by waiting. 402 Payment Required is a different condition: the resource needs payment rather than re-authorization from the person. The base protocol already permits AAuth-Requirement on a 402, and this document does not change that.

Enforcement

The Resource Enforces The PS authorizes a number. The resource counts. The PS is not in the request path and does not meter.

Budgets Require Auth-Token Mode A budget is carried in the budget claim of an auth token, so a resource can enforce one only where it requires auth tokens. A resource that declares access_mode: person-token and serves requests on the person's identity alone (, Person Identity Access) has no auth token to read a budget from, and neither does a resource operating in agent-token or session-token mode. A metered resource therefore requires an auth token on the endpoints it meters (access_mode: auth-token). It MAY continue to serve unmetered endpoints on a person token, since a resource MAY apply different modes to different endpoints (, Resource Access Modes). A resource MUST NOT rely on this extension for an endpoint it serves without an auth token. Where the resource holds the authorization state itself rather than reading it from a signed claim, there is nothing for the person server to have bounded.

Token Scope A budget is scoped to the auth token that carries it and expires with it. There is no persistent grant identifier and no requirement that the PS carry a budget across re-issuance. This is the mechanism, not a gap: re-issuance is where the PS re-decides , and a budget that survived it would be a standing grant the PS no longer sizes. The budget is revoked with the token. Revoking an auth token at its resource ends its budget along with the rest of its authorization. In three-party access the PS revokes it there; in four-party access the PS revokes the person token at the AS, and the AS revokes the auth tokens it issued against it (, Token Revocation). A resource without a revocation endpoint honors a revoked token until its exp. Consumption already committed is unaffected — a budget is a ceiling on spending, not a claim on what was spent — and a request already in flight completes, because revocation stops a token being used again rather than interrupting a call. This document adds nothing to that mechanism; it is named here because a person hitting stop expects the money to stop, and expiry alone bounds that at an hour. What a revocation means for the issuer's own accounting — when the allocation it reserved can be released — is . Two conditions return the agent to the PS, and either is sufficient. The auth token nears its exp: the base protocol caps an auth token at one hour and has the agent refresh it when fewer than five minutes remain (, Expiry and the Refresh Margin). Or its budget is exhausted , which happens after however much work it took to spend. Expiry is proportional to time and exhaustion is proportional to spend, so the supervision interval tracks whichever is moving faster: a mission running cheaply reports on the hour, one running expensively reports in minutes, and no party configures the difference.

Unreported Allocations An allocation can expire before its issuer sees a figure for it. A consumption record comes back only on a challenge to a request that presented the token . A token the agent retires by refreshing it, as the base protocol has it do inside the refresh margin , is never named in one, and neither is a token held by an agent that has crashed or been abandoned. Until the next usage query, the issuer knows a grant was live and nothing about what it consumed — the true figure is anywhere from zero to the full amount. Until a figure arrives, the issuer MUST account for the allocation as fully consumed. The error modes are not symmetric: an issuer that assumes less than was spent sizes the next allocation against headroom that may not exist and can overrun the ceiling it holds, while one that assumes the maximum is at worst temporarily conservative, which the next figure corrects. This is applied to the other end of the grant — the party missing a figure assumes the maximum until a real one supersedes it. Reconciliation is idempotent where the channel names the token. A consumption record is a {jti, consumed} pair whose consumed is that token's total as of the resource token that carried it , so a record arriving late — or arriving again — replaces the assumption for that token rather than adding to it. Usage counters and per-key figures name no jti; they are aggregates the issuer reconciles against its own ledger of what it assumed. The rule falls on every party that sized the allocation against a ceiling it holds. In three-party access that is the PS . In four-party access it is also the AS, which issues against the ceiling the PS stated and may apply credit or risk limits of its own . Both are entitled callers of the usage endpoint .

Settlement The issuer set every allocation's exp, so it knows when the assumption can be settled. A consumption record settles nothing. It is a snapshot : the token stays valid, the agent may spend more on it, and under insufficient-budget may retry a smaller request on it . What the record gives the issuer is the spend so far, for the re-authorization decision it is making at that moment. A usage reading settles every allocation, in aggregate. The issuer takes the person's figure from the usage endpoint , complete through as_of, and then holds where metered is the person's counter — all_time for a standing ceiling, the matching calendar counter for a calendar one — and an allocation is settled by the reading once its exp is at or before as_of. A settled allocation needs no figure of its own: whatever it consumed is inside metered, and it is no longer reserved. The only over-count in free is consumption under still-live tokens, present in both terms; it vanishes as each expires and the next reading covers it. The per-token figure in a consumption record refines the issuer's picture of a live allocation between readings; it does not settle it. A revoked token is not an early exp. Revocation stops the spending; it does not by itself release the reservation, because the figure for what was spent still arrives with the next reading. What it does is move the moment after which no more can be spent, and the issuer learns whether that moment exists from the revocation's own answer: a recipient answers 200 once its cascade is terminal, directly or at the pending URL of a 202, and an AS reports each resource's outcome in downstream (, Revocation Response). Three outcomes, three answers:

Recorded at the resource. Nothing further can be spent on that token. The allocation is settled by the first usage reading whose as_of is at or after the revocation was recorded, rather than the first one at or after exp — the same rule as any other settlement, since whatever was spent is inside metered by then.
revocation_unsupported. The resource honors the token until exp. The allocation stays reserved until exp and settles as it would have without the revocation.
revocation_unavailable. The issuer cannot tell which of the two it has, so it holds the allocation reserved until exp and MAY revoke again later.

An issuer that treated every revocation as an immediate settlement would release headroom that a resource with no revocation endpoint is still spending against, which is in reverse and has the error mode that section rules out. An issuer whose ceiling is per calendar period SHOULD set each allocation's exp no later than the period boundary. No allocation then straddles two periods, every allocation of a period has expired when the period ends, and the period settles without a query. The cost is that a token issued near the boundary is short. The calendar counters have no sub-day period ; an issuer with an hourly ceiling and clipped allocations never needs one, and an issuer with a trailing window settles from differences of successive all_time readings.

Aggregation Two things are counted, against different keys, and they are not the same requirement. The cap the resource enforces is per auth token. It is the budget claim of the token presented, and states the invariant: committed consumption plus outstanding reservations against that token MUST NOT exceed its granted amount. A resource needs no cross-token arithmetic to enforce a budget. The ledger the resource keeps is per person. The resource MUST aggregate consumption against the key (ps, sub, aud) of the auth token, which is what the consumption record and the usage counters report. (ps, sub) identifies the person: sub is minted by the person server named in ps, and values from different person servers are different people. aud is the resource itself. In three-party access ps equals iss. In four-party access iss is the AS, which did not mint sub, so a key on iss would let two person servers behind one AS collide; ps is the person server the AS verified sent the token request (, PS-to-AS Token Request). This document introduces no new identifier. The ledger is not a second ceiling. A resource MUST NOT refuse a request that fits its token's budget because a per-person total has reached some figure the resource inferred; no party told it such a figure, and the budgets it was handed are what it was authorized to honor. Holding a person's spending across concurrent tokens within bounds is the PS's job , because the PS is the party that issues them and the only one that knows the ceiling . A per-agent ceiling is not a resource-side key either. A person server that wants one agent capped at less than another issues it a smaller allocation ; the enforcement is the token's own budget, and no resource-side dimension is involved. What a resource cannot supply from allocations alone is how much each agent actually spent, since an allocation is a ceiling rather than a figure — that is what the per-key query at the usage endpoint serves . The ledger's key is the person, not the agent and not the mission. An auth token names no agent, and a person's spending at a resource is theirs whichever agent incurred it; a per-agent key would also reset every time the person changed agents. mission_s256 is optional — a token may carry one or not — so a mission-keyed ledger has no bucket for a mission-less token, and requires mission-less tokens for standing inference budgets. The person is the only key present on every auth token. Missions are an attribution dimension over that ledger , not the ledger itself.

The Billing Account A resource that meters usually charges someone for it, and the party it charges is an account in its own systems. Nothing in a budget names that account. The aggregation key above is (ps, sub, aud), and sub is directed per person server — it identifies a person at one PS and carries no meaning at the resource beyond what the resource has learned about it. For most resources that is sufficient and no mechanism is needed. The base protocol keys a person's relationship with a resource on the person server and sub precisely so it survives a change of agent, and a resource holding one account per person looks the account up from (ps, sub). tenant names the person's organization and is not part of the identifier (, Organization Identification). Consumption then meters against the account the resource already had. Beyond that, two different questions arise, and they compose rather than substitute. The first is asked once per person; the second on every authorization. Which person is this? The first budgeted request carrying a sub the resource has not seen is a question for the person, not the agent, and both access modes answer it with an interaction the person completes at the party that holds the account. In three-party access the resource asks. It puts an interaction claim in the resource token, and the person server chains the person through the resource's own flow — signing in, creating an account, connecting a payment method — before completing its own consent (, Resource-Initiated Interaction). Because the resource issues the resource token, it decides when to ask again: once per person, or once per mission, since it sees mission_s256 at that moment. In four-party access the AS asks, returning 202 with requirement=interaction to the person server's token request (, PS-AS Trust Establishment). This is the same one-time binding the AS already performs to establish trust with a person server, answering a second question at the moment it is already asking the person who they are. Because sub is directed per person server, a person reaching the same resource through two person servers presents two identifiers. The binding interaction is what attaches both to one account, and a resource that skips it sees two people and bills two ledgers. Which of their accounts? Binding establishes who the person is. It does not say which of several accounts an authorization is for, and a person who holds more than one at the resource has to say. Account Binding (, Account Binding) carries the answer: an OPTIONAL account parameter on the authorization endpoint request, named from the resource's own namespace, echoed as the account claim of the resource token and copied into the auth token. This applies in both access modes; how account reaches the issuer, and what each party does with it, is specified there and not restated here. In four-party access it reaches the AS in the resource token, so the binding tells the AS who the person is and account tells it which of their accounts this authorization bills. A metered resource should ask for account where a person may hold more than one, because a budget enforced against the wrong account is charged to the wrong payer. A resource holding one balance per person needs none of it: binding is the whole mechanism, and account never appears in its tokens. None of this is specific to budgets, and this document defines no new mechanism for it. It is stated here because a metered resource meets these cases on its first request and the rest of this document is silent on them.

Concurrency An agent may hold several concurrent auth tokens at the same resource — the mission_s256 claim means concurrent missions produce concurrent tokens, each with its own budget, for up to an hour. Handling this is mandatory, not optional:

A resource MUST apply the reserve-commit-release invariant of atomically per auth token, so that concurrent requests presenting the same token cannot together exceed its budget.
A resource MUST post consumption to the (ps, sub, aud) ledger atomically, so that concurrent requests across different tokens do not lose or double-count against the record and counters.
A PS SHOULD size per-token budgets so that their sum stays within whatever standing ceiling it holds for the person at that resource. This is the only place the cross-token total is enforced; is how an issuer keeps that sum exact as allocations expire.

The bound on over-issuance is the auth token lifetime multiplied by the number of concurrent tokens. A PS that issues n concurrent tokens of X each has authorized up to nX for as long as an hour, regardless of any standing figure it intended to hold.

The Budget Is a Hard Cap A resource MUST NOT let metered consumption exceed the granted amount. A budget is an authorization, and an authorization the enforcer may exceed is a hint. Output is metered after it is generated, so honoring the cap means bounding the request before serving it. Before serving a chargeable request, the resource determines the request's maximum cost — from a bound the request declares, such as a maximum output length, or from a documented default — and refuses the request with reason=insufficient-budget when that maximum exceeds the remainder. An operation with no finite cost bound MUST be given one, be truncated when the remainder is consumed, or be refused. The implementation shape is reserve-commit-release: atomically reserve the maximum against the grant, serve, commit the actual charge, release the difference. The normative requirement is the invariant, not the mechanism: committed consumption plus outstanding reservations MUST NOT exceed the granted amount at any moment, including under concurrent requests . The honest cost of the invariant lands near exhaustion: a request bounded at more than the remainder is refused even when its actual cost would have fit. The mitigation is the agent's — read remaining from the refusal's AAuth-Budget header and retry with a bound that fits — and that is the correct pressure, since it rewards realistic bounds.

Failed Calls Whether a request that fails — a 5xx after input tokens were consumed — draws down the budget is the resource's metering policy. Whatever it meters, the record and counters MUST reflect, or the person's numbers will not reconcile with the bill.

Delegation A budget is not delegable. Each auth token carries its own budget, and consumption through a delegated token draws down that token's budget alone. Both delegation paths — call chaining and sub-agent authorization (, Agent Delegation) — obtain each downstream auth token through the person server, so the PS sizes every grant in a chain, and already governs their sum. No sub-budget or draw-down-from-parent mechanism is defined.

Mission Attribution Consumption is attributed to a mission using the mission_s256 claim of the auth token, beside its ps claim: a mission is identified by the PS that approved it together with mission_s256 (, Mission Identifier). mission_s256 is PS-asserted throughout: the person server validated the mission when it issued the person token, the resource copied it into the resource token, and the person server, and in four-party access the AS, verified that it matches the presented token's (, Resource Token Verification). No party in the chain takes the mission on the agent's word, which is what makes a resource's per-mission figures worth reading.

Usage Counters The consumption record reaches the issuer only when the agent brings a resource token back. The agent is the party being budgeted and also the courier of the evidence: it cannot falsify the record, but between re-authorizations it does not appear, and the issuer is blind for up to an hour per token. The usage_endpoint removes the agent from that loop: the issuer — the PS, or in four-party access the AS — queries the resource directly, on a channel the agent is never on. The endpoint serves usage counters: pre-summed consumption totals the PS reads, acts on, and displays. It does not compute, convert, or round. The resource keeps a handful of running integers, incremented at metering time; serving the endpoint requires no per-record history.

Usage Request The caller — a person server, or in four-party access an access server — MUST make a signed POST to the usage_endpoint, signing as a server in its own right: an HTTP Sig under the jwks_uri scheme, with id its issuer and dwk its metadata document (, Keying Material), and the signature additionally covering content-type and content-digest, as on a request with a body to a PS or AS (, Covered Components). The body carries at most one scope key, naming a claim value the resource has seen in auth tokens:

sub: A directed person identifier. Scope: the person at this resource, across all their agents and missions.
tenant: A tenant identifier. Scope: the organization, across its people.
mission_s256: A mission identifier. Scope: one mission.

and one OPTIONAL member:

jkts: An array of JWK Thumbprints (), each naming a signing key the resource has seen present an auth token. Asks for what each of those keys consumed .

An access server names the person server whose values it is asking about:

ps: The person server whose namespace the scope key belongs to. REQUIRED when the caller is an access server and the request carries a scope key, since the tokens an AS issues carry values from every person server that federates with it. A person server omits it; it is the caller.

A request MUST carry a scope key or jkts, and MAY carry both. At most one scope key may appear. A request with more than one scope key, or with neither a scope key nor jkts, is an error .

Usage Response

as_of (REQUIRED): The time through which the figures are complete, in seconds since the Unix epoch. Metering aggregation MAY lag serving; as_of is what keeps a lagging figure honest.
aud (REQUIRED): The caller the response was produced for — a person server, identified as in the ps claim of a resource token, or an access server, identified as in the iss claim of an auth token. It is what stops a signed response being presented to a third party as a statement about them .
unit (REQUIRED) and decimals (REQUIRED): The unit every figure in the response is denominated in, and its scale, as in the budget object .
The scope key from the request, echoed unchanged — sub, tenant, or mission_s256 — present only when the request carried one.
usage (REQUIRED when the request carried a scope key): Calendar counters for that scope.
jkts (REQUIRED when the request carried jkts): An object mapping each thumbprint to what that key consumed .

Calendar Counters The members of usage are day, week, month, year, and all_time, following the interval enumeration of Stripe Issuing . Each is a non-negative integer giving consumption within the current period:

day: since 00:00 UTC today.
week: since Monday 00:00 UTC of the current ISO 8601 week.
month, year: since the start of the current UTC calendar month or year.
all_time (REQUIRED): everything the resource has metered against budgets under this key.

All period boundaries are UTC. This is a definition, not a deployment choice: no timezone appears in metadata or in the response, and every party computes the same figure. The cost is that "today" resets mid-afternoon in Auckland, which Stripe Issuing accepts for the same reason this document does — the counter is decision context, not a bill. The calendar counters other than all_time are OPTIONAL; a resource omits periods it does not track. For a mission_s256 query, all_time is the mission total — the figure a PS wants when deciding whether to fund a mission's continuation — and a resource MAY serve it alone. Counters are subject to the 15-digit bound of . A resource whose cumulative figure would exceed it omits that counter rather than reporting an inexact number. all_time reaches as far back as the resource retains. This document sets no retention requirement for scope keys; the person's bill is the durable record.

Per-Key Figures Each member of jkts is a thumbprint mapped to a single non-negative integer: everything the resource has metered against budgets on auth tokens presented by that key. There are no calendar periods here. A key's consumption is already bounded by the tokens issued to it, and an auth token lives at most an hour; a key that has stopped presenting tokens has a figure that no longer moves. Periods answer "how much this month", which is a question about a person, not about a key. A resource SHOULD retain a key's figure for at least 24 hours after that key's last metered request, and MAY retain it longer. The bound is idle time rather than age, so a key in continuous use is never pruned. Beyond that window the PS is the party that accumulates: it polls, it knows which keys belonged to which agent across rotations, and it holds the history. The resource keeps a short tail. A resource MUST omit a thumbprint from jkts rather than report zero for it when it holds no figure — because the key is unrecognized, or because its figure has been pruned. Absence means the resource cannot answer; a present zero means the key consumed nothing. This differs from the treatment of an unrecognized scope key , and the reason is that there is nothing to conceal: the PS issued or relayed every auth token, so it already knows the key exists, and a zero that means "pruned" would be a wrong answer to an allocation decision rather than a withheld one.

One Unit Per Response Every figure in a response is in one unit, named once at the top level, and it is the unit the resource meters in. There is no request parameter selecting it. The alternative is a per-unit array at every level, which costs every response the shape needed by deployments that meter in one unit — which is nearly all of them, since a resource that meters several quantities collapses them to one billing unit before denominating a budget . A resource may still declare several units in budget_units , because that is what an agent may ask a budget to be denominated in; what this endpoint reports is what the resource actually metered, and the response says which unit that was.

The Signed Response Signing the usage response is RECOMMENDED. A resource that signs uses an HTTP Sig with a key from the jwks_uri in its resource metadata — the same key material the PS already fetched to verify resource tokens. The signature MUST cover @status, content-type, and content-digest, and MUST be bound to the request by covering the request's @authority and @path with the req parameter (). The endpoint reports what a person owes for, so an unsigned figure is one the party that produced it can later disown. Signing makes the resource committed to what it reported: it cannot tell the person server one number and the biller another. It does not make the meter honest — the resource is the counterparty as well as the signer — and covers what remains. It also closes an asymmetry. The consumption record is already resource-signed, because it rides inside a resource token. The usage endpoint is the only issuer-facing consumption channel that is not. It is RECOMMENDED rather than REQUIRED because the figures are decision context rather than authorization, and because this would be the first response-side signature in the AAuth family — the signature profile is request-side throughout . A person server receiving an unsigned response is not in a position to do anything but read it: refusing it leaves the PS with no figures rather than unattributable ones, which is the worse of the two. What signing changes is whether the resource can later disown what it said, and that is worth having wherever both ends will implement it. aud is what keeps the signed response non-transferable. Without it a resource-signed statement of consumption could be handed to a third party as though it described them, and the figures carry no other indication of who asked.

Authorization and Errors The id parameter of the Signature-Key header is the caller's server identifier, and its dwk names the metadata document that says which role is calling — aauth-person.json for a person server, aauth-access.json for an access server (, Keying Material). That identifier is what the response carries as aud . A caller is a person server or an access server. The resource MUST only answer for values that have appeared in auth tokens it accepted whose iss or ps claim names the caller: for a PS, the tokens it issued in three-party access and the tokens carrying it as ps in four-party access; for an AS, the tokens it issued, and for a scope key only those whose ps is the request's ps. This applies to thumbprints in jkts as much as to scope keys. sub is directed per PS, so one person server cannot even name another's subjects; tenant, mission_s256, and thumbprints are not directed, and this check is what stops a third party from querying them. An AS is entitled because it sizes allocations against a ceiling of its own and is bound by for them. An AS operated by the resource may take the same figures from the resource directly; the endpoint is for the AS that is not. A query for a scope key the resource does not recognize returns 200 with usage omitted; "never seen" and "nothing consumed" are deliberately indistinguishable, so that a query cannot be used to discover whether a person holds an account. Unrecognized thumbprints are handled differently and for a stated reason . invalid_request, using the error response format of (), is returned for a body carrying more than one scope key, carrying neither a scope key nor jkts, carrying a scope key from an access server without ps, or carrying a malformed value. A resource MAY rate-limit the endpoint, using the RateLimit fields () as on any endpoint. A PS SHOULD poll no faster than its decisions require.

Division of Labor The two issuer-facing channels answer different questions at different moments. The consumption record serves the re-authorization decision: it arrives in-band, resource-signed, at no round-trip cost, exactly when the issuer is deciding. The usage counters serve everything else: supervision between re-authorizations, settlement of allocations that expired unreported , mission totals, tenant-level exposure, how a person's spending divides among their agents , and the person's dashboard. A metered resource SHOULD implement both; the narrowing chain functions with the record alone. The agent's own view is neither of these: it is the AAuth-Budget header , scoped to the token it holds and to the request it just made.

Capability Negotiation This document adds budget to the AAuth Capability Value Registry. An agent that understands budget semantics — the budget claim, the AAuth-Budget header, and the reason values — SHOULD include budget in its AAuth-Capabilities request header, and in the capabilities parameter of its person token and auth token requests (, AAuth-Capabilities Request Header). The person token request is where a budget-aware agent first reaches its PS about a resource, so it is where the declaration first matters: This tells the resource up front whether the agent will read what it sends, rather than leaving it to rely on ignore-unknown-parameter behavior. It is the same negotiation interaction performs for requirement=interaction. Recipients MUST ignore unrecognized capability values. A resource MUST NOT withhold AAuth-Budget from an agent that did not declare the capability. The header is safe to ignore.

Errors Narrowing is never an error. A resource that will grant less than the agent asked for issues a smaller budget; a PS or AS that will allow less issues a smaller amount. No error is returned in either case. Errors are reserved for statements that cannot be reconciled:

Error	Status	Endpoint	Meaning
`invalid_budget`	400	Authorization endpoint	The `budget` object is malformed, or names a `unit` the resource has not declared in `budget_units`
`invalid_budget`	400	PS and AS auth token endpoints	The resource token's `budget.decimals` disagrees with the value declared for that unit in the resource's `budget_units` metadata, or the object is otherwise malformed
`invalid_request`	400	Usage endpoint	More than one scope key, neither a scope key nor `jkts`, or a malformed value

Error responses use the error response format defined in AAuth Protocol (). invalid_budget at the authorization endpoint parallels invalid_scope: the agent named something the resource does not recognize. A decimals mismatch at the PS or AS MUST be a hard reject rather than a narrowing. A mismatch means one of the two figures is stale, and guessing which one is worse than failing — the error modes are a budget interpreted a thousandfold too large or too small. A PS or AS that has no cached budget_units for the resource and cannot fetch the metadata MAY proceed on the resource token's decimals, which is signed by the resource. The cross-check is a defense against staleness, not against the resource.

Declining with Guidance A PS granting less than the resource offered needs no mechanism: the amount in the issued claim says it. A PS or AS that declines a token request outright on budget grounds MAY include suggested_budget in its error response body: a budget object whose unit and decimals are copied from the resource token, and whose amount is what the issuer would currently accept. It is guidance, not a grant — the agent's move is a fresh resource token at that figure and a new token request, with the usual consent and policy evaluation. In four-party access an AS's suggested_budget reaches the PS, not the agent. The PS relays it in the problem+json body with which it relays the AS's error to the agent (, Auth Token Delivery), with unit and decimals unchanged and amount lowered to what the PS would itself currently accept for the person where that is lower. That figure never exceeds the ceiling the PS holds , and the PS states it as an amount it would accept, not as the ceiling, which the agent does not learn .

Standing Authorization for Metered Inference Metered inference is the initiating use case for this extension and has a property that distinguishes it from most resource access: the agent needs it before it can do anything else, including decide what else it needs. Inference authorization is agent-scoped and standing. It is established at first PS contact, not per mission. The reason is a termination argument rather than a preference: a per-mission inference budget requires the agent to run inference in order to evaluate whether it needs more inference budget, and that evaluation itself consumes inference. A standing allocation terminates; a per-mission one does not. Mission-less auth tokens are already legal. mission_s256 is optional in a person token and therefore in everything derived from it, and the PS permission and interaction endpoints work with or without a mission. No new token type is needed for this pattern. Do not model the harness as a mission. A mission description is defined as human intent expressed in Markdown. Synthesizing an "operating mission" or "harness mission" to hold the inference budget would put a fabricated description into the content-addressed blob that every token carrying mission_s256 is bound to, and mission revocation — a kill switch for one piece of work — would then also be the kill switch for the agent's ability to think. Those are two distinct controls and conflating them is a mistake. Pre-mission inference runs on a mission-less auth token and lands in the person's usage with no mission attribution. Mission boundaries become natural auth token re-issuance points, which costs nothing: the agent is already talking to its PS to create the mission. AP-bundled inference is out of scope. Where the agent provider pays for the agent's inference, the agent token is the credential, the person server never appears, and nothing in this document applies. This is the common deployment today, and readers will otherwise assume the extension covers it. The case that does engage this extension is a harness written by the agent provider spending against the person's inference account — which is where a ceiling matters most, because the agent provider's software is deciding how much of the person's money to consume. A TPX provider adds agent support without touching its meter. A TPX provider already prices per token, reports cost in each response's usage, and enforces a person-granted budget as a hard cap — for human-driven apps holding OAuth grants. Serving agents means accepting AAuth auth tokens carrying budget beside those grants: two authorization envelopes over one metering core. Deployed this way, this extension is the AAuth binding of TPX. Neither envelope displaces the other. A person driving an app and an agent acting for that person are different situations, and a provider serving both has one meter under two front doors .

Security Considerations

The Header Is Unsigned AAuth-Budget is not signed, so an intermediary can lie about the balance. The failure modes are bounded. Understating remaining makes the agent re-authorize earlier than it needed to. Overstating it makes the agent hit an unexpected 401. Neither causes overspend, because enforcement is the resource checking metered consumption against the signed budget claim of the auth token — the header is a pacing signal, not the authorization. An implementation that needs the balance to be trustworthy rather than merely harmless can cover AAuth-Budget with an HTTP Message Signature on the response (), as the usage endpoint recommends for its own responses . It is not required here, and the difference is what each response is for. A usage response is a statement of what a person owes for, read by a party that may later have to hold the resource to it. A balance on a request response is a pacing signal the agent acts on immediately and re-reads on the next call, and signing every metered response to protect a figure that is superseded seconds later buys little for what it costs at inference volumes.

Budget Is Not a Substitute for Scope A budget bounds how much an agent may consume, not what it may do. An agent with a small budget at a resource that performs irreversible actions can still perform them. Resources MUST continue to enforce scope, and SHOULD NOT treat the presence of a budget as evidence that the person reviewed anything beyond the amount.

Over-Issuance Through Concurrency A PS that issues concurrent auth tokens without tracking their sum has authorized their sum, not any single one of them . A resource that aggregates non-atomically across concurrent requests can be driven past the ceiling by parallel calls. Both are implementation errors that produce real overspend, and both are easy to make.

Consumption Reports as Attack Surface The budget_consumed record is resource-signed and usage counters are served from the resource's authenticated endpoint, signed where the resource follows ; both are the resource's own account of what it metered. A resource that inflates them can induce a PS to authorize more than the person intended, or to refuse further authorization. An issuer SHOULD reconcile them against the person's billing relationship with the resource where one exists, and SHOULD NOT treat them as authoritative for anything other than its own next decision. Signing the usage response does not change this. It makes the resource committed to a figure rather than able to disown it, which is what stops it reporting one number to the person server and another to the biller. It does not make the meter honest, because the resource meters, reports, and signs. The person's bill is the record a dispute settles against, and a signed report is evidence of what the resource said, not of what it consumed.

Unit Substitution Because a resource may change the unit between what the agent requested and what it offers , a PS reading a budget claim must read unit and decimals rather than assuming the denomination the agent described in justification. The cross-check against budget_units in is the defense against a stale scale; there is no defense against a resource that misdenominates deliberately, and none is needed — that resource is equally free to ignore the budget it was granted.

Privacy Considerations A budget amount is financial information about the person. It travels from the resource to the PS in the resource token and back in the auth token, and appears in plaintext in the AAuth-Budget response header on every response. The consumption record and usage counters are more revealing than the budget itself: counters describe the person's spending at that resource over time and by mission, and the record itemizes one grant. All of it is visible to the person's PS by design — the PS is deciding on the person's behalf. The two channels differ in who else can read them. Usage counters travel only between resource and issuer, so tenant-scope and long-horizon figures exist nowhere the agent can see. The consumption record rides in the resource token, which the agent relays and can read. It names only the token the agent itself presented, and only as a jti and an amount — an agent learns nothing about the person's other tokens or other agents from it — and a resource that considers even that too revealing omits budget_consumed and serves the usage endpoint alone. Because AAuth-Budget is unsigned and unencrypted above TLS, every intermediary on the path sees the person's remaining balance at that resource, and the price of the request that produced the response. Carrying no cumulative figure bounds this: an intermediary sees what one call cost and what is left of one hour's grant, not the person's spending history at that resource. Deployments that consider even the per-call figure sensitive may omit the OPTIONAL cost member from the header, at the price of leaving the agent to derive it from successive remaining values.

IANA Considerations

HTTP Header Field Registration This specification registers the following HTTP header field in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" established by :

Header Field Name: AAuth-Budget
Status: permanent
Structured Type: Dictionary
Reference: This document,

JWT Claims Registration This document requests registration of the following claims in the IANA "JSON Web Token Claims" registry established by :

Claim Name	Claim Description	Change Controller	Reference
`budget`	Authorized spending ceiling at a resource	IETF	This document,
`budget_consumed`	What the presented auth token consumed, reported by a resource	IETF	This document,

AAuth Capability Value Registry This document requests registration of the following value in the AAuth Capability Value Registry established by AAuth Protocol (). The registry policy is Specification Required (, Section 4.6).

Value	Reference
`budget`	This document,

No Budget Unit Registry This document deliberately establishes no registry of unit values. Units are declared by each resource in its budget_units metadata, exactly as scope values are declared in scope_descriptions. See .

Implementation Status Note: This section is to be removed before publishing as an RFC. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs.

Implementations in Progress tokenpony (Infinite Logic PBC) meters LLM inference and implements TPX , an OAuth 2.0 profile carrying the same grant for human-driven apps. That deployment is live, and this extension is being added over the same metering core, with AuthGravity as the person server and Harness News as the agent, in four-party access. TPX is a complete deployment on its own: it needs no person server and nothing from this document, and the two specifications share no wire surface — one meter, two independent authorization envelopes. Regent Protocol is in production at get4agent.com (marketplace resource and provisioning server): allocations, refusals with required, the streaming cost-omitted mode, the usage endpoint, and sub-agent delegation. Its open-source resource/PS middleware regent-httpsig (Python, Apache-2.0) publishes test vectors. The editor is implementing this extension in several services. Implementation reports and test vectors are expected from these efforts and will be recorded here.

Document History Note: This section is to be removed before publishing as an RFC.

draft-hardt-aauth-budgets-00
- Initial submission, written against draft-hardt-oauth-aauth-protocol-11.

Acknowledgments The author thanks Abay Aubakirov, Alex Polvi, and Karl McGuinness for feedback on early drafts.

References Normative References HTTP Signature Keys Hellō Cloudflare AAuth Protocol Hellō HTTP Caching Structured Field Values for HTTP Informative References Agent Payments Protocol (AP2) Google EIP-20: Token Standard AAuth Rich Resource Requests (R3) Hellō RateLimit header fields for HTTP Team Digitale, Italian Government Red Hat Microsoft ISO 4217:2015 Codes for the representation of currencies International Organization for Standardization Variable Recurring Payments Profile, Read/Write Data API Open Banking Implementation Entity ODRL Vocabulary and Expression 2.2 W3C Stripe Issuing: Card spending controls Stripe TPX: Token Pony Express — An OAuth 2.0 Profile for Metered LLM Inference Grants Infinite Logic PBC Payment Request API W3C x402: HTTP 402 Payment Protocol x402 Foundation

Design Rationale

Why an Integer in a Declared Scale Why not a Structured Field Decimal. , Section 3.3.2 caps a Decimal at 12 integer digits and 3 fractional digits, with round-half-to-even serialization. Inference is priced per million tokens, so a single call can cost on the order of $0.000015, which serializes to 0.000. The header would report zero consumption on every request while the person receives a bill. Why not a binary float. IEEE 754 cannot represent 0.1 exactly, and a budget is a running sum, so the error accumulates rather than cancelling. No monetary prior art surveyed in uses a float. Why not a decimal string, which is what most monetary prior art does use (, ). An integer in a declared scale is the only representation under which the Structured Field header value and the JWT claim value are the same number. A decimal string in the claim beside a Structured Field Decimal in the header would disagree at the third decimal place, and every implementation would have to define its own rounding to reconcile them.

Why the Scale Is Explicit x402 omits a scale because the asset contract address is the unit and the scale comes from the contract, immutably. USD does not work that way. ISO 4217 fixes the minor unit for USD at 2, and 2 decimal places cannot express a fifteen-microdollar call. The resource is therefore choosing a scale that the unit identifier does not determine, and a scale that is chosen has to travel with the amount.

Why decimals Is in the Signed Claim decimals is declared in budget_units metadata and also carried in the budget claim. The duplication is deliberate, and the reason is not primarily an attack argument — the resource is the enforcer, and a resource willing to reinterpret the scale is equally willing to ignore the budget outright. The reasons are versioning and self-description:

Versioning. Auth tokens live up to an hour. A resource changing its declared precision as an ordinary product decision — cents to micro-dollars — would silently reinterpret every token in flight by a factor of ten thousand.
Self-description. The resource is not the only reader. The PS ledgers against the number, the person's dashboard displays it, a proxy logs it, a dispute cites it. Each would otherwise have to resolve the number against mutable metadata fetched at some unspecified later time.

Why One Record An earlier revision carried up to twenty consumption records in the resource token, one per recent grant, so that a PS re-deciding saw the person's recent spend at the resource without a round trip. Working through the issuer's ledger, the presented token's figure is the only one that is news. Every prior token either came back through the same path when it was retired, in which case its record already arrived, or expired unreported, in which case the conservative rule holds until a usage reading settles it — and a reading settles every expired allocation at once, without naming any of them. The prior records cost roughly a kilobyte in the 401 header and let an agent read what was spent under tokens it never held, including the person's other agents'. The one thing the list uniquely offered — sibling-token spend at a checkpoint — is what the per-key query at the usage endpoint answers, per agent rather than per token, on a channel the agent is not on. The jti stays. Concurrent tokens are the normal case for an agent running several missions, and an issuer holding several live allocations for one agent cannot tell from an amount alone which of them a figure belongs to. The alternative — attributing by agent key and falling back to the conservative rule when ambiguous — makes the fallback the normal case for exactly the agents doing concurrent work. One short claim keeps the figure attributable and idempotent per token.

Why the Agent Is Not Told Its Cumulative Consumption An earlier revision of this document carried a consumed member in the header, giving what had been consumed against the auth token to date, and a balance_endpoint where the agent could read the same figure on demand. Both are gone. The agent is told what a request cost and what is left; cumulative consumption is reported to the person server and not to the agent. Four reasons. The figure is redundant. granted is in the auth token the agent signed the request with, and remaining is in the response, so cumulative consumption is granted - remaining whenever nothing is reserved. Carrying a member the recipient can already compute is weight without information. The word is already spoken for. A consumption record is a {jti, consumed} pair where consumed means the total metered against one token's whole budget. A person server reads those records and this header's semantics against each other. Having consumed mean a per-request figure in one place and a per-token total in the other is the kind of collision that survives review and then costs an implementer a day. Cumulative spend is the more revealing figure. It describes a pattern rather than a transaction, and AAuth-Budget travels unsigned past every intermediary on the path . What the agent genuinely needs per response is the price of the call it just made and whether it can afford another. Both are per-request facts, and that is what the field now carries. There is a fourth reason that applies across tokens rather than within one. An agent holding its cumulative consumption over a series of allocations can watch the series and infer the ceiling behind it — how much the PS is willing to release, and how fast. The ceiling is deliberately not disclosed , and a per-token figure that reconstructs it by subtraction discloses it anyway. The balance_endpoint went with it. It was OPTIONAL, existed for one case — an ambiguous failure, where the agent cannot say whether a request was metered — and cost a resource an endpoint to implement and this document a section to specify. That case is now answered by a rule the agent applies locally : assume the maximum until a later remaining says otherwise. A conservative default that every agent applies is better than an optional round trip that some resources offer.

Why the Granted Budget Is Not the Person's Ceiling A person server could authorize the whole of a person's intended spend at a resource in one auth token and let the agent draw it down. TPX does the OAuth equivalent: the budget sits on a durable grant, the app spends against it unsupervised, and the person hears about it when the grant runs dry. This document does not, and the difference is not a missing feature. The figure is not knowable when it would have to be fixed. A mission is approved before the work is done, and the work is what determines the cost. A person asked at approval for a number is guessing. Too low and the agent stops mid-task and the person is interrupted anyway. Too high and the number is not a control, because the agent will never reach it and nothing is checked before it does. An allocation sized against what the work has actually cost so far does not require the guess to be right. A ceiling the agent can read is a ceiling the agent plans against. An agent that knows it has been authorized for a pool treats the pool as available. An agent that knows only its current allocation asks when the allocation runs out, and asking is what puts the PS back in the decision. The justification accompanying that request, and the consumption records arriving with it, are the person server's evidence — and neither exists if the agent never has to come back. The check-in is the point, not a cost of it. Re-authorization is where the PS reads what the last allocation bought , compares it against the mission, and chooses among its six responses — including the two that are not a number at all: asking the agent to account for the spend, and ending the work. A single up-front grant has no such moment. It has one, at approval, when the least is known. This is why the ceiling appears nowhere on the wire. There is no claim for it, it may not be shared with the agent, and cumulative consumption that would reveal it by subtraction is withheld as well . What the resource enforces is the allocation in the token in front of it. What the person authorized is a matter between the person and their PS.

Why a Trailer Only Adds a Member AAuth-Budget may be sent as a trailer, carrying cost for a response whose cost was unknown when the header was written . This document rejected trailers in an earlier revision, on the reasoning of the RateLimit work (): intermediaries drop them, and combining a header value with a trailer value complicates clients. The first objection carries less weight here. It is largely a browser property — fetch does not surface trailers — and the traffic this document governs is an agent calling a resource, which is server-to-server and commonly HTTP/2. Where a trailer is dropped anyway, rule 3 of makes that harmless. The second objection is the real one, and answers it structurally rather than by mandating client behavior. A recipient may discard trailer fields or merge them into the header set, and a sender can neither observe nor control which. Restating a member across the two would therefore produce a value that depends on the recipient's choice: AAuth-Budget is a Dictionary, duplicate keys resolve last-wins (, Section 3.2), so merging yields the trailer's value and discarding yields the header's. Adding a member that the header did not carry has no such fork. Merge yields a complete picture, discard yields a conservative one, and neither is wrong. This is why reserved is a statement about a request rather than a running balance. A running figure would go stale the moment the reservation was released, and a stale member surviving a merge is exactly the failure the rule exists to prevent. What was held for a request does not change after the fact.

Why Not RateLimit RateLimit and RateLimit-Policy () already report a server-side quota and its remaining balance. Reusing them would avoid a new header. Four things prevent it, all following from a budget being an authorization rather than a capacity hint:

Stated non-goal. The RateLimit specification excludes authorization from its scope. Reporting the balance of a PS-issued grant through a field whose own specification says it is not for access control is a misuse a reviewer will name.
No unit carrier. q and r MUST be non-negative Integers, and the quota units registry covers request, content-bytes, and concurrent-requests. There is no currency carrier, so the denomination would be invisible in the field reporting the number.
Opposite reliability contracts. RateLimit says servers need not send the fields on every response, clients must not assume future responses will carry them, and a positive r is not a guarantee of anything. Those are correct properties for a capacity hint and wrong ones for the remaining portion of an authorization, which is why requires the field on every response the metering layer answers rather than leaving it optional.
Intermediary rewriting. Intermediaries MAY tighten RateLimit values. An intermediary tightening a budget balance is forging authorization state.

The two fields are complementary and MAY appear on the same response. A resource limiting an agent to 100 requests per minute and to five dollars of spend is stating two different things, and collapsing them loses one.

Why Budget Is Not a Mission Aggregate A mission description may well say "budget around $5,000," and the obvious next step is to make that a protocol object the PS enforces across every resource the mission touches. This document does not, for two reasons. The resources in a mission meter in units that do not add up. An airline meters in USD, an inference endpoint in micro-dollars or tokens, a storage service in gigabyte-months. Aggregating requires conversion rates and a common denomination, neither of which the protocol has, and both of which change. More fundamentally, the enforcement point is wrong. The party that can enforce a per-resource ceiling is the resource, because it meters. No party meters the mission. A mission-level total is a PS policy input — the PS decides how much of the person's $5,000 to authorize at each resource as it goes — which is exactly what the narrowing chain in gives it. The mission description already carries the person's intent, and the PS already reads it.

Why Units Are Not Registered RateLimit establishes an IANA registry of quota units because its units — request, content-bytes, concurrent-requests — are protocol-generic and every server means the same thing by them. Budget units are not generic. A unit is meaningful only against a resource's own pricing, and the parties that need to interpret it are the resource that declared it and the PS that fetched the resource's metadata. This is the same situation as scope values, which the base protocol leaves to each resource's scope_descriptions rather than registering. Registering USD would add nothing that ISO 4217 does not already provide, and registering tokens would suggest an interoperable meaning that does not exist. No registry does not mean no constraint. A monetary unit SHOULD be an ISO 4217 alphabetic code , which is what keeps a consent screen able to render "$5.00" rather than a resource-invented string the person has to interpret. What is left unregistered is the non-monetary case, where no external register exists to point at.

Prior Art This section is non-normative. It records where the field shapes and value encodings in this document come from, and what gap remains.

RFC 9396, Rich Authorization Requests (OAuth WG, May 2023), Section 2.2 defines the complete set of common data fields for an authorization detail: type, locations, actions, datatypes, identifier, privileges. There is no amount or quantity field among them. instructedAmount appears only in the document's examples and belongs to the payment_initiation authorization details type, which comes from Berlin Group NextGenPSD2 and carries ISO 20022 ActiveCurrencyAndAmount semantics; it is not defined by RFC 9396. Section 10 states that registration of authorization details types with the AS is outside the specification's scope, and Section 14 registers the request parameter, the claim, the metadata fields, and the invalid_authorization_details error — but establishes no registry of types. Section 6.1 is the load-bearing citation: there is no standardized mechanism for comparing two arbitrary authorization detail requests, and an AS should not rely on simple object comparison. AAuth Budgets closes that gap for one narrow case. Because the unit is resource-declared and the value is an integer in a declared scale, "is this grant less than the prior one" is a numeric comparison rather than a structural one. R3 () covers why AAuth does not profile RAR generally.

TPX TPX is an OAuth 2.0 profile for metered LLM inference grants: apps ship without provider keys, and the person grants each app a metered budget from a provider the person chooses and pays. The budget rides RFC 9396 authorization_details as {type: "llm-inference", budget, models}; the user or provider MAY grant less than requested and the client MUST read the granted figure from the token response — the requested/granted split of the narrowing chain , in OAuth form. Three of its mechanisms have direct counterparts here. Its GET /credits spend summary and budget_used introspection member report cumulative spend on a grant, which this document reports to the person server rather than to the agent . Its separation of budget_exhausted from balance_exhausted is the same boundary draws between re-authorization and payment. And its budget is "a damage cap, not a payment" — the hard-cap property states, which TPX asserts as a property of the grant and this document additionally realizes with reservations, since an agent's operations are unbounded before generation. TPX denominates in USD as decimal JSON numbers with at most six fractional digits, where this document uses an integer in a declared scale . TPX serves human-driven apps over OAuth; describes the deployment where one provider's meter serves both envelopes.

UK Open Banking Variable Recurring Payments ControlParameters is the most complete standing-budget model in production: MaximumIndividualAmount, MaximumCumulativeAmount, MaximumCumulativeNumberOfPayments, and PeriodicLimits[] carrying PeriodType and PeriodAlignment. PeriodAlignment — Consent versus Calendar — names the choice the usage counters make: calendar alignment, with the timezone question answered by fixing UTC.

Stripe Issuing Spending Controls spending_controls.spending_limits[] is {amount, interval, categories}, with amount an integer in the currency's smallest unit. interval spans per_authorization through all_time, which is the precedent for expressing a per-transaction cap and a periodic cap in a single enumeration rather than two fields; the usage counters adopt the date-based portion of that enumeration directly. Stripe computes all date-based intervals from midnight UTC — the precedent for fixing UTC by definition — and documents spending aggregation as best-effort with up to 30 seconds of delay, the precedent for as_of.

W3C Payment Request API PaymentCurrencyAmount is {currency, value} with value a decimal string. It is reused by Google's Agent Payments Protocol in CartMandate. AP2's IntentMandate carries a maximum price, an expiry, and a merchant allowlist as user-signed constraints, which is the closest prior art to a user-authorized agent ceiling.

x402 carries maxAmountRequired as a string in the asset's atomic units, alongside asset (a contract address) and network; v2 renames the field to amount and moves network to CAIP-2 form. There is no currency field: the asset identifier is the unit, and the exponent comes from the contract. This is the precedent for using a unit identifier rather than a currency field, and for decimals as the name of the scale.

ODRL payAmount with unit is the precedent for a field literally named unit holding a currency code.

RateLimit Header Fields (HTTPAPI WG, Standards Track, not yet an RFC) defines RateLimit-Policy with q, qu, w, and pk, and RateLimit with r, t, and pk, both as RFC 9651 Lists. It establishes an IANA RateLimit Quota Units registry (Specification Required) with initial entries request, content-bytes, and concurrent-requests, and three RFC 9457 problem types: quota-exceeded (429), temporary-reduced-capacity (503), and abnormal-usage-detected (429). It is cited here for why AAuth-Budget exists separately , for the trailer rules , and for pk as the precedent for a documented, client-predictable partition key.