One request ran. Seven hit the $0.01 spend ceiling.

The ceiling was checked before another request could start.

The temporary API key had matching daily and monthly limits of 10,000 microdollars. The canonical request reserved exactly 10,000 microdollars before routing. That made one active reservation equal to the key’s entire ceiling.

The run started one holder request first. Infer persisted the request as reserved, persisted one provider attempt as started, and held the one-cent wallet reservation. Only then did the seven contenders leave a synchronized barrier. Their dispatch times spanned 0.638 ms.

Each contender returned in 553.380–556.326 ms. All seven completed before the holder, while its request was still reserved and had no receipt. This matters: the observation covers committed-spend enforcement, not just two threads colliding on the same database lock.

The request settled for less than the reservation.

The holder completed in 1,936.356 ms. Its final customer charge was 43 microdollars, or $0.000043. Infer returned the unused 9,957 microdollars to the wallet during settlement.

The request and receipt reference the same immutable price version. The recorded customer rates were $0.39 per million fresh input tokens, $0.01 per million cached input tokens, and $0.77 per million output tokens.

Postflight reconciliation found one balanced inference_reserve transaction and one balanced inference_settlement transaction. There was no release transaction, no remaining wallet reservation, no held balance, and no started attempt. The temporary key was revoked after every HTTP task reached a terminal state.

Readiness stayed available during admission.

A separate monitor sampled the application and database across the contender wave. Local and public readiness returned HTTP 200, the database probe succeeded, and no database lock waiter appeared. The highest observed readiness latency was 340.127 ms.

Public status listed 22 services and reported both the overall service and the selected model operational during preflight, overlap, and postflight. That is a dated observation, not an availability promise. Current status remains the source for deciding whether to send a paid request.

What this record does not prove.

This was one holder-first wave on one key, model option, price version, and product build. It does not prove the behavior of every model, client, key limit, future release, or failure mode. It does not disclose or attest an upstream supplier identity, and it is separate from Infer’s stricter supplier-evidence readiness standard.

A residual race remains part of the test boundary: if the holder fails very quickly and releases its reservation before a late contender reaches admission, another request can be admitted. The harness treats any second request or provider attempt as a failed, non-publishable run. The passing record contained exactly one of each.

The run did not disable Infer’s general fallback logic, and it does not prove zero retries inside an upstream adapter or provider path. It required exactly one eligible route before dispatch, so the product could create only one route-level attempt for the admitted request. A conservative preflight bounded the eight-call wave at $0.031032 of supplier exposure; the observed record contained one product attempt.

A prior aborted incident remains a separate non-publishable record and is excluded from this passing result.

Try the control with your own cap.

Create an account, verify the account email, add service credit, and create a API key with daily and monthly limits. Check current status for the selected model before sending a request. Infer checks the key ceiling during admission and includes the final charge in the completed response and receipt.