Trescientos euros en una noche

Qué es y por qué importa

Si tu app llama a un servicio de inteligencia artificial, cada petición la pagas tú. No el usuario que pulsa el botón: tú, con la clave que has puesto en el servidor.

Casi siempre, sin embargo, nadie ha escrito un límite. Basta un bot, un script que se queda funcionando, alguien que hace clic cien veces o que ha encontrado tu clave: las peticiones salen una tras otra, también de noche, y solo te das cuenta cuando llega la factura.

Claude Code te escribe en un momento la función que llama a la IA. El límite, muchas veces, no: no lo añade porque nadie se lo ha pedido. Bastan unas pocas líneas de código y un ajuste, pero tienes que pedírselo tú.

Hacen falta dos protecciones distintas, y una no sustituye a la otra:

• El límite de peticiones está en tu código. Dice: esta persona puede hacer como máximo tantas peticiones por minuto. Lo escribe Claude.
• El tope de gasto está en el panel del servicio de IA. Dice: este mes no se pasa de esta cifra. Lo configuras tú, a mano.

El límite frena el abuso de todos los días. El tope es la red de debajo: te salva cuando el límite tiene un agujero, o cuando la clave acaba en malas manos y alguien la usa sin pasar por tu app.

1. El límite en el código

Abre Claude Code en la carpeta de tu app (desde el terminal: entras en la carpeta y escribes claude) y pega esto:

Mi app llama a un servicio de inteligencia artificial. Encuentra todos los puntos del código desde los que sale una petición a la IA. Luego:
1. pon un límite de peticiones por persona y por minuto en esos endpoints (por usuario si ha iniciado sesión, por dirección IP si no), con un mensaje claro tipo 'Demasiadas peticiones, inténtalo de nuevo en un minuto';
   si la app funciona en serverless o en varias instancias, el contador tiene que estar en un almacén compartido (por ejemplo Redis), no en la memoria del servidor;
2. comprueba que la clave de la IA esté solo en el servidor y nunca en el código que llega al navegador o al móvil;
3. al final explícame con palabras sencillas qué has cambiado y cómo probarlo.

Qué quiere decir, con palabras sencillas

• Endpoint: es la dirección de tu servidor a la que llama la app cuando el usuario pulsa el botón. El control va ahí, no en la app: un control en la app o en el navegador se salta en un momento.
• Por usuario o por IP: si la persona ha iniciado sesión, la reconoces por su cuenta. Si no, solo tienes su dirección IP. No es perfecto, porque varias personas pueden tener la misma IP y quien quiere abusar puede cambiarla, pero frena la mayoría de los casos.
• Almacén compartido: en un hosting serverless, y en general cuando la app funciona en varias copias del servidor, cada petición puede acabar en una copia distinta. Un contador en la memoria de una copia solo ve sus propias peticiones y se pone a cero cuando esa copia se apaga. Por eso tiene que estar en un sitio que vean todas: Redis o tu base de datos.
• Clave solo en el servidor: todo lo que llega al navegador o al móvil se puede leer. Una clave dentro de la app es, en la práctica, pública. Cuidado con las variables que algunos frameworks mandan a propósito al navegador, como las que empiezan por NEXT_PUBLIC_ en Next.js, VITE_ en Vite o EXPO_PUBLIC_ en Expo: la clave de la IA no debe estar nunca ahí.

Qué número elegir

El prompt no dice cuántas peticiones por minuto. Si Claude te lo pregunta, piensa cuántas veces usa esa función una persona real en un minuto y deja algo de margen. Mejor empezar bajo: subirlo después es fácil.

El límite por minuto solo no basta. Pocas peticiones por minuto, repetidas durante toda la noche, suman igualmente miles de peticiones. Si la función es cara, añade un límite diario:

Añade también un límite diario por usuario en las mismas peticiones a la IA, usando el mismo almacén compartido que el límite por minuto. Cuando se supere, muestra un mensaje claro tipo 'Has alcanzado el límite de hoy, inténtalo mañana'.

2. El tope de gasto

Esto lo haces tú, no Claude. Son dos minutos.

1. Entra en el panel del servicio de IA que usas y busca la parte de facturación o de límites de uso.
2. Configura un tope mensual. Elige un número que puedas permitirte perder en una mala noche.
3. Lee qué pasa cuando se alcanza el tope. Es el paso que casi todo el mundo se salta.

Ojo: no todos los servicios paran de verdad las peticiones al llegar al tope, algunos solo te mandan un aviso. Así que no te fíes del nombre del ajuste: comprueba en la documentación de tu servicio qué hace de verdad ese límite. La diferencia está entre «bloquea las peticiones» y «te manda una notificación».

Si tu panel solo ofrece el aviso, usa créditos de prepago con la recarga automática desactivada: cuando se acaban los créditos, las peticiones se paran. También aquí, comprueba que tu servicio funciona así antes de contar con ello.

Si la app usa otros servicios de pago, como el envío de SMS o los mapas, repite la misma comprobación con cada uno.

3. El aviso

En el mismo panel, si existe la opción, activa un email de aviso para cuando llegues a la mitad del tope. Ponlo en una dirección que leas de verdad.

El motivo es sencillo: un tope que bloquea las peticiones también frena a tus usuarios reales. El aviso a la mitad te deja tiempo para entender qué pasa, si es gente real usando la app o un abuso, antes de que la app deje de responder.

4. La prueba

Un límite que no has probado es un límite que no sabes si existe. Pídele a Claude:

Escribe un pequeño script que llame a mi endpoint de IA 30 veces en un minuto con el mismo usuario de prueba y dime cuántas peticiones pasan y cuántas se bloquean.

Si pasan todas, el límite no está funcionando: haz que te lo arregle antes de publicar.

• Haz la prueba en la versión local o de pruebas de la app, no en la que usan los usuarios. Las peticiones que pasan llegan de verdad a la IA.
• Si el límite que has elegido es más alto que 30 por minuto, sube también el número de la prueba, si no pasan todas aunque el límite esté bien.
• Si la app funciona en serverless, repite la prueba también en la versión de pruebas online. En local hay un solo servidor, y un contador guardado en memoria parece funcionar aunque online no funcionaría.

Errores comunes

• Poner el límite solo en la app o en el navegador. Se salta fácilmente: el control va en el servidor, en el endpoint.
• Guardar el contador en la memoria del servidor en serverless. Cada copia cuenta por su cuenta: usa Redis o la base de datos.
• Configurar el presupuesto en el panel y creer que estás cubierto. A veces es solo un aviso: comprueba qué hace de verdad y, si hace falta, usa créditos de prepago sin recarga automática.
• Dejar la clave de la IA en el código de la app o en una variable pública. Muévela al servidor y, si ya ha acabado en una app publicada, bórrala desde el panel y crea una nueva.
• Proteger un endpoint y olvidarse de otro. Pide a Claude que te liste todos los puntos desde los que sale una petición a la IA y comprueba que el límite está en cada uno.
• No probar el límite. Lanza el script de prueba antes de publicar, cada vez que cambies esas partes.

Lista de comprobación

• Límite de peticiones en cada endpoint que llama a la IA
• Contador en un almacén compartido (Redis o base de datos)
• Clave de la IA solo en el servidor
• Tope mensual configurado en el panel del servicio
• Comprobado si el tope bloquea las peticiones o solo manda un aviso
• Email de aviso a la mitad del tope
• Prueba de 30 peticiones hecha, con una parte bloqueada

Preguntas frecuentes