AI usage metering: keep credits, purchases and requests reconcilable

Define the unit before writing the balance label

A credit might represent tokens, a priced operation or an internal allowance. Document the conversion and whether different modalities use different rates. Avoid implying that an internal credit is a provider token unless that relationship is exact. Decide how input, output, cached content, retries and cancelled turns affect the charge. The rule should be stable enough to explain after an incident.

Use a ledger rather than a mutable number alone

Record grants, reservations, settlements, refunds and administrative adjustments with unique references. A displayed total can be derived from those events, but the underlying history explains how it changed. Protect against duplicated purchase notifications and replayed requests. When the client reconnects, it should fetch the authoritative state instead of applying the same local deduction again because a response was lost.

Reserve capacity before expensive work

Two simultaneous sessions can each see the same balance unless the backend coordinates them. Agree whether a request reserves a maximum allowance, a bounded chunk or another defined budget. Release unused reservations when work ends, with expiry and reconciliation for missing completions. A stuck reservation should not permanently strand the user’s balance, while automatic expiry must not permit unbounded unpaid processing.

Handle uncertain provider outcomes explicitly

A timeout may mean the request failed before processing or that processing completed and the response was lost. Store request identities and usage information when available. Define an “awaiting reconciliation” state instead of inventing a charge from incomplete evidence. If a usage field is unavailable for a particular mode, use a disclosed internal rule rather than claiming the provider returned precise token counts that it did not supply.

Integrate purchases with server verification

Treat StoreKit transactions as evidence to verify, not as an instruction from a client to add credits. Include refunds, restored purchases, subscription changes and delayed notifications in the test plan. An anonymous device account adds identity and recovery decisions: reinstalling, device changes and restoring an Apple purchase are not automatically equivalent to restoring every server-side credit grant.

Credit-ledger acceptance cases

• Submit the same verified purchase event twice and confirm that the allowance is granted once, with an explainable ledger entry.
• Run two requests against a nearly exhausted balance and inspect how reservation and settlement avoid spending the same allowance twice.
• Interrupt a request before final usage arrives and verify that support can explain the pending or reconciled result without editing the balance manually.

Require a reconciliation report at handover

Ask for sample ledgers covering success, duplicate delivery, cancellation, concurrent requests and refund events. Arte Soft’s published GPT Realtime Assistant provides a product context for discussing usage-based experiences, but a client ledger needs its own financial rules and validation. The engagement should leave operations staff able to trace a disputed balance without exposing raw conversations or manually editing production numbers to conceal an unresolved defect.

Relevant Arte Soft work

GPT Realtime Assistant — our own published product is our own product or engineering project. It provides context for the work we discuss here; it is not a claim of identical results for every client deployment.

Sources and further reading

• Apple: StoreKit ↗
• OpenAI: Realtime conversations ↗