Limits can change as capacity and model availability change. Treat response headers and API errors as the runtime source of truth rather than hardcoding a quota into your application.
Free access
Free access does not mean unlimited capacity. Applications must handle rate limits and temporary unavailability gracefully.
Rate limits
When a limit is reached, the API returns HTTP429 Too Many Requests.
Your application should:
- Stop sending immediate retries.
- Respect
Retry-Afterif the response includes it. - Otherwise wait using exponential backoff with small random jitter.
- Give up after a limited number of attempts.
- Show the user a clear, temporary error.
Tokens and context
Models process text as tokens. Both your input and the generated output count toward the model’s context capacity.
Tokenization differs between languages and models, so word counts are only rough estimates.
Keep requests efficient
- Keep system instructions specific and remove repetition.
- Send only conversation history needed for the next answer.
- Summarize older turns in long conversations.
- Use
max_tokenswhen the endpoint and selected model support it. - Cache deterministic results that are safe to reuse.
- Avoid sending the same request repeatedly after a permanent error.
- Limit concurrent requests in background jobs.
Request too large
An oversized request commonly returns a400 error. Reduce one or more of:
- The user input
- Included documents
- Conversation history
- Requested maximum output
Design for changing capacity
For production-like prototypes:- Set a connection and response timeout.
- Handle
429,500, and503as temporary failures. - Queue background work instead of starting unlimited parallel requests.
- Track success rate and latency without logging private content or API keys.
- Provide a fallback message when the service is unavailable.
Error reference
Decide which failures can be retried.
Best practices
Secure and stabilize your integration.