De Experto a Novato — Cuando el AI Assistant Llega al Límite

TL;DR

Los asistentes de IA tienen límites de contexto duros (Claude: 200K-1M tokens, GPT: 128K-1M según modelo)
Cuando alcanzas el límite, el modelo empieza a olvidar lo más antiguo, degradando calidad o fallando directamente
Estrategias válidas: chunking de sesión, compresión de contexto, checkpointing, y switching entre modelos según complejidad
Para producción: diseña tus agentes asumiendo que el contexto se acabará, no como reflexión posterior

El momento de la verdad

Hace unos días, un usuario compartía en Reddit una captura de su sesión con Claude justo antes de que saltara el límite de contexto: «me and claude 30 mins before hitting the 100% limit». La imagen muestra el contador de tokens en rojo, precipitándose hacia el máximo. No es un escenario teórico; es el día a día de cualquiera que use asistentes de IA para trabajo real.

El problema no es solo que «el contexto se llena». Es qué pasa cuando se llena, y cómo eso transforma a tu experto en un novato que empieza a cometer errores básicos.

Límites de contexto: la arquitectura dicta las reglas

Cada modelo tiene un tamaño de ventana de contexto fijo:

Modelo	Contexto máximo	Coste por 1M tokens (input)
Claude 3.5 Sonnet	200K	$3-$5
Claude 3.7 Opus	1M	$15-$30
GPT-4.1	128K	$10-$20
GPT-4.5 Turbo	1M	$15-$40
Gemini 2.5 Pro	1M	$7-$12

Estos números no son arbitrarios. La memoria de clave-valor (KV cache) escala cuadráticamente con la posición en muchos arquitecturas, por lo que doblar el contexto no significa doblar el coste, sino multiplicarlo por 4. Los límites son compromisos de ingeniería entre rendimiento y precio.

Lo crucial: el límite incluye tanto el prompt como la respuesta generada. Si envías 100K tokens de contexto y el modelo genera 20K, estás consumiendo 120K de tu cuota.

Qué pasa cuando llegas al límite

El comportamiento varía por implementación, pero en general:

Truncación silenciosa: El modelo recibe solo los últimos N tokens, olvidando lo más antiguo. Si tu sesión dura 2 horas, la primera hora se desvanece.
Degradación progresiva: A medida te acercas al límite, el modelo empieza a perder coherencia, repite conceptos, olvida instrucciones tempranas.
Error explícito: Claude devuelve context_length_exceeded. GPT-4 puede devolver 400 - context_length_exceeded. El API simplemente rechaza la llamada.
Caída en calidad: Incluso antes del límite, la atención (attention) se diluye. Un estudio de artificialanalysis.ai muestra que el rendimiento en benchmarks de razonamiento cae un 15-25% cuando usas el 80% del contexto vs el 20%.

El resultado: tu asistente, que ayer resolvía bugs complejos, hoy no recuerda qué variable definiste 15 minutos atrás. De experto a novato en una actualización de contador.

Estrategias de manejo de sesiones largas

1. Chunking explícito

En lugar de una sesión monolítica de 2 horas, divide en sesiones más pequeñas (ej: 30-45 min) con puntos de control. Cada chunk debe:

Tener un objetivo claro y delimitado
Incluir un resumen del chunk anterior (no el historial completo)
Persistir decisiones importantes en almacenamiento externo

Ejemplo práctico: un agente de refactorización de código podría:

Chunk 1: Analizar archivo, identificar problemas, generar plan (15 min)
Chunk 2: Implementar cambios según plan, con summary de hallazgos del Chunk 1
Chunk 3: Ejecutar tests, reportar resultados, revertir si falla

Cada chunk se ejecuta como una sesión independiente, pero el estado se pasa vía summary (ej: «Chunk 1 encontró 5 memory leaks en parser.py, parcheados en commits abc123, tests pasan en 8/10 casos»).

2. Compresión de contexto (context pruning)

No todo el historial es igualmente importante. Técnicas:

Eliminar turnos conversacionales triviales: «ok», «gracias», «entendido» no aportan valor.
Reemplazar código completo por diffs: En lugar de mantener el archivo entero en contexto cada vez, guarda solo los cambios (diffs) y el estado actual en disco.
Resumir errores y soluciones: Cuando encuentras y corriges un bug, resume: «Fix: null pointer en line 42 → add guard clause», en lugar de mantener el output completo del traceback.
Extraer «lecciones aprendidas»: Al final de cada iteración, genera un bullet-point de lo aprendido ydescarta el detalle granular.

Una heurística simple: cada 10 turnos, haz una pasada de «context review» y elimina lo no esencial.

3. Checkpointing y estado externo

Los agentes deben ser conscientes de que la memoria es volátil. Estrategias:

Registrar estado en base de datos o archivos: Variables críticas, decisiones de arquitectura, tokens de API usados.
Usar embeddings para recuperación semántica: Guarda interacciones en una base vectorial; cuando necesites contexto relevante, búscalo en lugar de pasar todo el historial.
Idempotencia: Diseña tareas para que si se reinician desde un checkpoint, el resultado sea el mismo.

4. Switching de modelo

No todos los pasos requieren el modelo más caro. Patrón común:

Fase 1 (exploración, brainstorming): modelo barato (Claude 3.5 Sonnet, GPT-4.1)
Fase 2 (razonamiento crítico, decisiones de arquitectura): modelo caro (Claude 3.7 Opus, GPT-4.5)
Fase 3 (writing, refinamiento): modelo barato otra vez

Esto reduce coste y, de paso, reduce la acumulación de contexto porque usas modelos con ventanas más pequeñas (más baratos) en las fases que generan menos contenido complejo.

Caveat: switching introduce inconsistencia en estilo y conocimiento. Si usas 3 modelos diferentes en una misma tarea, podrías obtener soluciones contradictorias. Mitigación: define claramente qué decisiones son tomadas por qué modelo, y permite que el modelo caro revise la salida del barato.

Diseñando agentes para el límite

Si estás construyendo agentes que correrán en producción, asume que el contexto se acabará. No es un «if», es un «when». Algunas reglas:

Stateless por diseño: Cada llamada al LLM debe ser autocontenida. Si alguien detiene el agente y lo reinicia desde la mitad, debe poder recuperar el estado desde almacenamiento persistent, no desde el historial del chat.
Limitar el historial en banda: En la API, pasa solo los últimos N turnos (ej: 10) más cualquier summary generado artificialmente. No confíes en la memoria del modelo.
Monitorear tokens en tiempo real: Lleva un contador de tokens input/output. Cuando llegues al 80%, activa estrategias de poda automática.
Alertar al usuario: Si el contexto se está llenando, notifica: «Has usado el 75% del contexto disponible en esta sesión. Considera dividir la tarea o guardar un checkpoint».

Alternativas: chunking vs. summarization

Hay dos escuelas:

Chunking puro: Sesiones cortas, estado externo. Más simple, menos mágia negra.
Sumarización incremental: Genera resúmenes automáticos del historial para comprimirlo.

Chunking es más confiable pero requiere más trabajo de orquestación. Summarization es «automágico» pero puede perder detalles sutiles. Mi recomendación: empieza con chunking, y solo añade summarization si el overhead de orquestación se vuelve prohibitivo.

Conclusión: la humildad del límite

El límite de contexto no es un bug; es una característica fundamental de la arquitectura actual de LLMs. Pretender que un asistente mantenga coherencia durante 10 horas de conversación es ingenuo.

Lo que hemos aprendido de la señal de Reddit es que hasta los usuarios más técnicos son sorprendidos por el límite. La solución no es «usar un modelo con más contexto» (aunque ayuda temporalmente); es diseñar interacciones que respeten la restricción.

Para desarrolladores: implementen chunking, checkpointing, y switching de modelos como patrones estándar. No dejen que sea una reflexión posterior.

Para usuarios: si tu sesión supera los 45 minutos, asume que estás perdiendo calidad. Divídela. Usa resúmenes explícitos. Y no confíes en que el modelo recuerde lo que le dije hace una hora.

El experto que conociste al inicio de la sesión no es el mismo novato que queda después de 100K tokens. Gestiona esa transición, o acabarás preguntándote por qué tu asistente se volvió tonto de repente. La respuesta está en el límite. Y ese límite, hoy, es parte de la herramienta — no un inconveniente que podamos ignorar.