How a Misread HTTP 429 Error Wasted Seven Minutes and Zero Output

A data-catalog governance system called ARGUS spent seven minutes producing no results during a 45-entity sweep because its retry loop mishandled HTTP 429 errors from an AI model provider. The system could not distinguish between a short-term burst-rate limit, which clears in seconds, and a daily token quota exhaustion, which resets only the next day. Both failure types returned the same 429 status code, but the critical difference was buried in the response body, which the HTTP client discarded before logging. The fix involved capturing the response body at the error boundary and introducing a dedicated BudgetExhausted exception that immediately stops retrying and retires the endpoint for the current sweep. The case highlights that error abstractions must preserve distinguishing details from API responses, not just surface-level status codes.