Ventanas de contexto: el presupuesto de tokens que gasta cada llamada

La context window es todo lo que el modelo puede referenciar en una llamada — el system prompt, las instrucciones, los ejemplos, los hechos recuperados, la conversación hasta ahí, las definiciones de tools, el input del usuario, y la propia respuesta del modelo mientras la escribe. Es el campo de visión entero del modelo para esa llamada, y tiene dos propiedades que gobiernan todo lo que hacés con ella: es finita, y está ordenada. Finita significa que hay un techo duro de cuántos tokens entran, y cada parte de arriba tira de ese único techo. Ordenada significa que la posición pesa — el mismo hecho cae distinto según dónde en la ventana esté parado. Qué es context engineering plantea la ventana como la unidad de control; esta página es la capa operativa debajo — cómo se gasta el presupuesto, cómo se maneja a medida que crece, y por qué un techo grande cambia menos de lo que parece.

Esto es una referencia, no una receta. Los números correctos — cuánto guardar, cuándo compactar, qué tan grande aprovisionar la ventana — dependen de tu tarea y tu modelo. Lo que no cambia es la forma del trade-off: cada token que agregás a la ventana cuesta algo, en espacio, en plata, en latencia y en la atención del modelo. El laburo es gastar ese presupuesto donde se gana su lugar (principio 10 — el contexto es un presupuesto, no un balde).

La ventana es un presupuesto, no un balde

Imaginá la ventana como una cantidad fija de espacio. Cada parte de la llamada se muda adentro, y todas comparten el mismo piso:

• El system prompt — el rol, la tarea y las reglas permanentes. Se fija una vez, vale toda la llamada. La profundidad de escribirlo es system prompts and instructions.
• Instrucciones — el pedido específico de este turno, en este formato, bajo estas restricciones.
• Ejemplos few-shot — pares de input-output trabajados que muestran la forma que querés en vez de describirla.
• Contexto recuperado — hechos traídos en tiempo de query para que el modelo responda desde tus datos, no desde su entrenamiento. Su propia disciplina es qué es grounding.
• Historia / estado de la conversación — lo que vino antes, más cualquier estado de borrador que se arrastra. La parte que crece en silencio.
• Definiciones de tools — las funciones tipadas que el modelo puede llamar, cada una con un nombre y una descripción que lee antes de poder elegir.
• El input del usuario — la pregunta real de este turno.
• La respuesta del modelo — la salida también cuenta. La ventana tiene que dejar lugar para la respuesta que está por escribir, así que una ventana de input casi llena no deja espacio para responder.

El reflejo es tratar la ventana como un balde: meté todo lo que pueda ayudar y dejá que el modelo lo ordene. No funciona así. Pasado un punto, más contexto hace la respuesta peor — la señal que el modelo necesita se ahoga en el contexto que agregaste "por las dudas", y el modelo le presta atención al ruido. Esto es context rot, y es la misma trampa que el grounding llama sobre-retrieval una capa más abajo: meter los cincuenta chunks de arriba degrada el razonamiento exactamente como meter la historia (mirá retrieval quality). El arreglo es el mismo de los dos lados — curá, no acumules. Gastá el presupuesto en las partes que se lo ganan, y cortá las que no, porque cada token compite con todos los demás por la atención del modelo.

La ventana está ordenada: lost in the middle

La segunda propiedad es la que sorprende. La ventana no es una bolsa plana donde cada token pesa lo mismo. La posición pesa, y el patrón es consistente: los modelos atienden de forma más confiable al principio y al final de la ventana, y menos confiable al medio. Una instrucción crítica o un hecho clave varado en el medio de una ventana larga se subpondera — presente en los tokens, pero en la práctica tenue. Esto es el efecto "lost in the middle", y significa que dónde ponés algo es parte de qué tan bien funciona.

La movida práctica es poner lo que importa donde el modelo lo pondera. La guía de Anthropic sobre contexto largo es concreta con esto: poné el material voluminoso — el documento largo, el corpus recuperado, la historia — hacia arriba, y poné la instrucción real y la pregunta cerca del final, lo más cerca de donde el modelo arranca a escribir. Los mismos hechos acomodados de dos formas producen dos respuestas distintas; el acomodo es una palanca, no un detalle de formato.

Manejar una ventana que crece

Una sola llamada es fácil de encajar. El problema es la llamada que es parte de una conversación, o un loop de agente que corre por muchos turnos — la historia crece cada turno, y librada a su suerte crece hasta que tapa la instrucción que importa o pega directamente contra el techo. Una ventana que crece sin límite es un sistema que se pone más lento, más caro y menos confiable cuanto más corre. Así que una ventana que crece tiene que manejarse, y hay tres movidas honestas:

• Resumir — reemplazá un tramo largo de historia por un resumen corto. Te quedás con el sentido y pagás una fracción de los tokens. El costo es que resumir es con pérdida: el detalle que el resumen descartó es detalle que el modelo ya no tiene.
• Descartar — tirá los turnos que ya no importan. Los intercambios más viejos de una conversación larga suelen ser peso muerto; cortarlos es el recupero más barato que hay, mientras cortes lo que de verdad está gastado y no lo que el turno actual todavía usa.
• Recuperar bajo demanda — mantené el grueso afuera de la ventana y traé de vuelta solo el pedazo relevante cuando un turno lo necesita, en vez de arrastrar todo hacia adelante por las dudas. Esto es grounding aplicado a la propia historia de la conversación.

Para un loop largo o agéntico, el enfoque manejado es server-side compaction — la plataforma resume y poda el contexto que se acumula por vos a medida que avanza el loop, así un agente multiturno no revienta su ventana en el turno cuarenta. Tratalo como la estrategia primaria para loops que corren largo: es la misma disciplina de resumir-y-descartar de arriba, automatizada y aplicada de forma continua, así no estás manejando a mano la historia de cada conversación larga.

Un techo más grande no es licencia para llenarlo

Los techos crecieron, y ahora son genuinamente grandes. Claude Sonnet 4 y Sonnet 4.5 soportan una context window de un millón de tokens — disponible en beta, para tiers de uso más altos — que es lugar para un corpus sustancial, una base de código larga, o una conversación profunda en una sola llamada. Es tentador leer un techo así de grande como permiso para dejar de pensar en el presupuesto. No lo es.

El principio 10 sigue valiendo a un millón de tokens, porque los costos que hacen real al presupuesto no desaparecen cuando sube el techo — escalan con lo que metés. Una ventana más grande que de verdad llenás cuesta más por llamada (pagás por los tokens), corre más lento (el modelo procesa más antes de responder), y todavía sufre context rot y lost in the middle (un hecho relevante compite con más distractores, y el medio es más grande). Un techo grande te compra la opción de incluir más cuando más de verdad se gana su lugar; no cambia la aritmética de que más por lo general no. Aprovisioná la ventana que la tarea necesita, y llenala con lo que la tarea necesita — no con todo lo que el techo permite.

Una cosa que sí ayuda es que el modelo ahora puede vigilar su propio presupuesto. Los modelos más nuevos — Sonnet 4.6, Sonnet 4.5 y Haiku 4.5 — tienen context awareness: pueden trackear los tokens que quedan a lo largo de una conversación y dosificarse en consecuencia, en vez de correr a ciegas hacia el techo. Es una ayuda real para loops agénticos largos, donde un modelo que sabe que se está quedando corto puede cerrar o compactar en vez de pegar contra una pared. No reemplaza tu presupuesto — es el modelo poniendo su parte de la misma disciplina que vos manejás desde afuera.

El hilo

La ventana es finita y está ordenada, y casi todo lo operativo del prompting sale de esos dos hechos. Finita es por qué curás en vez de acumular, manejás la historia en vez de dejarla crecer, y leés un techo de un millón de tokens como una opción y no como una instrucción — el contexto es un presupuesto, no un balde (principio 10). Ordenada es por qué ponés la instrucción donde el modelo la pondera, cerca de la pregunta, en vez de confiar en que un hecho enterrado en el medio cargue. Acertá los dos y la ventana trabaja para el modelo; equivocate en cualquiera y gastaste tokens, latencia y plata para hacer la respuesta peor. Esta es la profundidad debajo de qué es context engineering — esa página nombra la ventana como la unidad; esta es cómo la gastás. Y cuando la parte que guardás es grande y estable entre llamadas, la palanca que hace barato re-enviarla es prompt caching, donde el presupuesto se encuentra con la cuenta.

Related

• Qué es context engineering — el marco que esta página vuelve operativo: la ventana es la unidad de control
• System prompts and instructions — los tokens de mayor palanca en la ventana, y dónde ubicarlos
• Prompt caching — la palanca de costo para un contexto grande y estable que enviás repetidamente
• Structured output — restringir la respuesta, que también gasta del mismo presupuesto
• Prompting gotchas — las fallas con forma de contexto, incluida la instrucción enterrada y la historia inflada
• Retrieval quality — el sobre-retrieval es context rot del lado del grounding: el mismo presupuesto, una capa más abajo
• AI Engineering principles — el contexto es un presupuesto, no un balde (10), el modelo es la parte fácil (4), costo y latencia son features (6)

Reference:

• Anthropic — Context windows ↗
• Anthropic — Long context prompting tips ↗