I've got an unrealistic Foundry bill, can someone help explain please?

Question

Hello,

I've got this graph showing my input tokens going over 4M tokens a minute couple days ago, which is not realistic since they were against one model that is rate limited to 40K tokens a minute.

Does anyone know how this could've happened? My bill is insanely high due to this :(

Answer 1

Hello Ismaeel AA,

Greetings! Thanks for raising this question in the Q&A forum.

The short version is that a single deployment physically cannot process 4M input tokens in one minute while it is capped at a 40K TPM quota, because Azure OpenAI enforces that quota by returning 429 errors once the running per-minute token count is reached. What you are almost certainly looking at is a metrics reporting or scope issue rather than 4M real tokens being billed against a 40K/min deployment. The most common causes, in order of likelihood, are below.

1. Check whether the chart is summed across more than one deployment

The Processed Prompt Tokens metric supports splitting and filtering by ModelDeploymentName, ModelName, ModelVersion, and Region. If your chart is not filtered or split by ModelDeploymentName, it silently aggregates every deployment under that resource (and if you have deployments in more than one region or resource, those are not included unless you widened the scope yourself, but multiple deployments under the same resource absolutely get summed together). Go to your resource, Monitoring > Metrics, add Processed Prompt Tokens, set Aggregation = Sum, then Apply splitting on ModelDeploymentName to see the number isolated per deployment rather than combined.

2. Confirm the time granularity actually matches what you're reading

These token metrics are collected at PT1M (1-minute) granularity. If the chart's time granularity control is set wider than 1 minute (5 min, 15 min, 1 hour) while you are reading the peak value as "per minute," the displayed number will be a multi-minute sum, not a single-minute value. Explicitly set the granularity to 1 minute before reading peak values.

3. Cross-check against actual billed usage

Go to Cost Management + Billing > Cost analysis, scope it to the subscription, group by Meter, and filter to the date in question and the Microsoft.CognitiveServices resource provider. Compare the billed token quantity for that day against what the metrics chart showed. If billed usage is in line with your normal traffic and the 4M figure only appears in the unfiltered metrics chart, this confirms it is a display aggregation artifact, not a real overage.

4. Rule out a leaked key or runaway retry loop

If diagnostic logging is enabled on the resource, review the logs for that time window for unfamiliar caller IPs, an unexpected spike in request count (not just tokens), or a client-side bug causing a retry storm. Rotate the API key as a precaution if you see anything you don't recognize.

5. When to escalate to Azure Support

If you complete steps 1 to 4 and the actual billed line items for that date genuinely reflect token volume far beyond what your application could have generated against that single rate-limited deployment, this becomes a metering/billing anomaly rather than something you can resolve yourself. Open a support request under Help + support > New support request, category Billing, and include:

• Subscription ID and the specific resource ID
• The exact UTC date/time window of the spike
• Screenshots or exported CSV of both the Metrics chart (filtered per deployment) and the Cost analysis breakdown for that period
• A note that the deployment's configured TPM (40K) makes the billed volume implausible under normal throttling behavior

Support can pull the backend billing records tied to that resource and confirm whether it was a metering defect eligible for a billing adjustment.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.