RFC 012: Formalize tool.call payload extension for accounting detail - #18
Open
brettin wants to merge 1 commit into
Open
RFC 012: Formalize tool.call payload extension for accounting detail#18brettin wants to merge 1 commit into
brettin wants to merge 1 commit into
Conversation
…ail. Co-authored-by: Cursor <cursoragent@cursor.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds RFC 012, which requests extending
tool.callpayload accounting detail beyond a singletokenCostinteger—optional fields such asinputTokens,outputTokens,modelId,provider,modelTier,spendUsd, anduncertainty(Option A recommended), or a siblingtool.call.detailevent (Option B). Blocked on RFC 011 and RFC 004. Disposition: Hold.RFC document
Full text of
contracts/rfcs/012-tool-call-extensibility.md(also in this PR's Files tab):runId | toolName | status | latencyMs | tokenCost
Semantics
want to populate them keep emitting the minimal five-field payload unchanged.
tokenCoststays required as the total.inputTokens + outputTokensisnot required to equal
tokenCost— providers report differently;implementations should clamp negative values to zero.
spendUsdis the provider-reported billable amount, not a normalizedcross-provider estimate (deliberately leaves cost-modeling to consumers).
uncertaintyexists in the schema today(
uncertainty.schema.json) buthas no carrier on
tool.call; this adds the carrier.Backward-compatible — existing fixtures and emitters remain valid.
Option B — Canonical
tool-call-detail-event.schema.jsonsiblingKeep
tool-call-event.schema.jsonstrict. Add a new event typetool.call.detailwith the additional fields plus a requiredrelatedEventIdpointing back to the parenttool.call. Add it to theevent-envelope.schema.jsononeOf.Trade-offs
tool.callevent; explicit two-eventcontract every implementer can rely on.
join discipline is the implementer's responsibility; emit-path failures
become two-stage (the parent succeeds, the detail can fail silently).
Recommendation
Option A. It collapses the join, keeps the schema honest about what the
field set actually represents, and matches the already-merged spirit of
GAP-002. Option B is a viable fallback if backward compatibility on theexisting five-field shape is paramount.
Coordination with RFC 004
RFC 004 is the agenda item for the budget
allocate/enforce contract. If RFC 004 lands first and chooses field names like
spentUsdorinputTokenCount, this RFC's field names should follow thatchoice. We propose coordinating the naming pass at PR-review time.
Deferred (out of scope for this RFC)
additionalProperties: falsevs.extensionPolicytension exists onpolicy-check-event,reasoning-node-event,classification-shift-event.RFC 011 sets the precedent on
Run;this RFC follows for
tool.call; a later RFC should sweep the rest.spendUsdas theprovider-reported number; whether ARIA standardizes a normalization function
(or a cost-conversion companion schema) is a separate question.
populate usage at the same iteration point as non-streaming calls. Whether
tool.callshould distinguish stream vs. non-stream emission is a separateaccounting RFC.
Platform v0 alignment (out of scope)
x-gmp.tool.call.tokens)tool.call.payloadprovider,modelId,modelTierspendUsdtool.call; lives on related reasoning/eval payloadsuncertaintyref ontool.call.payloadPlatform reference
ARIAPlatform
platform-v0-implementation-profile.json—
ToolCallEvent,BudgetAllocate,EnforceBudget. ARIAPlatform v0 sketchesthe budget side of accounting but does not yet ground the per-call data the
budget endpoints need to do their job; this RFC closes that loop.