The rate-limit counter on my gpt-5-mini deployment decrements by

A developer reports that Azure OpenAI's rate-limit counter for gpt-5-mini deployments decrements by exactly the input token count, not by the documented formulas that include max_tokens. In 29 paired samples, 20 charges matched usage.prompt_tokens exactly, while 7 exceeded input after connection-error retries, and none matched input + completion. The behavior was identical across reasoning_effort settings, ruling out reasoning-budget effects, and contradicts Azure's documented worst-case ceiling and prompt + max_tokens formulas.

The rate-limit counter on my gpt-5-mini deployment decrements by x-ratelimit-remaining-tokens on a Global Standard gpt-5-mini 1M TPM, Sweden Central, API version 2024-12-01-preview , computed each charge as limit - remaining , and kept only responses where a single request finished within ±2 seconds so the delta was attributable to one call.Breakdown of the 29 paired samples: 20 charged exactly usage.prompt tokens examples: 8,329 / 13,605 / 40,073 / 93,837 2 within 5% of input + max tokens or max input, max tokens — probably coincidence 7 charged well above input — all retried after connection errors one request with 252,781 input tokens was charged 630,582, suggesting two attempts each hit by a character-based input estimate This rules out the documented formulas: - One request was charged 8,329 tokens with max completion tokens = 10000 . No formula involving max tokens — sum or maximum — can produce a charge below max tokens itself. input + completion matched 0 of 29. Completions aren't counted.- Behavior was identical with reasoning effort at minimal , low , and unset. Not a reasoning-budget effect. The Azure docs are contradictory. One section says the estimate "includes prompt text and count, the max tokens parameter setting, the best of parameter setting" — a worst-case ceiling reading. The 429 section commits to an actual sum: "prompt + max tokens." Neither matches reality. OpenAI's platform docs use max max tokens, character-based estimate — also doesn't match.So for a completed request, the counter visibly ends at exact input tokens with no max tokens component. What I can't observe externally: 1. Is the counter charged when the request arrives the documented prompt + max tokens estimate, later reconciled to actual input , or charged once at completion with the exact input? 2. If requests are charged on receipt, does the over-estimate get refunded, or is the refund delayed/aggregated such that it's invisible in my per-request delta? 3. For the retried requests, is each attempt charged independently against the remaining budget, or is there a deduplication window? Has anyone else seen this exact-input-only behavior? I'm especially curious if the charging-on-receipt theory holds — that would explain why max tokens never shows up in completed-request deltas. Next Cursor is losing its edge for my heavy coding workflows → /en/threads/8152/