Me topé con el error de ventana de contexto de Codex durante una sesión larga en Codex CLI. No es lo mismo que los límites de uso de 5 horas y semanal. Esos límites son restricciones de tiempo que fija tu plan. Este error aparece cuando los tokens acumulados en una sola sesión superan lo que el modelo puede procesar.
/compact no siempre lo resolvía. Aquí cuento qué hice en ese momento y cómo elijo ahora entre cuatro comandos: resume, fork, new y clear.
¿Cuándo aparece el error de ventana de contexto en Codex?
El error de ventana de contexto de Codex no salta de repente en una conversación corta. Se va acumulando en sesiones largas de refactorización que pasan por varios módulos, y pesa más hacia el final.
En mi caso, la tarea era ordenar lógica existente en un repositorio multimódulo de Java/Spring. Empezó como un cambio de dos o tres archivos. Luego el alcance que tenía que investigar no dejó de crecer, y se fueron acumulando los archivos leídos y los diffs. Repetí varias veces el ciclo: correr los tests → ver por qué fallaban → corregir el código → volver a correrlos.
No falló de golpe. En la segunda mitad de la sesión, cada vez más seguido tenía que volver a confirmar cosas que ya habíamos decidido u ordenar el contexto. Esas señales se repitieron varias veces hasta que al final terminaron en el error.
Si hubiera sido un script de un solo archivo, creo que no se habría llenado tan rápido. Trabajar con varios módulos y archivos de test a la vez es lo que acelera el consumo de contexto.
No lo confundas con el límite de uso de 5 horas o semanal
Este error es independiente de agotar tu uso. Los límites de uso se reinician con el tiempo. La ventana de contexto depende de cuántos tokens se acumularon en una sesión, así que puede aparecer aunque todavía te quede uso.
¿Qué conserva /compact y qué se pierde?
En mis sesiones, /compact conservó el objetivo general, los archivos principales y las decisiones ya tomadas. El porqué de las decisiones más finas muchas veces tuve que volver a explicarlo. Es una forma de seguir con la sesión, no un checkpoint que recuerda la conversación completa.
Usar /compact tampoco resolvió todo. Cuando la sesión ya era demasiado larga, o la dirección del trabajo había cambiado varias veces, después de compactar tuve que volver a añadir explicaciones. Hoy no repito /compact una y otra vez para aguantar hasta el final. En cuanto siento que el costo de explicar el contexto volvió a crecer, me paso a una sesión nueva.
Además, la compactación no siempre se activa sola. Este es el mensaje de error tal como aparece reportado en un issue de GitHub: “Codex ran out of room in the model’s context window. Start a new thread or clear earlier history before retrying.” (GitHub issue #19269, 24 de abril de 2026). En la comunidad de desarrolladores de OpenAI también hay un caso con el mismo mensaje. La cuenta OpenAI_Support solo respondió pidiendo versión, modelo y logs. Todavía no hay una solución de fondo.
Las 5 cosas que vuelvo a fijar después de compactar
Después de compactar, vuelvo a escribir una frase para cada uno de estos puntos:
- El objetivo final de la tarea actual
- El alcance de los cambios en esta sesión
- Los tests que siguen fallando
- Los enfoques que probé y descarté
- Las zonas que no se deben tocar
Resume, fork, new o clear: ¿cuál usar en Codex?
Resume continúa la misma línea de decisiones. Fork prueba una decisión distinta desde el mismo contexto. New empieza de cero llevando solo los hechos ya confirmados.
Si los usas indistintamente, el contexto suele enredarse más. Así los separo según la situación:
| Comando | Qué hace | Cuándo lo uso | Qué se queda y qué se pierde |
|---|---|---|---|
/compact |
Comprime el contexto dentro de la misma sesión | La sesión sigue viva y el costo de volver a explicar el contexto apenas empieza a subir | Se quedan el objetivo general, los archivos principales y las decisiones. Puede que tengas que volver a explicar el contexto detallado |
codex resume --last |
Continúa la misma sesión tal cual | La dirección sigue siendo correcta y solo hay que seguir con los detalles | Se queda el historial anterior. Pero si el contexto ya estaba lleno, el error puede volver |
codex fork --last |
Abre una rama nueva desde el mismo contexto | Quiero conservar el contexto hasta ahora, pero probar otro enfoque | Se queda el contexto existente. A partir de ahí, el avance se separa por rama |
/new |
Inicia una sesión nueva | Las hipótesis y los enfoques descartados se acumularon y el contexto mismo quedó contaminado | El contexto detallado anterior desaparece. Tú tienes que volver a escribir los hechos confirmados |
/clear no es un comando que use seguido. No tengo un caso concreto con él, así que solo dejo constancia de que lo uso poco.
¿Cuándo pasar a una sesión nueva de Codex?
Pasa a una sesión nueva cuando volver a explicar el contexto empiece a costar más que comprimirlo y mantenerlo. Que el contexto sea largo, por sí solo, no es el problema.
No creo que conservar mucho contexto sea siempre una ventaja. Sobre todo en trabajos como una refactorización, donde las decisiones intermedias cambian todo el tiempo. Para mí fue más estable, en algún punto, quedarme solo con los hechos confirmados y llevarlos a una sesión nueva, en lugar de comprimir el contexto viejo y seguir cargándolo.
La forma de medir ese momento es sencilla.
Si ya compactaste y aun así cada vez más seguido tienes que volver a añadir explicaciones, mantener la sesión ya cuesta más que empezar de nuevo.
¿Por qué no confío del todo en el auto-compact? (a septiembre de 2026)
La confiabilidad de la compactación automática ha cambiado según la versión. Si te aparece este error, conviene revisar primero en los issues de GitHub si se trata de una regresión conocida.
El umbral de compactación automática no es una cifra de la documentación oficial. Es un comportamiento interno que se confirma en issues de GitHub. Según el GitHub issue #11805, desde la v0.100.0 el umbral de compactación que configura el usuario queda se limita de forma forzosa al 90% de la ventana de contexto (abierto el 14 de febrero de 2026, hoy cerrado como “not planned”). También hay reportes aparte de que la compactación automática no se ejecuta en absoluto. Un ejemplo es el issue que reporta que en la v0.42.0 compact no se ejecuta automáticamente cuando hay un conjunto de cambios grande.
Esta sección refleja la situación al momento de escribirla (septiembre de 2026). Si se estabilizó después, hay que volver a comprobarlo.
Preguntas frecuentes
¿Qué hago si el error de ventana de contexto sigue después de /compact?
Puede ser la regresión en la que la compactación automática no se activa. En ese caso, en lugar de repetir compact, es más estable pasar a una sesión nueva escribiendo antes una frase para el objetivo, el alcance de los cambios y los tests que fallan.
Si cambio con codex resume --last o fork --last, ¿se conserva mi trabajo anterior?
Resume continúa el historial tal cual, pero si el contexto ya estaba lleno, el error puede volver. Fork crea una rama nueva conservando el contexto existente, aunque no preserva por completo cada detalle.
Si Codex tiene auto-compact, ¿por qué intervenir a mano?
Hay reportes de que en algunas versiones la compactación automática no se activa. Primero revisa si lo que te pasa es una regresión conocida. Es mejor no fiarte de ella y tener el manejo manual como opción por defecto.
Referencias
- GitHub issue #19269: caso reproducido de referencia (fuente primaria) del mensaje de error “Codex ran out of room…” (2026-04-24, Codex CLI v0.124.0)
- Hilo de la comunidad de desarrolladores de OpenAI: otro caso del mismo error, con la respuesta de OpenAI_Support (sin solución de fondo)
- GitHub issue #11805: fuente del límite forzado del umbral de compactación automática al 90% de la ventana de contexto desde la v0.100.0 (2026-02-14, cerrado como not planned)
- GitHub issue #4363: reporte de regresión en el que compact no se ejecuta automáticamente en la v0.42.0 con un conjunto de cambios grande
Este artículo fue localizado a partir del original en coreano: https://jjeongil.tistory.com/3568.