Una ventana de contexto no es almacenamiento — es memoria de trabajo. Cada token en la ventana (tu prompt del sistema, el historial de la conversación, cualquier documento que pegues y la propia salida del modelo hasta el momento) compite por el mismo presupuesto de tamaño fijo. Cuando la gente dice que Claude tiene una ventana de contexto de 200K o que Gemini soporta 1M de tokens, esos números incluyen todo: entrada y salida combinadas. Un error común es tratar la ventana de contexto como una base de datos que puedes llenar de documentos y esperar que el modelo busque perfectamente. En realidad, los modelos procesan el contexto a través de mecanismos de attention, y attention tiene límites tanto computacionales como cualitativos.
El problema de "perdido en el medio" es real y está bien documentado. Investigaciones de Stanford y otros mostraron que cuando colocas información crítica en el medio de un contexto muy largo, los modelos son mediblemente peores usándola comparado con información al principio o al final. Esta no es una preocupación teórica — afecta directamente cómo deberías estructurar tus prompts. Si estás alimentando a un modelo con 50 páginas de documentación, pon las secciones más importantes al principio y al final, no enterradas en la página 25. Algunos equipos trabajan alrededor de esto fragmentando documentos y usando RAG para recuperar solo las piezas relevantes en lugar de volcar todo en el contexto.
Los tamaños de ventanas de contexto han crecido dramáticamente. GPT-3 se lanzó en 2020 con 4K tokens (aproximadamente 3,000 palabras). Para 2024, Claude ofrecía 200K tokens, y Gemini 1.5 Pro empujó a 1M de tokens. Los modelos Gemini 2.5 de Google mantienen esa ventana de un millón de tokens. Pero ventanas más grandes vienen con compensaciones reales. La latencia aumenta porque el modelo debe atender a más tokens. El costo sube porque la mayoría de los proveedores de API cobran por token procesado. Y como se mencionó, la calidad en tareas de recuperación no escala linealmente con el tamaño del contexto — una ventana de 1M de tokens no es 5 veces mejor encontrando una aguja que una ventana de 200K tokens.
Para desarrolladores que trabajan con API, la gestión del contexto es un problema central de ingeniería. Las conversaciones largas acumulan tokens rápidamente. Un chat de ida y vuelta puede consumir 500–1,000 tokens por intercambio, lo que significa que un modelo de 4K tokens se queda sin espacio en solo unos pocos turnos. Los sistemas en producción manejan esto con ventanas deslizantes (eliminando los mensajes más antiguos), resumen (comprimiendo la conversación previa en un resumen más corto) o enfoques híbridos usando RAG para descargar material de referencia en una base de datos vectorial y solo traer fragmentos relevantes bajo demanda. Hacer esto bien es frecuentemente la diferencia entre un demo que funciona y un producto que escala.
Un matiz que confunde a los principiantes: el límite de la ventana de contexto es en tokens, no en caracteres o palabras. La tokenización varía por modelo e idioma. El texto en inglés promedia alrededor de 1 token por cada 4 caracteres, pero el código puede ser más denso (los nombres de variables y la sintaxis consumen tokens rápidamente), y los scripts no latinos como el chino o el hindi frecuentemente usan más tokens por palabra. El mismo documento podría consumir 10K tokens en inglés y 15K en japonés. La mayoría de los proveedores ofrecen herramientas o librerías de tokenización — Anthropic tiene un contador de tokens en los headers de respuesta de la API, y OpenAI publica tiktoken — para que puedas medir con exactitud en lugar de adivinar.