Skip to main content
Provider rate limits restrict the number of requests or tokens you can consume within a time window. When you exceed these limits, the provider returns an HTTP 429 response and your request fails. Polyglot provides built-in retry policies to handle these transient failures, but sustained rate limiting requires application-level strategies.

Symptoms

  • HTTP status code 429 (Too Many Requests)
  • Error messages containing “rate limit exceeded,” “too many requests,” or “quota exceeded”
  • Requests that work in isolation but fail under load

Use the Built-In Retry Policy

Polyglot can automatically retry failed requests with exponential backoff and jitter. Retries are opt-in and explicit — you must attach an InferenceRetryPolicy to the inference builder:

Retry Policy Parameters

The delay between retries uses exponential backoff: baseDelayMs * 2^(attempt - 1), capped at maxDelayMs. The jitter strategy adds randomness to avoid thundering herd problems:
  • none — no randomness, uses the exact computed delay
  • full — random delay between 0 and the computed delay
  • equal — half the computed delay plus a random value up to half the computed delay

Length Recovery

The retry policy also supports automatic recovery when a response is truncated due to token limits:

Retry Policy for Embeddings

Embeddings requests use a separate policy class with the same interface:

Application-Level Throttling

When retries alone are not enough, implement request throttling in your application to stay within the provider’s rate limits:

Batch Requests to Reduce Volume

Instead of making many small requests, combine related questions into a single prompt when the use case allows:
This reduces the number of API calls from N to 1, dramatically lowering rate limit pressure.

Additional Strategies

  • Switch providers or models. Different providers and models have different rate limits. If one provider is heavily throttled, route some requests to another.
  • Upgrade your API plan. Most providers offer higher rate limits on paid tiers.
  • Cache responses. If the same prompts recur frequently, cache the results to avoid redundant API calls.
  • Use off-peak hours. Some providers have lower contention during off-peak hours, reducing the likelihood of rate limiting.
  • Monitor usage. Track your request volume and token consumption to anticipate rate limit issues before they affect users.