AIDiveIntro: la semana que se acortó
El límite semanal de Claude Code bajó un 17% a mediados de septiembre de 2026, cuando terminó la promoción de verano. Quienes tienen los planes más grandes cuentan ahora que el miércoles ya se les ha acabado la semana. El anuncio de Anthropic dice que los límites se subieron de forma permanente un 25%, y la publicación siguiente llama a ese mismo cambio una reducción del 17%.
Todas las listas de consejos para estirar el límite vienen sin un solo número. Este artículo le pone a cada solución uno medido y las ordena. Destacan dos resultados: casi la mitad de los tokens de un mes se fueron en subagentes, y una sola pausa larga hace que el siguiente mensaje reescriba la mayor parte de la sesión.
Qué cambió y cómo contar
Las mediciones de aquí salen de un mes de logs de Claude Code de un solo desarrollador: 455 sesiones y 63 398 solicitudes, del 3 de septiembre al 3 de octubre.
La promoción duró de mayo al 13 de septiembre y subió el límite semanal un 50%. El límite de cada ventana de cinco horas no se movió. A finales de agosto, la cuenta de desarrolladores de Anthropic anunció una subida permanente del 25%, y una publicación después el mismo hilo dice que equivale a una reducción del 17%. Las dos afirmaciones son ciertas:
| Periodo | Límite semanal (límite antiguo = 100) |
|---|---|
| Antes de la promoción | 100 |
| Durante la promoción (de mayo al 13 de septiembre) | 150 |
| Nivel permanente desde el 14 de septiembre | 125 |
De 150 a 125 es el 17% que la gente nota. Un usuario con dos de los planes más grandes escribió que llegar al 100% un miércoles nunca le había pasado antes. Otro, con el mismo plan, iba por el 86% un martes por la mañana. El recorte no es la única causa: a principios de septiembre salió un modelo más voraz, así que no todas las semanas vacías vienen de este cambio.
Desde tu lado puedes ver un porcentaje. La pantalla /usage reparte el uso reciente entre skills, subagentes, plugins y cada servidor MCP conectado, y avisa de los fallos de caché. Una tecla la cambia entre el último día y los últimos siete. Lo que no puedes ver es el tamaño del límite en tokens: Anthropic publica porcentajes y multiplicadores, nunca una cifra de tokens. Por eso todo lo medido a continuación está en tokens, para una sola carga de trabajo, y no es una parte de tu semana.
Contar tokens desde los logs tiene una trampa. El log escribe la misma respuesta varias veces, así que sumar todas las líneas da 18 600 millones de tokens. Contada una sola vez, la cifra es 9300 millones. Un recuento ingenuo casi duplica todo.
Subagentes: casi la mitad de la factura
Un subagente es otro Claude que tu sesión lanza para una tarea secundaria y que informa cuando termina. En el mes medido, los subagentes se llevaron el 48,1% de todos los tokens en 2631 ejecuciones.
| Medida | Parte de los subagentes |
|---|---|
| Todos los tokens | 48,1% |
| Tokens de salida | 63,9% |
| Ponderado como la lista de precios pública pondera la salida y las escrituras de caché | 55,3% |
Cada subagente paga además un precio de entrada. Antes de hacer nada, su solicitud inicial ya lleva una mediana de 47 117 tokens: las instrucciones, la lista de herramientas y la lista de skills, todo enviado de nuevo. Otra persona lo midió en otra máquina y encontró entre 16 000 y 21 000 tokens por lanzamiento en agentes cuyo propio prompt es diminuto. Como dice ese artículo, el archivo del agente es un error de redondeo dentro de su propio coste de lanzamiento.
El modelo es la otra mitad. Por defecto un subagente hereda el modelo de la conversación principal, así que pasar la sesión al modelo más grande pone también a todos los ayudantes en él. En los logs medidos, el modelo más pequeño atendió menos del 1% de las solicitudes de subagentes. La solución es una línea en el archivo del agente: un campo model con un modelo más pequeño para tareas como ejecutar tests o buscar archivos.
Eso deja dos hábitos. No uses un subagente para una tarea pequeña que puedes hacer en el sitio, y fija un modelo pequeño en los que conserves.
El límite de este resultado: nadie ha medido cuánto ahorra fijar el modelo como parte de la semana, y un modelo pequeño que necesita más turnos puede salir más caro. El 48% viene de un trabajo que se ramifica mucho. Tu parte está en la pantalla /usage.
La caché de cinco minutos que nadie menciona
Claude Code guarda tu conversación en una caché de prompts en el servidor, y leerla de nuevo cuesta una fracción de lo que cuesta enviarla otra vez. Para la sesión principal esa caché dura una hora. Para un subagente dura cinco minutos.
La documentación lo dice claramente: los subagentes tienen cinco minutos, incluso con suscripción, hasta que elijas más. Lo mismo vale para todo lo que queda fuera de la conversación principal, incluidos el trabajo en segundo plano y la compactación. Los logs medidos coinciden: todas las escrituras de caché de un subagente cayeron en el nivel de cinco minutos, y todas las de una sesión principal en el de una hora.
Un desarrollador en Reddit notó lo que eso provoca: uno de sus subagentes reescribió todo su contexto ocho veces en un solo día. La solución es una línea en el archivo de ajustes, "subagentPromptCacheTtl": "1h".
| Su medición | Antes | Después |
|---|---|---|
| Escrituras de caché | 12,2 millones de tokens | 3,0 millones de tokens |
| Ventana de cinco horas con cuatro subagentes | del 2% al 100% | del 0% al 22% |
Es un solo usuario comparando dos días distintos, no una prueba controlada. En los logs medidos aquí apenas importa: solo 95 de 41 790 solicitudes posteriores de subagentes (unas dos de cada mil) llegaron tras una espera de más de cinco minutos, aunque cada una reescribió unos 75 000 tokens.
Así que depende de cómo trabajen tus subagentes. Si esperan una compilación larga, una revisión o a ti, actívalo. Si trabajan en ráfagas cortas, déjalo, porque una caché que dura una hora cuesta más de escribir.
La pausa que reescribe toda la sesión
La caché de la sesión principal dura una hora. Tras una pausa más larga desaparece, y el siguiente mensaje no puede leer nada de ella. La documentación lo detalla: el mensaje que envías después de la pausa no encuentra la caché y reprocesa todo tu contexto.
| Pausa antes del mensaje | Solicitudes | Caché reescrita (mediana) |
|---|---|---|
| Menos de 5 minutos | 18 029 | 1176 tokens |
| De 5 a 60 minutos | 414 | 1327 tokens |
| Más de 60 minutos | 79 | 130 332 tokens |
La sesión típica contenía en ese momento 175 523 tokens, así que casi todo se escribió de nuevo. Además, el contador no trata igual una escritura que una lectura. Un desarrollador puso un proxy de registro delante de Claude Code y vigiló su ventana de cinco horas: según sus proporciones, un token escrito en la caché pesa unas cuarenta veces más que uno leído de ella.
Claude Code lo sabe. Cuando retomas una sesión grande tras una pausa larga, te ofrece retomarla desde un resumen. Acepta.
El hábito más barato llega antes. Cuando termines una tarea, limpia la sesión mientras la caché sigue caliente. Limpiar no cuesta nada y la siguiente tarea empieza pequeña. Compactar también sirve, pero compactar una sesión enorme es en sí una solicitud enorme.
Una pausa no es la única forma de perder la caché. Cambiar de modelo a mitad de sesión la vacía, porque cada modelo guarda la suya. En los modelos más nuevos, cambiar el esfuerzo no la vacía. Claude Code te pide confirmar un cambio de modelo mientras la caché está caliente, y ese aviso es la advertencia.
Los límites: 79 vueltas en frío son una muestra pequeña, y algunas siguen a una compactación. Un resumen también pierde detalle, así que esta solución cuesta algo de continuidad.
Esfuerzo: la solución que puede costarte calidad
El esfuerzo es cuánto tiempo se le permite pensar al modelo antes de responder. Hay cinco niveles, de low a max, y el pensamiento se factura como salida. El valor por defecto es high en la mayoría de los modelos y medium en los dos más nuevos.
La documentación dice que el presupuesto de pensamiento puede llegar a decenas de miles de tokens por solicitud y que el nivel más alto tiende a pensar de más. En los modelos más nuevos el pensamiento no se puede desactivar, así que el nivel es el único control.
Un desarrollador ejecutó las mismas 29 tareas reales en los cinco niveles:
| Nivel de esfuerzo | Coste medio por tarea | Tareas superadas (de 29) |
|---|---|---|
| low | 2,50 $ | 23 |
| medium | 3,15 $ | 28 |
| high | 5,01 $ | 26 |
| xhigh | 6,51 $ | 25 |
| max | 8,84 $ | 27 |
La calidad no siguió al coste. Medium superó más tareas que cualquier nivel por encima, y por dólar también dio más aciertos. En sus palabras, la curva parece tener su pico en medium. El equipo de Claude Code trabaja igual: uno de sus ingenieros construye en low o medium, revisa, y solo ejecuta la verificación en high.
La pega es la razón por la que esta solución puede costar calidad. En los problemas difíciles que eligió, low acertó cero veces de cinco y high acertó cinco de cinco. Un intento en low tardó dos minutos, uno en high treinta y tres.
Así que ajusta el esfuerzo al paso: medium para construir, high cuando un error sale caro (un bug en código antiguo, una migración, una comprobación final), max casi nunca. Los logs de sesión registran el esfuerzo de cada solicitud, así que puedes comprobar lo que ejecutaste de verdad.
Esos costes están en dólares sobre un modelo más antiguo, no en una parte de la semana; nadie lo ha publicado. Y un intento barato que falla y se repite cuesta más que uno que funciona.
Los consejos que pesan menos de lo prometido
Algunas soluciones aparecen en todas las listas y apenas mueven la aguja. Probarlas no cuesta nada. Simplemente, la semana no se fue por ahí.
Lo que se carga al inicio es lo único real de este grupo. Un artículo midió la solicitud inicial desde una carpeta vacía en 29 061 tokens, y en casi 39 000 dentro de un proyecto real. En los logs medidos aquí la solicitud inicial mediana es de 55 989 tokens, entre 15 764 y 105 020 según el proyecto. El comando /context muestra lo que hay ahí (archivos de memoria, skills, listas de herramientas) y nombra cada archivo de memoria que cargó. Recorta lo que nunca usas. La ganancia es modesta porque ese bloque se escribe una vez y se lee de la caché en cada turno posterior. Duele en un arranque en frío y en cada lanzamiento de subagente.
| Consejo popular | Medido |
|---|---|
| Quitar servidores MCP | 1350 tokens por 51 herramientas en tres servidores; 18 tokens por un servidor con una herramienta |
| Desactivar las sugerencias de prompts | 3 a 4% para un usuario; lo de "hasta el 10%" venía de una cuenta con contextos enormes |
| Filtrar la salida del shell | cerca del 0,1% del volumen total, medido por un colaborador de uno de esos filtros |
Las definiciones de herramientas se difieren por defecto ahora, y por eso los servidores MCP pesan tan poco. La documentación califica de pequeño el coste de las sugerencias de prompts. Los tres crecen con el tamaño de tu contexto, y los servidores cuestan más en modelos antiguos donde el diferido está desactivado. Desactívalos si quieres, pero no esperes recuperar la semana.
La tabla ordenada
Ordenadas por lo medido:
| Puesto | Solución | Medido | Pega |
|---|---|---|---|
| 1 | Menos subagentes y más baratos | 48,1% de los tokens; 47 117 por lanzamiento | Menos paralelismo |
| 2 | No retomar una sesión en frío | 130 332 tokens reescritos frente a 1176 | Un resumen pierde detalle |
| 3 | Esfuerzo: medium para construir | 3,15 $ frente a 5,01 $ por tarea; 28 de 29 superadas | Low falla en problemas difíciles |
| 4 | Caché de subagentes a una hora | De 12,2 millones a 3,0 millones de tokens de escritura de caché | Solo compensa si los subagentes esperan |
| 5 | Recortar lo que carga al inicio | +9744 tokens sobre una base de 29 061 | Se paga una vez por sesión |
Los tres populares (servidores MCP, sugerencias de prompts, salida del shell) no son por donde se fue la semana.
Los límites, sin rodeos: este ranking está en tokens, de un mes del trabajo de una sola persona, más mediciones de otras personas. Anthropic no publica el tamaño del límite en tokens, así que nadie desde fuera puede convertir esto en una parte de tu semana. Tu orden puede ser distinto, y la pantalla /usage te lo dirá.
Las dos soluciones más grandes son hábitos, no ajustes, y son gratis: lanza menos subagentes, y nunca retomes entera una sesión en frío.
