Suben los límites de la API de Claude: cómo entender los nuevos niveles Start, Build y Scale

Anthropic actualizó las Claude Platform release notes el 26 de junio de 2026: los rate limits de la API de Claude subieron, y los límites de Claude Sonnet y Claude Haiku ahora quedan alineados con Claude Opus en cada usage tier. Los usage tiers anteriores también se consolidaron en tres niveles más simples: Start, Build y Scale.

Según Anthropic, la mayoría de las organizaciones pasarán a un tier más alto, ninguna organización recibirá límites inferiores a los anteriores y los desarrolladores no tienen que hacer nada manualmente. Puedes revisar tu tier y tus limits actuales en Claude Console.

Notas de lanzamiento:

https://platform.claude.com/docs/en/release-notes/overview

Documentación de rate limits:

https://platform.claude.com/docs/en/api/rate-limits

Documentación de Rate Limits API:

https://platform.claude.com/docs/en/api/rate-limits-api

Lo más importante de esta actualización

Si solo usas la API de Claude para scripts ocasionales o herramientas pequeñas, quizá no notes el cambio de inmediato. Pero si ejecutas Claude Code, AI Agents, resúmenes por lotes, preguntas RAG o colas backend, esta actualización merece atención.

El cambio se puede resumir en tres puntos:

1. Los límites generales de la API de Claude subieron.
2. Los límites de Sonnet y Haiku se alinean con Opus dentro de cada usage tier.
3. Los usage tiers se simplifican a Start, Build y Scale.

¿Qué significa en la práctica? Antes, algunos desarrolladores tenían que revisar límites distintos al cambiar entre Opus, Sonnet y Haiku. Ahora la estructura de tiers y los límites por modelo son más fáciles de entender, algo útil para apps multimodelo, productos con Agents y plataformas internas.

Pero esto no significa que puedas abrir concurrencia sin control. La API de Claude sigue limitada por número de solicitudes, input tokens, output tokens y velocidad de crecimiento del tráfico.

Por qué importa a los desarrolladores

En muchas integraciones con Claude API, el problema real no es si el modelo puede responder. Es encontrarse de pronto con 429 después de pasar a producción.

Escenarios típicos:

1. Un script local envía cientos de archivos a Claude para resumirlos.
2. Una app con Agents ejecuta muchas llamadas a herramientas y solicitudes de contexto largo al mismo tiempo.
3. Un sistema RAG mete resultados de búsqueda, historial de conversación y system prompts en un solo prompt.
4. Una cola backend consume trabajos demasiado rápido y agota la capacidad de tokens en minutos.
5. Las solicitudes fallidas activan reintentos automáticos y empeoran la congestión.

La subida de límites ayudará a que algunas cargas corran mejor. Pero si tu app puede amplificar solicitudes, todavía tienes que tratar los rate limits con seriedad. Más límite es una buena noticia, pero el throttling, las colas y la estrategia de reintentos siguen siendo necesarios.

Cómo entender Start, Build y Scale

Los nuevos usage tiers quedan en tres niveles:

No copies números concretos desde un artículo. Claude Console y la documentación oficial deben ser la fuente de verdad. Los límites de Anthropic pueden cambiar según cuenta, organización, workspace, modelo y política de producto.

En términos simples: si solo escribes scripts de vez en cuando, lo importante es no subir demasiado la concurrencia. Si estás construyendo un producto real, trata Claude como un servicio externo que necesita planificación de capacidad, no como una llamada de función normal.

RPM, ITPM y OTPM siguen siendo clave

Los rate limits de la API de Claude no son solo “solicitudes por minuto”. La documentación usa con frecuencia tres métricas:

Muchos errores 429 no ocurren por exceso de solicitudes, sino por exceso de tokens. Por ejemplo, puedes enviar solo 10 solicitudes por minuto, pero si cada una lleva cientos de miles de input tokens, puedes chocar primero con ITPM. Al revés, si el prompt es corto pero el modelo genera informes largos en lote, puedes chocar primero con OTPM.

Por eso, al depurar no mires solo el número de llamadas API. Como mínimo, registra el nombre del modelo, workspace, input tokens, output tokens, estado de respuesta y número de reintentos.

Agents y tareas por lotes ganan más margen

La subida de límites también ayuda a solicitudes normales tipo chat, pero los beneficiarios más claros son Agents y tareas por lotes.

Una sola “solicitud de usuario” en una app con Agent puede esconder una cadena de llamadas a Claude API:

1. Leer archivos.
2. Resumir contexto.
3. Llamar herramientas.
4. Revisar resultados de herramientas.
5. Planificar el siguiente paso.
6. Producir la respuesta final.

Si varios usuarios lo usan al mismo tiempo, o si el backend también ejecuta trabajos por lotes, el consumo de tokens sube rápido. Con límites más altos, estas cargas tienen más margen y cambiar de modelo debería ser más fluido. Aun así, en producción conviene separar carriles: solicitudes online por una ruta de baja latencia, lotes por cola y tareas largas con límites de concurrencia propios.

No culpes solo al modelo por un 429

Cuando aparece 429, no conviene cambiar de modelo de inmediato ni subir los reintentos al máximo. Un orden de diagnóstico más útil es:

1. Leer el mensaje de error y confirmar si es rate limit, quota u otra restricción.
2. Revisar cabeceras de respuesta como limit, remaining y reset.
3. Calcular los RPM, ITPM y OTPM recientes.
4. Ver si frontend, backend, cola y SDK están reintentando al mismo tiempo.
5. Ver si tareas backend y solicitudes de usuario comparten la misma organización o workspace.
6. Revisar si un aumento reciente de tráfico activó acceleration limits.

La documentación de Anthropic también menciona acceleration limits cuando el tráfico sube de forma repentina. Es decir, aunque el volumen promedio parezca razonable, una subida brusca puede activar límites.

Al lanzar una función nueva, lo más seguro es abrir tráfico gradualmente. Por ejemplo, actívala primero para el 5% de usuarios y mira 429, latencia, consumo de tokens y curva de costos antes de mandar todo el tráfico a Claude API.

Rate Limits API encaja en monitorización

Anthropic también ofrece Rate Limits API para consultar la configuración de límites de organizaciones y workspaces. Es útil para monitorización interna, paneles de administración y scripts de operaciones.

Puede servir para:

1. Confirmar límites del workspace antes de desplegar.
2. Mostrar capacidad disponible a distintas líneas de negocio.
3. Explicar por qué staging funciona pero producción recibe 429.
4. Ajustar concurrencia de colas según los límites actuales.
5. Crear alertas de capacidad antes de que los usuarios reporten errores.

Pero no debe sustituir el throttling de la aplicación. Tu servicio sigue necesitando colas, límites de concurrencia, exponential backoff y un máximo de reintentos.

Qué cambiar ahora en tu código

Si ya usas Claude API, empieza por algunas revisiones prácticas:

1. Abre Claude Console y confirma si tu tier ya es Start, Build o Scale.
2. Revisa los rate limits actuales de los modelos que usas de verdad. No dependas de capturas antiguas ni de memoria.
3. Haz configurables la concurrencia, las solicitudes por minuto y los maximum output tokens.
4. Pon las tareas por lotes detrás de una cola, en vez de golpear la API con un for directo.
5. Usa exponential backoff para 429, con un máximo de reintentos.
6. Registra input tokens, output tokens, nombre del modelo, workspace y latencia de solicitud.
7. Si reutilizas contexto largo, evalúa prompt caching, pero no lo trates como si no contara para ningún límite.

Esta actualización es claramente positiva: la API de Claude tiene más capacidad y los usage tiers son más fáciles de entender. Para los desarrolladores, la acción correcta no es “enviar más fuerte sin pensar”. Es usar ese margen extra para ordenar la cadena de llamadas, la monitorización y la estrategia de reintentos. Así los límites más altos se convierten en estabilidad, no en una forma más rápida de llegar al siguiente cuello de botella.