Comparativa de Ventanas de Contexto LLM 2026: Tokens de Entrada y Salida Máximos para Cada Modelo Principal

Los proveedores cotizan dos números de contexto distintos. La ventana de entrada es el total de tokens que el modelo acepta en una única solicitud, incluido el prompt del sistema, el historial de conversación, las definiciones de herramientas y el mensaje actual del usuario. El límite de salida es el máximo de tokens que el modelo está dispuesto a devolver en una única respuesta — un límite separado, generalmente más pequeño, establecido por el proveedor.

Confundir los dos es la sorpresa de costes más común que vemos. Claude Sonnet 4.6 tiene una ventana de entrada de 500k pero limita la salida a 64k; si le pides que traduzca un documento de 200k tokens a otro idioma, no puedes obtener la traducción completa en una respuesta — la salida se detiene en 64k. Tienes que dividir la solicitud en partes.

Los modelos de razonamiento complican aún más el lado de la salida. El o4-reasoning de OpenAI comparte su presupuesto de salida de 100k entre tokens de razonamiento ocultos y salida visible; un modelo que piensa durante 80k tokens solo tiene 20k restantes para la respuesta visible. Planifica los presupuestos de salida en consecuencia. Para estrategia de ventana de entrada específicamente, nuestro constructor de prompts de código ayuda a estructurar prompts técnicos largos que encajen claramente dentro de ventanas más estrechas.

La conversión de tokens a palabras utiliza la regla de oro de 1 token ≈ 0,75 palabras en inglés. La proporción real varía — el código y el texto en idiomas no ingleses tienen proporciones más bajas, los datos estructurados tienen proporciones más altas — pero para la planificación la regla funciona.

200k tokens ≈ 150.000 palabras ≈ 500 páginas de prosa densa. Ejemplos: el texto completo de Guerra y paz (1.200 páginas) no cabe, pero la mayoría de libros técnicos completos (300-450 páginas) sí. Un manual de empleados promedio de una empresa tecnológica más sus políticas referenciadas cabe cómodamente.

1.000.000 de tokens ≈ 750.000 palabras ≈ 2.500 páginas de prosa densa. Ejemplos: toda la serie de Harry Potter (~1,1M de palabras en 7 libros) cabe con margen de sobra. Una 10-K financiera de 200 páginas más 50 transcripciones de apoyo. Una base de código de tamaño medio de 50-80k líneas de código.

2.000.000 de tokens ≈ 1.500.000 de palabras ≈ 5.000 páginas. Ejemplos: 4-5 novelas completas a la vez, las obras completas de Shakespeare con anotaciones, o una base de código de 300 archivos con 200k LOC. En este tamaño, la generación aumentada por recuperación (RAG) casi siempre supera el enfoque de meter todo en contexto — más barato, más rápido y generalmente más preciso según los puntos de referencia publicados.

10.000.000 de tokens (Llama 4 Scout): aproximadamente 7,5M de palabras, o 25.000 páginas. Los puntos de referencia de recuperación después de 500k son mixtos; trata el número de titular más como 'aceptamos esta cantidad de entrada' que como 'razonaremos de forma fiable sobre esta cantidad de entrada.'

El punto de referencia de aguja en pajar coloca un hecho específico único en posiciones aleatorias dentro de un documento largo y prueba si el modelo puede recuperarlo. La mayoría de modelos puntúan cerca del 100% en entradas más cortas y se degradan a medida que la entrada crece — típicamente cayendo en picada entre 50k y 200k tokens de contenido denso.

Según los puntos de referencia publicados de 2026: Gemini 3.1 Pro Preview mantiene recuperación de 95%+ hasta aproximadamente 600k tokens antes de degradarse. Claude Opus 4.8 se mantiene por encima del 90% hasta ~300k. gpt-5.5 se mantiene por encima del 90% hasta ~200k. Llama 4 Scout, a pesar de su número de titular de 10M tokens, muestra resultados mixtos después de 500k.

La conclusión práctica: diseña tu prompt alrededor de la recuperación efectiva, no de la ventana anunciada. Si el rango fiable del modelo es 300k tokens pero necesitas consultar 500k, divide el documento, puntúa los fragmentos por relevancia y pasa solo las coincidencias principales en contexto. Eso es RAG, y casi siempre supera el relleno de contexto bruto más allá de cierto tamaño de documento.

Para RAG específicamente, el coste de incrustación domina la factura de construcción de índice — consulta nuestra calculadora de coste de incrustación para los precios actuales de incrustación por modelo.

Supongamos que necesitas revisar un documento de 250.000 tokens — un lote de contrato de 600 páginas con anexos. ¿Qué ventana se ajusta?

Elegible por ventana bruta: cada modelo en la tabla excepto OpenAI o4-reasoning (200k) y Claude Haiku 4.5 (200k). Elegible por recuperación efectiva (asumiendo contenido denso): gpt-5.5-pro, Claude Opus 4.8, Claude Sonnet 4.6, Claude Fable 5, Gemini 3.x, Gemini 2.5 Pro, Qwen 3 Max.

Comparación de costes para una única revisión con presupuesto de entrada de 250k y salida de 2k. gpt-5.5: $1,31 ($1,25 entrada + $0,06 salida). Claude Sonnet 4.6: $0,78 ($0,75 + $0,03). Gemini 2.5 Pro: $0,33 ($0,3125 + $0,02). Claude Opus 4.8: $1,30 ($1,25 + $0,05). Gemini 3.1 Pro Preview: $0,52.

Mismo contenido, $0,33-$1,31 por revisión según la opción de modelo. Si ejecutas 1.000 revisiones por mes, la diferencia se compone a $330 vs $1.310 por mes — una diferencia mensual de $980 para la misma carga de trabajo. Empareja el modelo a la profundidad de recuperación requerida, luego elige la opción más barata que cumpla con la barra de recuperación. Para estrategias de calidad de prompt que resistan un nivel más barato, nuestro generador de metadescripción ayuda a comprimir consultas de recuperación.

Necesitas generar un documento de 50.000 tokens — un informe de formulario largo, una novela traducida, una base de código generada. ¿Qué modelos pueden devolver eso en una única respuesta?

Modelos que pueden devolver 50k tokens en una única llamada: Claude Opus 4.8 (límite de salida de 64k), Claude Sonnet 4.6 (64k), Claude Fable 5 (128k), familia Gemini 2.5/3.x (65k), OpenAI o4-reasoning (100k compartido con razonamiento, así que ~30-50k visible después del razonamiento). La mayoría de otros limitan a 8-32k de salida.

Si tu modelo limita a menos de 50k, debes dividir: genera los primeros 16k, pide al modelo que continúe desde donde lo dejó, repite. La división introduce riesgo de continuidad — el segundo fragmento puede repetir contenido, perder el hilo o cambiar el tono. La generación de una sola pasada en un modelo con un límite de salida más alto es casi siempre más limpia.

Nota de coste: con 50k de salida, Claude Sonnet 4.6 cobra $0,75 por generación ($0,003 entrada en un prompt pequeño + $0,75 salida). Con 50k de salida en gpt-5.5, tendrías que dividir tres veces, pagando entrada dos veces extra; la factura real termina alrededor de $1,00-$1,20 dependiendo de la repetición de contexto.

La regla general para 2026: menos de 100k tokens de contenido relevante, meter contexto es generalmente más simple y da mejores respuestas. Entre 100k y 500k, depende de la densidad de consultas — una única pregunta dirigida se sirve mejor mediante RAG, mientras que un análisis multifacético se beneficia de contexto completo. Por encima de 500k, RAG casi siempre gana en coste, latencia y precisión.

Matemática de costes: una única llamada de Gemini 2.5 Pro con entrada de 1M tokens cuesta $1,25 en entrada. Consultar el mismo documento 10 veces en una sesión cuesta $12,50. Construir un índice de incrustación de los mismos 1M tokens con text-embedding-3-small ($0,02/1M) cuesta $0,02 una sola vez, luego las consultas extraen solo los fragmentos principales (típicamente 5-20k tokens) a $0,0063-$0,025 por consulta — una reducción de costes de 100-1.000x a escala de sesión.

Matemática de latencia: las llamadas de contexto largo toman segundos hasta el primer token (a menudo 5-20s en entradas de 1M tokens). Las consultas de RAG con recuperación de 10k tokens típicamente devuelven el primer token en menos de 1s. La diferencia acumulativa de UX a escala es grande.

Cuándo desafiar la regla: documentos con referencias transversales que ninguna recuperación a nivel de fragmento descubrirá — contratos legales largos donde las cláusulas se referencian entre sí en el documento, análisis financieros multidocumento donde necesitas correlaciones en todas las fuentes, revisiones de código en sistemas fuertemente acoplados. Ahí, el contexto completo te compra algo que RAG no puede.

La mayoría de proveedores cobran una tarifa plana por token independientemente del tamaño de la ventana, pero algunos aplican un recargo por encima de un umbral. A partir de junio de 2026, OpenAI cobra su tarifa estándar hasta la ventana completa en la mayoría de modelos. Anthropic cobra la misma tarifa en toda la ventana de 500k en Sonnet 4.6 y Opus 4.8. Google cobra la misma tarifa hasta 200k en Gemini 2.5 Pro y Gemini 3.1 Pro Preview, con un recargo modesto por encima de ese umbral (confirma en precios de Gemini).

El factor de coste más importante es simplemente que las llamadas de contexto largo procesan más tokens. Una llamada de Gemini 2.5 Pro de 1M tokens cuesta $1,25 solo en entrada, independientemente de cuántos tokens use realmente el modelo. Si llenas la ventana en cada llamada, tu factura de entrada se escala linealmente con el tamaño de la ventana — a 100k llamadas por mes, $125.000.

El almacenamiento en caché de prompts cambia esto dramáticamente. Tanto Anthropic como OpenAI ofrecen descuentos de caché que facturan la porción en caché al 10% de la tarifa estándar. Para consultas repetidas contra el mismo documento grande — una base de conocimientos, un contrato, una base de código — el almacenamiento en caché convierte una llamada de $1,25 en $0,125. Consulta precios de Anthropic Claude y precios de API de OpenAI para los detalles de mecánica de caché.

Cada estimación en la tabla anterior asume prosa inglesa con aproximadamente 0,75 palabras por token. Esa proporción es conveniente para matemática de servilleta, pero es un número de una distribución que corre aproximadamente 3x de ancho dependiendo del idioma, conjunto de caracteres y tipo de contenido. Si estás presupuestando una ventana de 200k o 1M tokens para una carga de trabajo multilingüe, planificar a la tasa de inglés rutinariamente quedará corto en el recuento de tokens real por 50-200%. La misma ventana que contiene 150.000 palabras en inglés contiene solo 60-80.000 caracteres chinos, 40-50.000 líneas de JSON bonito, y en algún lugar entre 8.000 y 12.000 líneas de Python dependiendo del estilo.

Comienza con los propios tokenizadores. La familia GPT de OpenAI usa cl100k_base para GPT-4 y GPT-5.x, una codificación de pares de bytes (BPE) entrenada principalmente en texto web en inglés con aproximadamente 100.277 tokens en el vocabulario. Claude de Anthropic usa su propio tokenizador BPE con fusiones comparables pero no idénticas — los recuentos de tokens entre OpenAI y Claude para el mismo pasaje en inglés típicamente difieren entre 1-4% en ambas direcciones. La familia Gemini de Google usa SentencePiece con un vocabulario de aproximadamente 256k tokens, que comprime scripts no latinos más agresivamente que cl100k_base. Llama 4 usa una variante de SentencePiece de 128k. El tamaño del vocabulario y la distribución de entrenamiento determinan cuán eficientemente se comprime un idioma determinado, y la brecha entre modelos en el mismo texto no inglés puede alcanzar 30-40%.

El inglés se comprime bien porque los tokenizadores BPE ven un texto de entrenamiento en inglés enorme y fusionan subcadenas frecuentes ('ing', 'tion', 'the ') en tokens únicos. La tasa de inglés empírica es 0,73-0,78 palabras por token en los tokenizadores fronterizos modernos, o aproximadamente 4 caracteres por token. Los idiomas románicos (español, francés, italiano, portugués) se sientan ligeramente peor — 0,65-0,72 palabras por token — porque los datos de entrenamiento de BPE sesgados en inglés. El alemán funciona 0,55-0,65 porque las palabras compuestas largas a menudo se fragmentan en 2-4 tokens. El ruso y otros idiomas de script cirílico típicamente funcionan 0,4-0,55 palabras por token. El árabe, con palabras morfológicamente ricas y script de derecha a izquierda, a menudo funciona 0,35-0,5.

Los scripts logográficos y silábicos son el caso punitivo. En cl100k_base, un carácter chino típico cuesta 1,5-2,5 tokens — lo que significa que 100k tokens de chino cabe solo 40.000-65.000 caracteres, o aproximadamente la longitud de una única novela de 200 páginas en lugar del lote de 500 páginas que la misma ventana contiene en inglés. El japonés es ligeramente peor que el chino porque kanji, hiragana y katakana se tokenizarse de manera diferente. El Hangul coreano funciona 1,2-1,8 tokens por bloque de sílaba en cl100k_base. Los tokenizadores de SentencePiece (Gemini, Llama 4) reducen esto aproximadamente a la mitad — Gemini maneja un carácter chino más cerca de 0,8-1,2 tokens — que es una razón real por la que los equipos que ejecutan cargas de trabajo de CJK gravitan hacia Gemini o modelos con tokenizadores similares.

El tipo de contenido importa tanto como el idioma. El código es denso en caracteres pero escaso en tokens por carácter (aproximadamente 1 token por 3,5-4,5 caracteres), sin embargo, pesado en tokens por línea porque los identificadores, la puntuación y los espacios en blanco consumen tokens. Una regla práctica: una ventana de 200k tokens contiene 1.600-2.400 líneas de Python densamente comentado, 1.200-1.800 líneas de Java o C#, 800-1.400 líneas de TypeScript con JSX, o 6.000-10.000 líneas de JavaScript minificado. JSON y XML empujan en la otra dirección — son caros en tokens porque cada comilla, llave y etiqueta es su propio token o dos. Una ventana de 200k tokens contiene aproximadamente 40-55k líneas de JSON formateado o 25-35k líneas de XML. Markdown se sitúa entre prosa y código; la notación matemática en LaTeX está entre las peores, funcionando 0,3-0,5 'conceptos' por token porque cada comando de barra invertida, par de llaves e índice se fragmenta fuertemente.

Ejemplo práctico. Una ventana de contexto de 200k tokens contiene aproximadamente: 150.000 palabras en inglés (aproximadamente 500 páginas), 100.000-120.000 palabras en español, 65.000-80.000 caracteres chinos bajo cl100k_base, 110.000-130.000 caracteres chinos bajo el tokenizador de Gemini, 8.000-12.000 líneas de Python, 4.000-6.000 líneas de XML, o 45.000-55.000 líneas de JSON compacto. Una ventana de Gemini 2.5 Pro de 1M tokens contiene aproximadamente 750.000 palabras en inglés pero solo 550.000-650.000 caracteres chinos — aún vastamente más que lo que cl100k_base cabría, pero muy corto de la extrapolación ingenua en inglés. La regla accionable para cargas de trabajo multilingües es presupuestar a 1,5-2x la tasa de token en inglés para scripts no latinos en OpenAI y Claude, y aproximadamente 1,2-1,5x en Gemini y Llama 4.

El consejo práctico: nunca te comprometas a un tamaño de ventana basado únicamente en recuentos de caracteres o recuentos de palabras. Ejecuta tu contenido real a través del propio tokenizador del modelo — la biblioteca tiktoken de OpenAI para GPT, el punto final count_tokens de Anthropic para Claude, la API count_tokens de Google para Gemini — en una muestra representativa de 5-10 documentos reales, luego planifica con un búfer de seguridad de 20-30% además de la tasa medida. El coste de subestimar es concreto: un flujo de trabajo diseñado para 150k palabras en inglés que en realidad se ejecuta en chino golpeará el límite de ventana de 200k en documento 1, fallará silenciosamente o truncará, e implementará respuestas rotas a los usuarios. Mide primero, luego elige la ventana.

Comienza con la pieza más grande de contenido único que procesa tu carga de trabajo — un documento, un historial de conversación, un fragmento de base de código. Suma el prompt del sistema, definiciones de herramientas, memoria de conversación y un búfer de seguridad del 20%. Ese es tu tamaño de ventana mínimo requerido.

Si la respuesta es menos de 50k, casi cada modelo funciona. Si 50k-200k, elimina Haiku 4.5 y o4-reasoning; todo lo demás califica. Si 200k-500k, elimina Mistral Large 3, DeepSeek V4 y Grok 4. Si 500k+, solo la familia Gemini, Claude Fable 5, gpt-5.5-pro (1M) y Llama 4 (1M-10M) hacen el corte.

Luego prueba la recuperación efectiva. Coloca un hecho conocido en las posiciones 50%, 75% y 90% de tu entrada máxima típica, pide al modelo que lo recupere y verifica. Si la recuperación cae por debajo del 85% después de tu ventana operativa, cambia a RAG en lugar de empujar el modelo a su límite anunciado.

Para la mayoría de equipos el movimiento correcto es: elige un modelo cuya recuperación efectiva cubre el 80% de los tamaños de documentos esperados, usa RAG para la cola larga. Consulta nuestra calculadora de costes GPT vs Claude vs Gemini para un desglose de costes lado a lado en cada tamaño de ventana.