La capacidad se mide, no es una cifra de un millón

La línea de «1M tokens» en una ficha de modelo es un límite superior de lo que la API aceptará, no una garantía de lo que el modelo usará bien. En agosto de 2026, ofox.ai envió un mismo documento inglés de 420 palabras a nueve modelos insignia y midió una dispersión de 1,56x en el recuento de tokens — 614 tokens en Grok 4.20, 957 en Claude Opus 5 — para exactamente el mismo texto. La ventana anunciada es una afirmación de ficha; la capacidad real es una medición, y según Theorem 3, una propiedad queda garantizada exactamente cuando su mecanismo está implementado y midiendo. El mecanismo aquí es el tokenizador más la curva de precisión de recuperación, y ninguno aparece en la cifra titular.

Qué es realmente una ventana de contexto

Una ventana de contexto es el presupuesto de tokens para una única petición a la API. Todo lo que el modelo lee y todo lo que escribe tiene que caber en un solo número, y la API no tiene estado — no recuerda la llamada anterior. En cada turno tu aplicación reenvía toda la conversación, y la ventana es el techo de cuán grande puede ser ese reenvío más la respuesta que viene.

Por eso la ventana no es memoria en ningún sentido útil. Un producto de chat que parece recordar tu nombre entre sesiones está guardando ese texto en algún sitio y pegándolo de vuelta en la ventana en cada petición. La persistencia vive en tu aplicación, no en el modelo.

Qué cuenta hacia la ventana

Todo lo que hay en la petición, más todo lo que hay en la respuesta. Las partes que la gente olvida suelen ser las más caras:

• Prompt del sistema. Se cuenta en cada turno, no una vez por sesión.
• Historial completo de mensajes. Cada turno previo de usuario y asistente que reenvías.
• Definiciones de herramientas. Nombres, descripciones y esquemas JSON de cada herramienta que declaras. En Claude estos añaden además un prompt de sistema de uso de herramientas por modelo, desde 286 tokens en Opus 5 hasta 675 en Opus 4.7.
• Resultados de herramientas. A menudo el mayor elemento individual en un bucle de agente; un listado de directorio o una respuesta de API puede llegar a miles de tokens.
• Tokens de razonamiento. En modelos con pensamiento activado, el razonamiento cuenta y se factura incluso cuando el texto no se te devuelve.
• La propia respuesta. Por esto max_tokens y la ventana de contexto interactúan: una petición que no deja hueco para la salida se trunca.

«1M tokens» son nueve números distintos

[UNIQUE INSIGHT] La ventana anunciada es un límite superior de lo que la API aceptará, no de lo que el modelo usará bien — y la distancia entre esos dos es una cuestión de benchmark, no de ficha. El mecanismo que determina la capacidad real es el tokenizador más la curva de precisión de recuperación, y ninguno aparece en la cifra titular.

Entre los nueve modelos insignia que ofox.ai catalogó el 2026-08-12, «1M» se resuelve en nueve enteros distintos: desde un 1.000.000 redondo (Claude Opus 5, Grok 4.20, DeepSeek V4 Flash) hasta 1.131.072 (Qwen 3.8 Max). Eso es una dispersión del 13% antes de haber medido nada. En el catálogo completo de 119 modelos de texto, la ventana más común es 256K (25 modelos), con 22 en 1M.

Una cautela sobre de dónde vienen estas cifras. Los catálogos de pasarela y la documentación del proveedor no siempre coinciden: el 2026-08-12 el catálogo de ofox listaba Grok 4.20 en 2.000.000 mientras que la propia documentación de xAI indica 1.000.000. La comparación honesta usa el número del proveedor, y compruebas la página del proveedor cuando la cifra importa. Una ficha es una afirmación; la doc del proveedor es una afirmación más fuerte; el prompt_tokens medido en tu contenido es la única que responde a tu pregunta.

La dispersión de 1,56x con la misma entrada

La sorpresa más profunda es que el tokenizador — no el número de ventana — es el mecanismo determinante. ofox envió un mismo documento inglés de 2.638 caracteres (un postmortem de servicio de 420 palabras) a nueve modelos a través de un único endpoint y leyó prompt_tokens en cada respuesta:

• Grok 4.20: 614 tokens (4,30 caracteres/token)
• GPT-5.6 Sol: 626 (4,21)
• GLM-5.2: 632 (4,17)
• DeepSeek V4 Flash: 634 (4,16)
• Gemini 3.1 Pro: 684 (3,86)
• Claude Opus 4.6: 698 (3,78)
• Qwen 3.8 Max: 706 (3,74)
• Kimi K3: 716 (3,68)
• Claude Opus 5: 957 (2,76)

Una dispersión de 1,56x con la misma entrada. Claude Opus 5 es el valor atípico porque Anthropic documenta que Claude 4.7 y posteriores usan un tokenizador más nuevo que produce aproximadamente un 30% más de tokens para el mismo texto.

Combina las dos tablas y la ventana anunciada deja de ser el número útil. Las copias de ese mismo documento de 420 palabras que realmente caben van de 1.045 en Claude Opus 5 a 1.677 en GPT-5.6 Sol — una brecha de 1,60x en modelos que todos anuncian «aproximadamente 1M».

La ratio no es constante entre tipos de contenido. En un fichero TypeScript la dispersión fue de 1,53x y GLM-5.2 fue el más ajustado en vez de Grok. En prosa china la dispersión se amplió a 1,88x, y ambos modelos Claude quedaron cerca de un token por carácter chino frente a 1,87 de Grok. Tómalos como muestras, no como reglas: en un segundo pasaje chino con más puntuación los mismos dos modelos quedaron en 0,98 y 0,96 caracteres/token, lo que significa que algunos caracteres cuestan más de un token. Si tu entrada es código o no es inglés, mídela en vez de asumir.

Por qué los precios por token no son comparables entre proveedores

Como un token no es una cantidad fija de texto, los precios por token no son directamente comparables. Un proveedor que cobra menos por token puede salir más caro por palabra si su tokenizador es más denso. Anthropic factura la ventana completa de 1M a tarifas estándar sin prima de contexto largo, así que una petición de 900K tokens cuesta lo mismo por token que una de 9K. Gemini 3.1 Pro pasa de 2 $ a 4 $ por millón de tokens de entrada pasado 200K, y Grok 4.20 de 1,25 $ a 2,50 $ en el mismo umbral. El modelo con la tarifa titular más barata puede ser el más caro para trabajo con documentos largos, y la diferencia del tokenizador se suma a la tarifa que te toque.

Una comparación de presupuesto que lee el precio de portada y la ventana anunciada está leyendo dos afirmaciones. Una comparación que mide prompt_tokens en el documento real y multiplica por la tarifa del tramo aplicable está leyendo una medición. La primera es una suposición; la segunda es un número contra el que puedes facturar.

La ventana no es el contexto utilizable

La cautela más importante es que un modelo que acepta 1M tokens no es lo mismo que un modelo que encuentra fiablemente el dato que enterraste en el token 800.000. La precisión de recuperación decae con la distancia en todo modelo público, y el tamaño de ese hueco es una cuestión de benchmark, no de ficha. ofox señala RULER, MRCR v2 y NoLiMa como los benchmarks que realmente lo miden: RULER explora la recuperación a profundidades controladas en contextos sintéticos, MRCR v2 sigue la recuperación multi-salto en documentos largos, y NoLiMa prueba si un modelo aún encuentra la respuesta cuando se elimina el solapamiento léxica entre pregunta y evidencia. Ninguna de esas puntuaciones aparece en una ficha junto a «contexto de 1M».

Trata la ventana anunciada como un límite superior de lo que la API aceptará, y los números de benchmark como la guía de lo que el modelo usará bien. El primer número es un contrato; el segundo es una medición. Un modelo que acepta un millón de tokens pero recupera con un 60% de precisión a profundidad 500K tiene un contexto utilizable muy por debajo del anunciado, y ninguna ventana lo arregla — solo lo hace un mecanismo distinto (enrutamiento, recuperación o reestructuración).

El mecanismo es la medición, no la ficha

[ORIGINAL DATA] En Everythink tratamos la ventana de contexto como cualquier propiedad afirmada: según Theorem 3, una propiedad queda garantizada exactamente cuando su mecanismo está implementado y midiendo. La línea de «1M tokens» no tiene mecanismo detrás; el prompt_tokens en tu propio contenido es el mecanismo. Medimos antes de comprometernos con un proveedor, y volvemos a medir cuando un proveedor publica un tokenizador nuevo, porque la cifra titular se ha desviado hasta 1,6x en cualquier dirección.

Esta es la disciplina de la re-medición. Un tokenizador no es una propiedad estable de la física; es un artefacto de software que un proveedor puede reemplazar por uno más nuevo que produce un 30% más de tokens para el mismo texto, como hizo Anthropic con Claude 4.7. Cuando eso ocurre, cada estimación de capacidad que cacheaste del tokenizador antiguo está equivocada en el mismo 30%, y también cada estimación de coste construida sobre ella. Los equipos que se queman son los que midieron una vez, escribieron el número en un fichero de configuración y no volvieron. Los que se mantienen honestos re-miden con una cadencia, como recalibrarías cualquier instrumento.

No es una disciplina nueva para nosotros. El HAI Engine está en producción desde 2016, y cada previsión se ramifica a múltiples Sisters — cada una un agente de IA tipado con su propia personalidad y su propia decisión de presupuesto de contexto — antes de que el Oracle fusione sus borradores en un conjunto calibrado. Una previsión no es un prompt gigante; es un conjunto enrutado de prompts acotados, y el acote es una medición, no una línea de ficha.

[PERSONAL EXPERIENCE] Llevamos una década midiendo presupuestos de contexto de agentes, y el error más fiable que vemos es elegir un modelo por la ventana anunciada y descubrir, en producción, que la carga real cabe un 35% menos de documentos de lo que implicaba la ficha. El arreglo nunca es una ventana más grande. El arreglo es medir tu propio contenido en los modelos entre los que eliges — una petición con max_tokens: 1 devuelve prompt_tokens y cuesta una fracción de céntimo — y enrutar en consecuencia.

El enrutamiento precede a la recuperación

Este es el mismo principio que «the space is the router»: en Everythink, la topología network→community→room enruta una consulta antes de que nada responda. No viertes el mundo entero en una ventana y esperas que el modelo encuentre el dato correcto en el token 800.000; enrutas a la sala que contiene el contexto relevante, de modo que la ventana que el modelo ve realmente es pequeña, fresca y medida. La capacidad es un problema de enrutamiento antes que de recuperación, y la recuperación es un problema de medición antes que de ficha.

The 21 papers lo codifican. Theorem 3 no dice «más grande es mejor»; dice que una propiedad se cumple exactamente cuando el mecanismo que la garantiza está en su sitio y midiendo. Para la capacidad, ese mecanismo es un tokenizador leyendo tu contenido y un benchmark leyendo la recuperación del modelo a profundidad. El número anunciado no es ninguno de los dos.

La soberanía del cliente funciona con medición

La soberanía del cliente — tu red, tu marca, tus datos — tiene una dependencia silenciosa con la medición de capacidad. Cuando eres dueño de la topología network→community→room, decides qué contexto llega a qué agente, y esa decisión solo es tan buena como tu estimación de lo que cabe. Un operador soberano que confía en la ficha entrega la decisión real al copy de marketing del proveedor. Un operador soberano que mide su propio corpus mantiene la decisión de enrutamiento en casa, donde pertenece. Lo mismo aplica a la inclusión por diseño: un usuario con conectividad limitada en un plan de datos medido se sirve mejor con una ventana pequeña y bien enrutada, no con una manguera de un millón de tokens, y «pequeña y bien enrutada» es una medición que solo puedes hacer si has medido.

Cómo caber más en la ventana que tienes

Ninguno de estos hace la ventana más grande; todos reducen lo que gastas dentro. En orden aproximado de retorno:

1. Caché de prompts. Un prefijo estable — prompt del sistema, definiciones de herramientas, un documento sobre el que sigues preguntando — se factura a aproximadamente el 10% de la tarifa de entrada en un acierto de caché en Anthropic y otros proveedores, aunque el descuento exacto varía y en algunos es mayor. Es la palanca más grande para llamadas repetidas, y cambia el coste, no la capacidad.
2. Compaction. Resumen en el servidor de los turnos anteriores cuando la conversación se acerca al límite, para que una sesión de agente larga siga funcionando en vez de fallar.
3. Edición de contexto. Limpiar resultados de herramientas obsoletos y bloques de razonamiento viejos del historial. Los bucles de agente se llenan de salida de herramientas más que de conversación.
4. Elegir el tokenizador adecuado para tu contenido. Como muestran las mediciones de arriba, esa decisión por sí sola vale hasta 1,6x de capacidad efectiva antes de optimizar nada más.

Los tres primeros gestionan el presupuesto. El cuarto elige contra qué presupuesto estás midiendo. Los cuatro son mecanismos; ninguno es un número más grande en una ficha.

Qué pasa cuando excedes la ventana

Recibes un HTTP 400 y ninguna salida. Nada se trunca silenciosamente. ofox envió una petición sobredimensionada a un modelo de 32.000 tokens y recibió:

{"error":{"code":null,
  "message":"<400> InternalError.Algo.InvalidParameter: Range of input length should be [1, 30720]",
  "type":"invalid_request_error"}}

Lee ese límite con cuidado: el modelo anuncia 32.000, y el techo de entrada impuesto es 30.720, con el resto reservado para la salida. La ventana anunciada es el total, no tu asignación de entrada, y el número impuesto puede ser inferior al de marketing.

Las formas de error difieren por proveedor, así que no hagas pattern-matching sobre la cadena del mensaje. Los endpoints compatibles con OpenAI generalmente devuelven un 400 con un código estilo context_length_exceeded. Claude puede en cambio terminar el turno con stop_reason: "model_context_window_exceeded", distinto de max_tokens y que necesita su propia rama en tu código. Maneja ambos. Una respuesta que se detuvo antes porque se llenó la ventana no es el mismo fallo que una que se detuvo porque tu max_tokens era pequeño, y las soluciones difieren.

Conclusiones clave

• La ventana anunciada es un límite superior de lo que la API acepta, no de lo que el modelo usa bien. La capacidad real es una medición, y la medición es el tokenizador más la curva de precisión de recuperación.
• «1M tokens» son nueve números distintos, y el mismo documento de 420 palabras cabe 1,6x más copias en un modelo insignia que en otro. Los precios por token no son comparables entre proveedores sin ajustar por la densidad del tokenizador.
• Mide tu propio contenido. Una petición con max_tokens: 1 devuelve prompt_tokens y cuesta una fracción de céntimo. Ejecútala en tu carga real antes de elegir un modelo por el tamaño de la ventana, y vuelve a ejecutarla cuando un proveedor publique un tokenizador nuevo.
• El mecanismo es la medición, no la ficha. Según Theorem 3, una propiedad queda garantizada exactamente cuando su mecanismo está implementado y midiendo. La línea de «1M» no tiene mecanismo; prompt_tokens es el mecanismo.
• El enrutamiento precede a la recuperación. No viertas el mundo en una ventana. Enruta primero al contexto relevante — la topología network→community→room en Everythink es el mismo principio a nivel de producto — para que la ventana que el modelo ve sea pequeña, fresca y medida.

Preguntas frecuentes

¿Es una ventana de contexto lo mismo que memoria? No. Una ventana de contexto es por petición, no persistente. La API no tiene estado: en cada turno reenvías toda la conversación, y la ventana es el techo de lo que una petición puede contener. Cualquier cosa fuera de ella desaparece a menos que tu aplicación la guarde y la envíe de nuevo. Los productos que parecen recordarte entre sesiones están reinyectando texto guardado en la ventana, no tirando de memoria del modelo.

¿Cuántas palabras son 1 millón de tokens? Para prosa en inglés, aproximadamente entre 440.000 y 685.000 palabras — un rango más amplio de lo que admite la regla habitual. Según la medición de ofox en un mismo documento, ocho de nueve modelos quedan entre 587.000 y 684.000 palabras por millón de tokens; Claude Opus 5 es el valor bajo atípico, unos 439.000, por su tokenizador más nuevo. El código es más denso (unos 2,4 a 3,6 caracteres/token) y el chino aún más (0,9 a 1,9), así que la misma ventana de 1M contiene mucho menos de esos.

¿Cuál es la ventana de contexto más grande disponible en 2026? 1M tokens es la cima de la franja principal. Varios proveedores se sitúan ligeramente por encima del número redondo: Qwen 3.8 Max en 1.131.072, GPT-5.6 en 1.050.000, y Gemini, GLM y Kimi K3 en 1.048.576. Entre los 119 modelos de texto del catálogo de ofox el 2026-08-12, la ventana más común es 256K (25 modelos), con 22 en 1M.

¿Por qué el mismo fichero usa más tokens en Claude que en GPT? Tokenizadores distintos. Anthropic señala que Claude 4.7 y posteriores usan un tokenizador más nuevo que produce aproximadamente un 30% más de tokens para el mismo texto que los Claude anteriores. En el documento inglés de prueba de ofox, Claude Opus 5 usó 957 tokens donde GPT-5.6 Sol usó 626, una diferencia de 1,53x con la misma entrada. No hay nada mal; los modelos simplemente cuentan distinto, y los precios por token no son comparables entre proveedores sin ajustar por ello.

¿Puedo aumentar la ventana de contexto de un modelo? No. Es fija para el modelo y no hay parámetro para subirla. Lo que sí puedes cambiar es cuánto gastas de ella: la caché de prompts reduce el coste de reenviar un prefijo estable, la edición de contexto limpia resultados de herramientas obsoletos, y compaction resume los turnos más antiguos. Esos gestionan el presupuesto en vez de expandirlo.

Si quieres dejar de adivinar la capacidad y empezar a medirla, crea tu red — la topología que enruta antes de que nada responda, para que la ventana que tus agentes ven realmente sea la que has medido.

Sources

• 2026 — ofox.ai, «What Is a Context Window? Token Limits by Model (2026)» — https://ofox.ai/blog/what-is-a-context-window-token-limits-by-model-2026/
• 2026 — Anthropic, «Context windows» — https://platform.claude.com/docs/en/build-with-claude/context-windows
• 2026 — Anthropic, «Pricing, including the tokenizer note» — https://platform.claude.com/docs/en/about-claude/pricing