Límites de uso

Hay dos cubetas, y no miden lo mismo.

El endpoint de tokens tiene su propia cubeta por client_id, también de 60 por minuto, para que una credencial válida no lo convierta en una fuente infinita de JWT. Es una razón más para cachear el token en vez de pedir uno por request.

#Los headers

Toda respuesta autenticada trae el estado de la cubeta, incluidas las de error: no hace falta acertar para saber cuánto queda.

HTTP/1.1 200 OK
X-Request-Id: 9f1c0a3e-7b2d-4f18-9a55-2c6e0d1b4a77
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 41
X-RateLimit-Reset: 1767222060

HTTP/1.1 429 Too Many Requests
Retry-After: 23
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1767222060

{
  "status": "error",
  "message": "Demasiados requests",
  "message_code": "rate_limit_exceeded",
  "data": [],
  "meta": { "request_id": "…" }
}

#Manejar un 429

• Respetá Retry-After. Es la espera exacta hasta que la ventana se libera; reintentar antes solo gasta otra unidad.
• Agregá jitter. Sin él, todos tus workers reintentan en el mismo instante y el 429 se repite en bloque.
• Si venís usando X-RateLimit-Remaining, frená antes de llegar a cero: es más barato esperar que rebotar.

import random
import time


def respect_rate_limit(response) -> bool:
    """Duerme lo que pide el 429 y avisa si conviene reintentar."""
    if response.status_code != 429:
        return False

    wait = float(response.headers.get("Retry-After", "1"))
    time.sleep(wait + random.uniform(0, 0.5))
    return True

#Los turnos son otra cosa

El límite por minuto cuenta requests, no consumo del modelo. Un turno puede durar minutos y gastar miles de tokens siendo un solo request.

El consumo de modelo lo gobierna la licencia del usuario titular: cada turno descuenta del pool de niucredits. Cuando se agota, el envío se rechaza aunque te sobre cupo de requests. El consumo se consulta en Analíticas.