Anthropic recorta un 17% los límites semanales de Claude Code

Un recorte del 17% equivale, en la práctica, a perder una de cada seis unidades de trabajo semanal con el agente. Ese es el ajuste que Anthropic está aplicando a los límites semanales vigentes de Claude Code, según la información publicada por BleepingComputer.

Para quien usa Claude Code todos los días, el número importa menos que su unidad: no es una ventana corta que se recupera en unas horas, es el tope que define cuánto trabajo cabe en una semana.

Qué se sabe y qué no

La información disponible se limita al recorte porcentual sobre los límites semanales actuales. No hay detalle sobre si el ajuste se aplica igual a todos los planes, desde qué fecha, ni cómo se reparte entre modelos. Hasta que Anthropic lo concrete en su documentación de uso, lo razonable es tratar el 17% como una magnitud y no como una tabla, y comprobar el consumo real de la propia cuenta antes de replanificar nada. Tampoco conviene extrapolar a la API: los límites de Claude Code y el consumo por API son cosas distintas, y el titular habla solo de los primeros.

Por qué importa más de lo que parece

Los límites cortos se absorben esperando. Un tope semanal, no: si el equipo lo agota el jueves, el viernes se trabaja sin agente. Eso convierte el límite en una variable de planificación y no en una molestia puntual. Un equipo que había calibrado su semana asumiendo cierto margen tiene que recalibrarla con un 83% del presupuesto anterior, y las tareas que más consumen (refactors largos, migraciones, revisiones sobre repositorios grandes) son justo las que peor toleran quedarse a medias.

Hay además un efecto de segundo orden. Cuando el presupuesto semanal se estrecha, el incentivo es lanzar menos ejecuciones exploratorias y más ejecuciones bien preparadas. Es una disciplina sana, aunque llegue impuesta: cada tarea mal especificada que hay que repetir cuesta ahora un poco más que la semana pasada.

Cómo absorber el recorte sin trabajar menos

Lo que nos ha funcionado en ElephantPink va casi todo en la misma dirección: gastar contexto solo donde aporta criterio.

1. Modelo por tarea. Renombrados, formateos, extracciones mecánicas y generación de boilerplate no necesitan Opus 4.8. Haiku 4.5 o Sonnet 4.6 resuelven ese tramo con un coste bastante menor.
2. Contexto acotado. Releer un archivo de 2.000 líneas para cambiar tres se paga en cada turno. Leer rangos, mantener un CLAUDE.md corto y cerrar sesiones que ya no aportan nada es la palanca más barata que existe.
3. Delegar en subagentes. Un subagente devuelve la conclusión, no el volcado de los doce archivos que ha tenido que abrir para llegar a ella. El contexto principal se mantiene pequeño durante más tiempo.
4. Hooks para lo que no necesita criterio. Formateo, linting y tests en PostToolUse se ejecutan solos. Pedírselo al modelo en cada turno es pagar tokens por algo que hace mejor un comando de shell.
5. Servidores MCP que filtren. Un MCP que devuelve 400 filas para que el modelo se quede con tres está quemando presupuesto. El filtrado va en el servidor, no en el prompt.

Ninguna de estas medidas compensa por sí sola un 17%, pero juntas cubren bastante más que eso en la mayoría de flujos que hemos medido.

Lo que nos parece

Ajustar límites en un producto con coste marginal real es normal, y es preferible a la alternativa silenciosa de degradar la calidad por detrás sin decirlo. Lo que sí se le puede pedir a Anthropic es previsibilidad: cifras claras, aviso con margen y una forma sencilla de ver el consumo propio antes de chocar con el tope. El recorte fastidia, y aun así buena parte del trabajo que obliga a hacer (menos contexto inútil, más delegación) son cosas que ya deberíamos estar haciendo.