Trece chats de Claude medidos: un chat saturado no avisa de que ha dejado de ser fiable

Las trece sesiones, con sus números

Esta es la tabla que explica casi todo lo demás. Cada fila es una medición real de la herramienta de uso de sesión de Claude Code, con su hora.

Tres cosas de esa tabla merecen leerse despacio.

La ventana de 200.000 frente a la de un millón. La medimos en trece sesiones: 200.000 en tres y un millón en diez. Que esas tres fueran Haiku lo sabemos por la ficha de cada relevo, no por la medición. Con una ventana cinco veces menor, un trabajo idéntico llena la sesión en un día.

La carga fija. Antes de que nadie escriba nada, cada sesión gasta entre 47.360 y 109.634 tokens solo en herramientas, conectores MCP e instrucciones del sistema. En la mayoría está entre 60.000 y 70.000. Sobre un millón apenas se nota. Sobre 200.000 es la tercera parte de la sesión: en el PMP global eran 69.768 tokens, el 35 % de todo lo disponible.

El dato que no sabemos explicar. La sesión de Documentación devolvió 564.689 tokens sobre una ventana de 200.000. Es lo que dio la herramienta. No tenemos explicación y lo dejamos escrito tal cual.

Ocho fallos, con su causa y lo que costó cada uno

Un modelo que se queda sin contexto no empieza a dudar. Empieza a rellenar, con la misma prosa ordenada con la que acertaba media hora antes. Por eso ninguno de estos ocho casos se detectó leyendo: todos se detectaron midiendo.

El primero de la lista es el más instructivo, porque no parece un fallo. Un chat barrió los historiales buscando la instrucción que había parado su proyecto, no la encontró y concluyó por escrito que no existía, acompañando la conclusión de comprobaciones de control para dar confianza en el método. Un agente puede construir una demostración impecable de algo que es mentira.

Lo que se come del cupo, hora a hora

Resumir una sesión obliga al modelo a leerse entero el historial una vez para condensarlo. Si va al 95 % de un millón, son 954.835 tokens leídos de golpe. El coste crece con lo llena que esté, que es justo al revés de como suele hacerse.

Dos lecturas de esa tabla. La primera: el 30 de septiembre, una tarde de relevos con varias sesiones activas llevó el cupo de 5 horas del 4 % al 61 % en menos de dos horas. La segunda, más incómoda: el 5 de octubre pasó del 86 % al 96 % en ocho minutos.

El resumen de la sesión al 95 % costó en torno a 5 puntos del cupo de 5 horas. Es el dato más llamativo y el que menos se sostiene solo: el cupo es de toda la cuenta y en esos minutos podía haber otras sesiones trabajando. Era lo único grande que estaba pasando, pero no aislamos las demás. Vale como orden de magnitud, no como medición limpia.

Hay un coste menos visible. Cada mensaje enviado a una sesión llena arrastra todo su historial, y si lleva más de una hora parada la caché ha caducado y ese historial se procesa entero otra vez. Dejar trabajando un chat casi lleno cuesta en cada turno, y al final hay que resumirlo igual.

Resumir la sesión o abrir un relevo

Son dos operaciones distintas y se confunden porque las dos liberan espacio. Resumir conserva la sesión y comprime lo que hay dentro. Relevar abre una sesión limpia y le pasa por escrito lo que necesita saber.

El 1 de octubre medimos un resumen completo, el único que hemos observado. La sesión de Ingeniería había llegado al 95 % en menos de un día, con trabajo a medias sin guardar, y se detuvo al alcanzar el límite del plan. Ese fue el momento bueno, porque estaba quieta.

Se le dijo qué conservar: rutas, lo que estaba sin guardar y el informe de revisión pendiente. Después no siguió sola, porque el comando de resumen no lanza ningún turno. Hubo que darle el paso siguiente con las rutas, y entonces terminó la tarea, guardó el cambio y subió el paquete.

Esa última regla sale de dos casos: una sesión con diez resúmenes acumulados se atascó en un procedimiento que conocía bien, y otra con seis había olvidado un tope de gasto que se le había fijado y volvió a preguntarlo. Las sesiones dedicadas a un solo tema aguantan mejor varios resúmenes seguidos.

Hay una tercera opción que conviene no saltarse, porque la documentación de Claude Code la pone por delante del resumen: limpiar la sesión. No comprime nada, la vacía para empezar otra tarea, y existe la forma de volver después.

El error que más caro sale no es elegir mal entre las tres. Es no elegir, dejar la sesión trabajando al 90 % y pagar el historial completo en cada turno hasta que no queda más remedio que resumir, ya en el peor momento.

Los nueve relevos y sus preguntas de control

Un relevo no termina cuando se crea la sesión nueva. Termina cuando esa sesión demuestra que ha entendido, respondiendo preguntas cuya respuesta ya conocemos. Si no sabemos la respuesta, no es una pregunta de control: es una consulta.

En los seis primeros relevos se respondieron 37 preguntas de control sobre 37. Los tres posteriores suman 11 aciertos más y una revisión sin preguntas, en la que la sesión nueva fue a comprobar el trabajo del anterior y encontró cuatro decisiones y seis errores.

Dos columnas de esa tabla concentran el método. La de quién escribió la ficha: si la sesión que se va está llena, su resumen es un borrador, no una fuente. De tres fichas escritas por sesiones saturadas, las tres tenían errores y una era grave. Y la del contexto: una sesión al 100 % se releva, no se le pide que se explique.

Hay un caso que resume por qué esto importa. Una sesión de desarrollo estuvo parada del 12 al 30 de septiembre esperando que le confirmaran un encargo. La confirmación existía desde antes, escrita como regla permanente, pero había quedado sepultada por al menos dos resúmenes. Lo que no está en la ficha de traspaso, la sesión nueva no lo sabe, y lo que no sabe no lo pregunta: lo espera.

Qué es del modelo y qué de Claude Code

Casi todo lo anterior no es una propiedad de la inteligencia artificial en abstracto. Es de Claude Code, la aplicación de escritorio, y de cómo gestiona sesiones, herramientas y cupo. Separarlo importa porque cambia a quién se le pide el arreglo.

Ese último renglón es el que más nos interesa y el único que no podemos atribuir. Para separarlo haría falta reproducir el mismo trabajo contra la API, sin la aplicación de por medio, y no lo hemos hecho.

Qué dice la documentación oficial y dónde se queda corta

Empezamos este repaso esperando encontrar contradicciones entre la documentación de Claude Code y lo que medimos. Casi no las hay. Lo que hay es otra cosa, y para quien tiene que decidir resulta más útil: la documentación dice qué hacer y no dice cuánto cuesta no hacerlo.

Seis de seis confirmadas. Si alguien esperaba el titular de que la documentación engaña, no está aquí.

Lo que sí encontramos son comportamientos que la documentación no cubre porque no son el caso para el que está escrita, que es una persona con una sesión. Trabajando con varias a la vez aparecen tres:

Ese tercero es el que produjo el fallo más llamativo de todo el repaso, el del chat que demostró por escrito que una orden no existía. No fue un invento del modelo: fue buscar en el sitio equivocado y no saberlo.

Medido, deducido y sin datos

Esta tabla es la que sostiene todas las anteriores. Un documento interno nuestro daba por medidos dos datos que no lo estaban, y al contrastarlos aparecieron.

Quedan además tres preguntas abiertas que no hemos podido cerrar: cuánto se degrada una sesión con cada resumen, cuánto cuesta exactamente resumir al 60 % frente al 95 %, y por qué el archivado de una sesión parada falló alegando que tenía trabajo en marcha.

La conclusión que sí sostenemos es más incómoda que cualquiera de esas cifras. Una sesión que ha perdido contexto no se comporta como un sistema roto, que es lo que esperaríamos y sabríamos detectar. Se comporta como un compañero seguro de sí mismo que recuerda mal. Y eso no se descubre leyendo lo que escribe: se descubre yendo a comprobar lo que dice, cada vez, en la fuente.