Límite de peticiones

Los proveedores fijan límites por razones sencillas. La capacidad es finita y compartida, y un script descontrolado no debe ralentizar a todos los demás usuarios. Los límites también contienen el coste y frenan abusos, como una clave robada usada para inundar un servicio. Sin ellos, un error en un bucle podría enviar miles de llamadas en un minuto. Piensa en una panadería que atiende una cola: dejar que un solo cliente compre todas las barras en el primer minuto es injusto para los demás, así que el panadero limita a cada persona, y un buen límite es solo un reparto justo escrito como número.

Los límites adoptan varias formas. Uno corto por minuto absorbe las ráfagas. Uno más largo, por día, acota el uso total, ya sea como ventana fija que se reinicia a una hora determinada o como ventana deslizante que mira siempre hacia atrás, sobre el último tramo de tiempo. Algunos servicios cuentan solicitudes, otros cuentan tokens, y algunos limitan además cuántas llamadas pueden ejecutarse a la vez. Los límites suelen depender del plan: un nivel superior obtiene un techo más alto.

Gestionar bien un límite es un pequeño oficio. Lee la cabecera Retry-After cuando está presente y espera ese tiempo. Si no, reintenta con espera exponencial y algo de azar, nunca en un bucle apretado. Reduce las llamadas guardando respuestas en caché y agrupando el trabajo, y reparte la carga en el tiempo. Y recuerda que un límite de peticiones no es un límite de gasto: quedarse sin saldo es otro error, con otro remedio. Las bibliotecas suelen encapsular esta lógica por ti, reintentando con educación y haciendo pausas; si escribes tu propio cliente, registra cada 429 con su marca de tiempo para ver si lo causan ráfagas o una carga sostenida.

La documentación de la API de NeverNo fija la regla. Cada cuenta dispone de un número de solicitudes de API por cada 24 horas deslizantes, según su plan. Al superarlo, las llamadas reciben un 429 con el código rate_limited hasta que la ventana avanza. También se aplica un límite corto por minuto, y entonces el 429 incluye una cabecera Retry-After. Cada llamada cuenta como una solicitud, sea cual sea el número de tokens o de imágenes, mientras que el punto de acceso que cuenta tokens no cuenta. Como la ventana es deslizante, la capacidad vuelve poco a poco a medida que envejecen las llamadas antiguas, y no de golpe a medianoche.

Las cifras exactas de cada plan están en la tabla de la documentación de la API, y no las repetimos aquí para que esta página no quede nunca desfasada. Quedarse sin créditos es otro caso: la API responde 402 con insufficient_credits. La suscripción Dev usa el límite de solicitudes de Pro+. Como la documentación es la fuente única de las cifras, un script debería leer el tope de ahí en lugar de fijar en su código una cifra adivinada, y tratar un aumento repentino de errores 429 como señal para frenar y poner su trabajo en cola.