Skip to main content
LLM.kiwi is currently free to use without a credit card. Usage limits protect reliable access for everyone.
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 HTTP 429 Too Many Requests. Your application should:
  1. Stop sending immediate retries.
  2. Respect Retry-After if the response includes it.
  3. Otherwise wait using exponential backoff with small random jitter.
  4. Give up after a limited number of attempts.
  5. Show the user a clear, temporary error.
Do not create many API keys to evade limits. That can degrade the service and may lead to access restrictions.

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_tokens when 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 a 400 error. Reduce one or more of:
  • The user input
  • Included documents
  • Conversation history
  • Requested maximum output
When processing a large document, split it at meaningful boundaries, process the sections, and then combine or summarize the results.

Design for changing capacity

For production-like prototypes:
  • Set a connection and response timeout.
  • Handle 429, 500, and 503 as 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.
Last modified on July 28, 2026