In Mode A the gateway sees the provider's own usage block, so the commit is issued by infrastructure the tenant does not control. A misbehaving or crashing client cannot skip it.
In Mode B the client owns the commit. The reaper bounds the damage — an uncommitted reservation expires after 120 s — but a tenant that never commits will systematically over-hold quota and is detected by a per-tenant commit-ratio alert.
Mode C exists because batch work should consume leftover capacity rather than compete for it. Admission is evaluated at dequeue time, not at submit time, so a queued job never holds a reservation while it waits.
Numbers
Reservation TTL 120 s, chosen as roughly 4× the p99 completion latency of the slowest supported model.
Commit-ratio alert fires below 0.98 over a 15-minute window for any tenant on Mode B.
Mode C admission runs at 1 Hz per worker pool and consumes only capacity unused by interactive tiers.
Assumptions
Streaming responses are supported in all three modes; the commit is issued when the stream terminates, not when it starts.
Clients on Mode B are expected to send a commit even on failure, with a status field. A failed call still consumed input tokens at most providers.
