
GPT-6.1 Sol Ventana de contexto: 1.050.000 tokens, la línea de 922.000 y el acantilado de 272.000
- openaiNUEVOOpenAI: GPT-6.1 Sol2026-09-2952Inteligencia
- anthropicNUEVOAnthropic: Claude Sonnet 5.52026-09-2856Inteligencia
- typesafeTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 por 1M de tokens · 111 tok/s
- OpenAIOpenAI: GPT-6 Luna2026-09-2238Inteligencia
- OpenAIOpenAI: GPT-6 Sol2026-09-2248Inteligencia
- AnthropicAnthropic: Claude Opus 5.52026-09-2258Inteligencia
- xAIGrok 4.72026-09-2146Inteligencia
- OrcaOrca: OrcaCyber Zero 1.02026-09-17$3.00 / $7.50 por 1M de tokens · 55 tok/s
- OrcaOrca: OrcaVerify Text 1.02026-09-16$2.00 / $0.00 por 1M de tokens · 347 tok/s
- DeepSeekDeepSeek: DeepSeek V4.1 Flash2026-09-1040Inteligencia
- OpenAIOpenAI: GPT-6 Astra2026-09-0453Inteligencia77Código
- GoogleGoogle: Gemini 3.8 Flash2026-09-0241Inteligencia76Código
- AlibabaQwen: Qwen3.8 Max (0902)2026-09-0245Inteligencia76Código
- AnthropicAnthropic: Claude Fable 5.12026-09-0153Inteligencia82Código
- TencentTencent: Hy4 preview2026-08-28$0.83 / $2.50 por 1M de tokens · 60 tok/s
- AlibabaQwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 por 1M de tokens · 377 tok/s
- z-aiZ.ai: GLM 5.3 Flash2026-08-2642Inteligencia72Código
- DeepSeekDeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.22 / $0.66 por 1M de tokens · 231 tok/s
- z-aiZ.ai: GLM 5.32026-08-1845Inteligencia75Código
- obsidianQwen3.8 27B2026-08-1534Inteligencia68Código
La página del modelo del proveedor para GPT-6.1 Sol, leída el 7 de octubre de 2026, indica una ventana de contexto de 1.050.000 tokens y una salida máxima de 128.000 tokens. La misma página, en la forma legible por máquina que se obtiene al añadir .md a su URL, contiene una tercera cifra que la página renderizada nunca imprime: un máximo de 922.000 tokens de entrada. GPT-6 Sol, el modelo al que 6.1 fue lanzado a suceder el 2026-09-29, publica el par idéntico de cifras máximas en su propia página, y la misma línea de 922.000 en su propio formato markdown. Nuestra propia tarjeta de modelo para openai/gpt-6-sol informa la ventana como 1.050.000 tokens y el límite de salida como 128.000, muestra la primera de esas cifras como "1M" en su franja de especificaciones, e imprime "1.1M" para el mismo modelo en una tabla comparativa más abajo en la misma página.
Así que las páginas sí discrepan, y vale la pena ser precisos sobre cómo. La tira de especificaciones renderizada del proveedor ofrece una ventana y un techo de salida, y ningún techo de entrada. La documentación en Markdown del proveedor para el mismo modelo ofrece los tres. Cualquiera que dimensione una solicitud a partir de la página renderizada trabaja con una restricción menos de las que publicó el proveedor, y la que falta es el número que decide si una solicitud encaja.
Tres cifras, tres fuentes y una resta que nadie escribe
Aquí está cada número con el documento del que proviene, todos leídos el 7 de octubre de 2026.
• Ventana de contexto de 1,050,000 — la página del modelo del proveedor para gpt-6.1-sol, tanto en la franja de especificaciones renderizada como en su formato markdown, y la misma cifra en la página de gpt-6-sol. También es lo que devuelve nuestro catálogo para openai/gpt-6-sol y openai/gpt-6-luna, donde el campo figura como 1,050,000 en lugar de redondeado.
• máximo de 128,000 tokens de salida — la misma página, los mismos dos formatos, para ambas generaciones. El campo de nuestra ficha dice 128,000; su visualización se redondea a «128K».
• 922,000 tokens de entrada como máximo — la forma en markdown de la página del modelo gpt-6-sol del proveedor y de su página de gpt-6.1-sol. No está en la franja renderizada de ninguna de las dos páginas, y no está en nuestro campo de catálogo para el modelo, que se detiene en la ventana y el límite de salida.
Las tres cifras son aritméticamente coherentes entre sí: 922.000 más 128.000 es exactamente 1.050.000. La propia guía de razonamiento del proveedor describe el mecanismo que hace que la identidad tenga sentido sin hacer nunca la suma en la página del modelo: los tokens de razonamiento, dice, "siguen ocupando espacio en la ventana de contexto del modelo", y si los tokens generados "alcanzan el límite de la ventana de contexto o el valor de max_output_tokens que hayas establecido", la respuesta vuelve marcada como incompleta. Una ventana compartida entre lo que entra y lo que sale es una ventana en la que el techo de entrada es la ventana menos la reserva de salida.
Esa lectura está corroborada, no demostrada, y conviene separar ambas cosas. Lo que está documentado es una ventana de 1.050.000, un límite de salida de 128.000 y un máximo de entrada de 922.000. Lo que se infiere es cuál de esos es la restricción que se activa primero. La inferencia se cumple para toda solicitud que reserve su asignación completa de salida y falla para cualquier solicitud que no lo haga: fija max_output_tokens en 4.000 y 1.046.000 tokens de entrada no se rechazan de forma evidente. Hasta que el proveedor escriba esa resta en la página donde viven los números, trata el emparejamiento como la forma del presupuesto y no como una regla de admisión estricta, y valida contra el endpoint de conteo en lugar de contra una entrada de blog.
El contexto no es un precio: el paso de 272.000 tokens
Una ventana más grande es una afirmación sobre la capacidad. No es una afirmación sobre el costo, y en esta familia ambas cosas se separan en una línea documentada. La página de precios del proveedor enuncia la regla en una sola frase: los prompts con más de 272K tokens de entrada se cobran a 2x las tarifas de entrada y caché, y a 1.5x la de salida para la solicitud completa. La propia definición de sus dos columnas en esa misma página es «Contexto corto: ≤272K tokens de entrada. Contexto largo: >272K tokens de entrada».
Lee con atención la palabra full. El nivel no grava únicamente los tokens que superan la línea: vuelve a fijar el precio de todo, incluido el primer token. Y no es un cambio de la 6.1: la regla idéntica, con el umbral idéntico, se aplica a GPT-6 Sol, y por eso el acantilado debe atribuirse al nivel y no al lanzamiento.
Trabaja un trabajo de contexto largo por ambos lados, con las tarifas publicadas de GPT-6.1 Sol, con el prefijo ya residente en la caché para que el cargo por escritura en caché no enturbie la comparación:
• 240,000 tokens de entrada (200,000 en caché, 40,000 nuevos), 6,000 de salida — la entrada nueva de 40,000 a $2.00 por millón es $0.080; la entrada en caché de 200,000 a $0.10 es $0.020; la salida de 6,000 a $10.00 es $0.060. Total, $0.160.
• 300.000 tokens de entrada (260.000 en caché, 40.000 nuevos), 6.000 de salida — la solicitud ahora supera el umbral, así que todas las tarifas cambian: entrada nueva 40.000 a $4,00 son $0,160; entrada en caché 260.000 a $0,20 son $0,052; salida 6.000 a $15,00 son $0,090. Total, $0,302.
Un veinticinco por ciento más de tokens de entrada compra una factura un 89 por ciento mayor. Ejecuta el mismo par en GPT-6 Sol y la forma se mantiene con una pendiente más pronunciada: $0.180 por debajo de la línea frente a $0.354 por encima de ella, porque la tarifa en caché de $0.20 de la tarjeta más antigua se sitúa en el mismo lugar que la tarifa en caché de contexto largo de 6.1. El cruce es un escalón, no una pendiente, y la forma más barata de verlo es cruzarlo por un pelo. Una solicitud de 271,000 tokens totalmente sin caché con 1,000 tokens de salida cuesta $0.552; con 273,000 cuesta $1.107. Siete décimas de un por ciento más de tokens de entrada, 2.01 veces el dinero. Recorta 2,000 tokens de esa solicitud y la factura cae de $1.107 a $0.552: menos del uno por ciento de la entrada por la mitad del costo.
Nada en esta sección tiene que ver con que la ventana de GPT-6.1 Sol sea grande. Tiene que ver con que la ventana sea lo bastante grande como para alcanzar un límite que cuesta más de lo que compra el tamaño de la ventana.

¿Qué llena realmente 1,050,000 tokens?
Un presupuesto de contexto se compone de seis cosas, y no todas se pueden almacenar en caché por igual. Proporciones aproximadas de una solicitud agéntica ilustrativa de 240.000 tokens; las proporciones son nuestras, y las reglas de almacenamiento en caché son del proveedor, procedentes de su documentación sobre prompt caching consultada ese mismo día.
• Contenido de sistema inyectado por el proveedor y formato de las solicitudes — se muestra antes de tus mensajes, se factura como entrada y se excluye explícitamente de la longitud mínima almacenable en caché. No está bajo tu control, ni te corresponde recortarlo.
• Tus instrucciones de desarrollador y del sistema, alrededor de 6.000 tokens. Almacenable en caché. Esta es la parte frontal del prefijo, por lo que un cambio aquí invalida todo lo que está detrás.
• Definiciones de herramientas y esquemas, alrededor de 14.000 tokens para la superficie de herramientas alojadas más tus funciones. Se puede almacenar en caché, y es la parte más frágil del prefijo: la guía enumera los nombres de las herramientas, las descripciones, los esquemas, el orden y las instrucciones específicas de cada herramienta como elementos que desplazan el límite del prefijo.
• El corpus recuperado, unos 180.000 tokens. Se puede cachear y es, con diferencia, la línea más grande. Solo merece la pena cachearlo si es estable byte a byte entre llamadas: un corpus reensamblado en cada solicitud es un corpus a precio completo.
• El registro acumulado — turnos anteriores y resultados de herramientas — de unos 30.000 tokens y en aumento. Almacenable en caché hasta el cambio más reciente; el resultado de la herramienta que llegó en este turno es entrada nueva a la tarifa completa.
• Tokens de razonamiento — se generan, nunca se almacenan en caché y se facturan como salida. Consumen ventana y son invisibles en el cuerpo de la respuesta.
De esa lista se desprenden directamente dos notas operativas. En primer lugar, las entradas de caché se guardan en máquinas individuales: la guía dice que una solicitud puede reutilizar un prefijo «solo si llega a una máquina que contenga una entrada coincidente que no haya expirado», y que el enrutamiento por desbordamiento comienza a partir de unas 15 solicitudes por minuto. Un prefijo que es estable en tu código puede aun así no acertar en producción. En segundo lugar, el prefijo mínimo que se puede almacenar en caché es de 1024 tokens de entrada visibles, y los tokens de sistema ocultos no cuentan para ese mínimo; por lo tanto, un prompt de sistema pequeño no es un prefijo almacenable en caché, por grande que sea la solicitud que lo rodea.
El techo de salida es un presupuesto aparte, no una segunda ración
128,000 tokens máximos de salida no significa 128,000 tokens de respuesta. La guía de razonamiento dice explícitamente que max_output_tokens limita el total que genera el modelo, "incluidos los tokens de razonamiento, los tokens de salida visibles y los tokens de formato no visibles", y que los tokens de razonamiento se facturan como salida mientras ocupan espacio en la ventana.
Eso convierte el truncamiento en una decisión de diseño y no en un caso límite, debido a cómo falla. Cuando la generación alcanza el límite, la respuesta se devuelve con un estado incomplete y un motivo max_output_tokens — y la guía advierte que esto «podría ocurrir antes de que se produzca cualquier token de salida visible, lo que significa que podrías incurrir en costos por tokens de entrada y de razonamiento sin recibir una respuesta visible». Un presupuesto que gasta toda la ventana en la entrada y deja la reserva de salida al azar es un presupuesto que puede facturar una solicitud completa de contexto largo y no devolver nada que quien realiza la llamada pueda analizar. la propia recomendación inicial del proveedor es reservar al menos 25.000 tokens para razonamiento y salidas mientras sigues midiendo lo que realmente necesita un prompt.
GPT-6.1 Sol afina esto, y es una de las pocas líneas genuinamente específicas de 6.1 en la versión. Su escala de esfuerzo de razonamiento incluye low, medium, high, xhigh y max, y las configuraciones none y minimal no son compatibles. GPT-6 Sol acepta las seis. Por lo tanto, no hay ninguna configuración en 6.1 que desactive el gasto de razonamiento, la predeterminada es medium, y el lado de salida del presupuesto nunca es gratuito.
La reducción a la mitad de la entrada en caché, leída donde la ventana es más amplia
La única tarifa en la tarjeta GPT-6.1 Sol que se movió en contra de GPT-6 Sol es la entrada en caché: de $0.20 a $0.10 por millón de tokens, que la página del modelo expresa como el 5% de la tarifa de entrada sin caché, y que la guía de caché del proveedor nombra explícitamente como el caso 0.05x frente al 0.1x al que se leen la mayoría de los modelos GPT-5.6 y posteriores. La entrada, las escrituras de caché y la salida son idénticas en ambas tarjetas, y los multiplicadores de contexto largo también son idénticos.
Para exactamente la carga de trabajo de la que trata esta página, ese es el medidor correcto que se debería haber movido, y la razón es la composición de una solicitud larga, más que su tamaño. En el trabajo de 300,000 tokens de arriba, 260,000 de los tokens de entrada son un prefijo en caché — el 87 por ciento de todo lo que envía la solicitud. Por lo tanto, la línea en caché es el mayor medidor de entrada individual de la factura, lo cual es una propiedad general del trabajo con contexto largo: cuanto más larga sea la ventana que uses, mayor parte de ella será un prefijo que ya has enviado. Reducir a la mitad ese medidor vale $0.052 en esa solicitud.
Y el precipicio se lleva más de lo que da la reducción a la mitad, en la misma solicitud. Con el precio de las tarifas de contexto corto que habría pagado por debajo de la línea, el mismo trabajo de 300.000 tokens en GPT-6.1 Sol costaría $0,166 en lugar de $0,302 — un coste de cruce de $0,136, o aproximadamente 2,6 veces lo que vale el único medidor modificado de la versión. Por encima de la línea, la tarifa en caché marca $0,20, que no es un número nuevo en esta familia: es el doble del titular de la tarjeta 6.1 y exactamente lo que GPT-6 Sol cobraba por una lectura en caché por debajo de la línea antes de esta versión. Una carga de trabajo en caché de contexto largo recoge el cambio del titular y luego lo devuelve en el límite, y el límite —no el modelo— es la causa.

Cómo dimensionar un presupuesto de contexto
Como procedimiento, en el orden en que las restricciones son vinculantes:
• Cuenta la solicitud, no la estimes. Envía mediante POST la carga útil exacta —herramientas, imágenes, archivos y todo— al endpoint de recuento de tokens de entrada de la API de Responses. La guía no se anda con rodeos sobre por qué: el recuento incluye tokens de formato para roles de mensaje y límites que nunca aparecen en el texto que puedes tokenizar localmente, y las estimaciones locales como dividir caracteres entre cuatro son inexactas para imágenes, archivos y esquemas.
• Reserva primero el lado de la salida. Elige max_output_tokens de modo que cubra el razonamiento, la salida visible y el formato en conjunto, y parte del búfer de 25.000 tokens del proveedor en lugar de empezar desde cero. Tu presupuesto de entrada es la ventana menos esa reserva, y la cifra de novecientos veintidós es la versión del proveedor de esa misma resta.
• Calcula el precio de la solicitud en ambos lados de 272,000 antes de enviarla. El escalón es lo bastante grande como para que una solicitud diseñada para quedar justo por debajo del límite y una solicitud diseñada para quedar justo por encima sean productos diferentes.
• Ordene el prefijo por estabilidad.Las instrucciones, luego los esquemas de herramientas, luego el corpus y, por último, la transcripción. Todo lo que cambia entre llamadas debe ir al final, donde cuesta una coincidencia de prefijo en lugar de toda la caché.
• Supere 1.024 tokens de entrada visibles antes de esperar una caché. Por debajo de ese mínimo no se almacena nada en caché, y los tokens ocultos del proveedor no cuentan para ese mínimo.
• Comprueba que la reutilización sea plausible. Un prefijo debe reutilizarse dentro del tiempo de vida de la caché de 30 minutos y debe llegar a la máquina que contiene la entrada; ambos aspectos se describen en la guía y ninguno es una propiedad de tu código.
...Vuelve a medir cualquier cambio de modelo o de configuración. Cambiar a GPT-6.1 elimina el, lo que cambia el token de razonamiento y el lado de salida. Un cambio en el esfuerzo de razonamiento, el esquema de salida estructurada o la gestión del contexto también puede mover un límite de prefijo y costarte por completo la tarifa en caché.
• Decide qué ocurre cuando el trabajo no se reducirá. La compactación es la salida documentada: una solicitud de Responses puede establecer context_management con un umbral de compactación, y el servidor reemplaza el contenido anterior de la conversación con un elemento de compactación opaco que traslada el estado clave con menos tokens. Es una decisión de presupuesto más que un recorte gratuito, porque la guía señala que la compactación «puede impedir la reutilización desde el primer token modificado en adelante»: una pasada de compactación invalida el prefijo que queda detrás.

La aritmética de esta página parte de la generación a la que reemplaza GPT-6.1 Sol, y ese escalón es el que se puede invocar hoy: nuestra ficha de openai/gpt-6-sol reporta una ventana de contexto de 1.050.000 tokens con 128.000 tokens de salida máxima a las tarifas de lista de OpenAI con un 0 % de recargo — el precio del proveedor es el precio que figura en la página, y cualquier cambio del proveedor se refleja ahí el mismo día, no en una renovación. Nuestra ficha no incluye un campo propio de entrada máxima, por lo que la cifra de 922.000 tokens para ese modelo tiene que proceder de la documentación del propio proveedor, que es la que esta página ha utilizado en todo momento. Para lo que resulta útil la ficha es para dimensionar: la ventana y el techo de salida que sí publica son los dos números que el procedimiento de presupuesto anterior resta entre sí, y el escalón inferior es el que realmente puedes usar para aplicar ese procedimiento mientras 6.1 sigue siendo nuevo. Está en https://www.orcarouter.ai/models/openai/gpt-6-sol.
Comparados en este artículo1
Detectado en este artículo · Benchmarks: Artificial Analysis · actualizado a diario
