Codex con GPT-6.1 Sol recorta la ventana a 828 400, pero dejó pasar una entrada de 888 mil tokens

En ~/.codex/config.toml figura model_context_window = 1000000, pero en cada tarea Codex con GPT-6.1 Sol informa de una ventana de 828 400 tokens. El autor de un análisis en Habr averiguó de dónde sale esa cifra, la subió a 900 000 con un catálogo de modelos propio y probó una entrada sintética de 890 547 tokens con marcas de control. La conclusión principal vino de la ejecución de control: el mismo texto, con 888 330 tokens, también pasó con la ventana estándar de 828 400. La ventana de Codex no limita el tamaño de un único mensaje de entrada.

De dónde sale 828 400

Codex recibe los parámetros del modelo desde el servidor y los guarda en caché en ~/.codex/models_cache.json. La entrada de GPT-6.1 Sol contiene context_window 500 000 (el valor por defecto), max_context_window 872 000 (el config no puede subir la ventana por encima de esa cifra) y effective_context_window_percent 95. Resultado: 872 000 × 0.95 = 828 400.

El autor lo comprobó en más de una sesión. De los registros de ~/.codex/sessions tomó las últimas 40 tareas: 39 con gpt-6.1-sol y una del servicio codex-auto-review. En los 39 eventos token_count aparece model_context_window: 828400. El valor está en el campo info.model_context_window, mientras que la entrada y la salida reales de la última solicitud se encuentran en last_token_usage. El formato del registro no está documentado como estable, así que el campo puede cambiar de lugar tras una actualización del cliente.

Prueba con 890 mil tokens y marcas

Mediante el parámetro model_catalog_json, el autor conectó una copia del catálogo del servidor en la que gpt-6.1-sol tiene max_context_window de 1 000 000 y un porcentaje de 90. El resultado fue 900 000. El margen del 10% lo tomó de pruebas de septiembre con GPT-6 Astra: allí una entrada exitosa fue de 900 089 tokens, mientras que un relleno a partir de 909 000 terminaba en error de desbordamiento.

El relleno tiene que ser denso en tokens: en septiembre, un texto de 1 720 376 caracteres lo detuvo el propio cliente, que no dejó pasar mensajes de más de 1 048 576 caracteres. Por eso la prueba usa ideogramas aleatorios U+4E00–U+9FA4 con semilla fija 42, unos 1,9 tokens por carácter. En tres puntos del texto se insertaron las marcas R7K2, Q9M4 y W3T8, y el modelo debía devolverlas en orden.

• Un breve «OK», catálogo propio, ventana de 900 000: entrada de 57 187 tokens. Es la parte de servicio de la configuración del autor: instrucciones, reglas, descripciones de herramientas y habilidades.
• Calibración, 30 302 caracteres, catálogo propio: 115 300 tokens, 3 de 3 marcas.
• Ejecución grande, 434 302 caracteres, catálogo propio: 890 547 tokens, 3 de 3 marcas, 62 s, cached_input_tokens 9 216.
• Control, mismo texto, catálogo del servidor, ventana de 828 400: 888 330 tokens, 3 de 3 marcas, 60 s, sin caché.
• La diferencia entre las dos últimas entradas es de 2 217 tokens. El relleno es idéntico; la causa está en la parte de servicio, pero el autor no la investigó con precisión.

Qué define realmente la ventana

La ayuda describe el campo como «Context window tokens available to the active model». Tibo Sotto, del equipo de Codex, explicó que una ventana mayor permite a Codex retener más código, salida de herramientas e historial antes de comprimir el material antiguo. Es decir, la cifra determina el momento de la autocompresión. El umbral lo controla un parámetro aparte, model_auto_compact_token_limit, y model_auto_compact_token_limit_scope en modo total cuenta todo el contexto activo, mientras que en modo body_after_prefix solo cuenta el incremento posterior al prefijo trasladado.

El techo real figura en la página de GPT-6.1 Sol de la documentación de la API: ventana de 1 050 000 tokens y entrada máxima de 922 000. Esto concuerda con los errores de septiembre. En la API, las solicitudes con más de 272 mil tokens de entrada cuestan el doble. Según Sotto (publicación del 11.10.2026), la suscripción no tiene recargo por contexto largo en GPT-6.1 Sol, y la ventana por defecto en Codex se elevó de 272 a 500 mil. El autor no encontró esto en la documentación. Tampoco midió cuánto límite de la suscripción consume una solicitud de 890 mil.

Catálogo propio: qué se rompe tras una actualización

model_catalog_json sustituye el catálogo del servidor por un archivo estático, y el autor tropezó con ello. En septiembre subió el límite solo para gpt-6-astra; después el modelo principal pasó a ser gpt-6.1-sol, y en su copia conservó los antiguos 872 000 y 95%. El aumento a 900 000 desapareció en silencio y todas las tareas de trabajo se ejecutaron con 828 400. Además, la copia no incluye gpt-6.1-terra, y la ventana por defecto de Sol es allí de 272 000 en lugar de los 500 000 del servidor.

La gestión experimental del contexto [features.context_management] está desactivada desde el 12.09.2026: Sotto escribió que el equipo apagó un experimento opt-in que podía provocar paradas prematuras o respuestas a mensajes antiguos. Afectó a entre 4 y 5 mil usuarios. En el catálogo, GPT-6.1 Sol, GPT-6.1 Terra y GPT-6 Astra tienen supports_experimental_context: false, y la bandera del config no activa nada.

Conclusión práctica para quienes trabajan con Codex. No persigas el millón en el config: lo que te limita es el max_context_window del servidor. Para ver la ventana real, lee model_context_window en el registro de la tarea. Si conectas un catálogo propio, reconstrúyelo a partir de un models_cache.json reciente después de cada actualización del cliente y comprueba la ventana en una tarea nueva. En las 39 tareas de trabajo del autor, la entrada más grande fue de 389 543 tokens, así que 828 mil alcanzan con holgura. La siguiente prueba será una sesión larga hasta la autocompresión: con qué volumen se activa según la ventana y cuántas marcas sobreviven a la compresión.