GPT-5.6 Sol cae en la sobreingeniería. Aun así, lo uso

GPT-5.6 Sol lleva mis tareas más allá de lo necesario, pero sigue siendo el mejor modelo que he usado para encontrar riesgos. En una auditoría de lanzamiento señaló unos 400 posibles problemas, frente a 70 de Fable 5. La mayoría no superó el triaje. Ahora lo uso en solo lectura y dejo que otro modelo decida qué merece un parche.

¿GPT-5.6 Sol cae en la sobreingeniería? El patrón se repite

Sí. GPT-5.6 Sol ha llevado varias veces mi trabajo más allá de lo necesario, y varios relatos de r/codex describen el mismo comportamiento. La comparación directa más clara usó Sol 5.6 High y Fable 5 High para trabajos idénticos, y algunas implementaciones de Sol eran tres veces mayores [2].

Un ejemplo fue un backfill de DynamoDB que Fable completó en unas 100 líneas. La versión de Sol ocupó unas 400 porque añadió protecciones contra condiciones de carrera, comprobaciones de lectura tras escritura y lógica para alternar entre lecturas consistentes y no consistentes. Ninguno de esos elementos hacía que el código fuera incorrecto, pero juntos complicaban la comprensión y validación de un cambio sencillo [2].

Cambiar el nivel de razonamiento o el modo no elimina el comportamiento. Un usuario dio a Sol en xhigh un plan claro y límites explícitos de alcance, pero el modelo siguió persiguiendo «casos límite de casos límite» [3]. Otro usuario llegó al tercer día de una ejecución con Sol Ultra sin superar el primer gran hito porque los bugs pequeños y el endurecimiento adicional desplazaban una y otra vez el objetivo principal [4].

El mismo hilo muestra lo rápido que esa insistencia puede agrandar un cambio. Una auditoría con corrección automática reescribió secciones enteras de un sitio web y obligó al usuario a revertir la mitad del resultado; otra tarea convirtió una corrección funcional de index + 1 en más de 1.000 líneas modificadas [4]. Por eso, varios usuarios prefieren High a Ultra: se mantiene más cerca del objetivo y exige menos coordinación [5]. Otros cuentan que los bucles de revisión reabren durante horas problemas ya resueltos, incluido uno que duró ocho horas [6].

En el debate sobre GPT-5.6 de Hacker News aparece un reparto de trabajo parecido: algunos usuarios emplean Codex como revisor estricto y reservan Claude para los problemas difíciles y el diseño de alto nivel [7]. Los relatos de la comunidad muestran que el comportamiento puede repetirse. La propia documentación de OpenAI ayuda a entender por qué.

OpenAI reconoce que Sol puede ir más allá de la intención del usuario

La ficha del sistema de GPT-5.6 afirma que Sol va más allá de la intención del usuario con más frecuencia que GPT-5.5, incluso mediante acciones que nadie le pidió. OpenAI considera bajas las tasas absolutas, pero recomienda supervisar las sesiones largas con agentes de programación [8].

La guía de prompting convierte esa advertencia en una regla práctica: define límites claros para la autonomía y la aprobación, y mantén la explicación, la revisión y la planificación separadas de la implementación [9]. La guía de modelos de Codex añade que Ultra combina el máximo nivel de razonamiento con delegación automática. OpenAI describió cuatro agentes paralelos como configuración predeterminada durante el lanzamiento [1], pero recomienda Ultra solo cuando el trabajo contiene partes realmente independientes y afirma que la mayoría de las tareas no necesita Max ni Ultra [10].

Esos documentos hacen que mi experiencia resulte menos extraña. Sol está diseñado para insistir, mientras que los niveles de razonamiento superiores y los agentes adicionales le dan más margen para hacerlo. En la práctica, un prompt como «déjalo listo para producción» señala una dirección, pero no una línea de meta. Soy yo quien tiene que definirla. Cuando OpenAI lanzó GPT-6 Astra, comprobé si el modelo nuevo respeta el alcance mejor que Sol en Codex.

¿Qué pasó con la ventana de contexto de Sol? Codex bajó a 272K

GPT-5.6 Sol sigue admitiendo 1,05 millones de tokens de entrada mediante la API y puede producir hasta 128K tokens de salida [11]. La suscripción es otro producto: el centro de ayuda de OpenAI indica una ventana de 272K para Sol en ChatGPT Business [12]. La especificación de la API no describe el contexto disponible con la suscripción.

El límite de la suscripción cambió cuatro días después del lanzamiento. Una incidencia de GitHub en openai/codex registra la caída del perfil del servidor de 372.000 tokens brutos (353.400 efectivos) a 272.000 (258.400 efectivos) el 13 de julio, una reducción del 26,9 % [13]. Más tarde, un empleado de OpenAI escribió en X que el perfil grande consumía demasiado rápido el uso de la suscripción y que volvería [14]. El 29 de julio de 2026, la documentación de OpenAI seguía mostrando 272K [12]. Los límites de la suscripción volvieron a cambiar más tarde, algo que trato en por qué Codex Plus puede detenerte aunque quede cuota semanal.

En cambio, el centro de ayuda de Claude documenta una ventana de un millón de tokens para Fable 5 y Opus 5 en Claude Code con los planes de pago [15]. Esa diferencia importa porque un contexto de trabajo menor hace más probable que las decisiones anteriores sobre el alcance pasen por la compactación durante una ejecución larga.

Ver los datos en una tabla

Producto	Valor
Sol vía API	1050K
Codex en el lanzamiento, 9 de julio	372K
Codex desde el 13 de julio	272K
Claude Code, Fable 5 y Opus 5	1000K

El gráfico concreta la diferencia entre productos: Claude Code ofrece actualmente a sus modelos competidores casi cuatro veces más contexto del que Sol recibe con una suscripción [15].

Codex gestiona un contexto lleno comprimiendo las partes antiguas de la conversación. La compactación automática y el comando /compact resumen el chat visible, y la página de buenas prácticas de OpenAI desaconseja mantener un proyecto entero en una sola conversación [16].

Ahí es donde la ventana más pequeña se convierte en un problema para mi flujo de trabajo. En mis sesiones con Sol suelen perderse precisamente las restricciones que controlan el alcance: riesgos aceptados, funciones que decidimos no crear o un simple «no añadas sobreingeniería». La documentación de subagentes de OpenAI denomina context pollution y context rot a problemas relacionados [17]. El código no es lo que se vuelve frágil. Lo frágil es el acuerdo sobre lo que Sol debe dejar intacto.

¿Por qué cuesta controlar Sol Ultra? La coordinación se convierte en trabajo

Sol Ultra añade agentes sin limitar al agente principal a la delegación. La documentación de OpenAI explica que el software puede crear, dirigir y reunir hilos de agentes, pero el agente principal aún puede leer, razonar e implementar mientras esos hilos están activos [17]. El resultado es más capacidad sin un límite equivalente sobre quién hace cada tarea.

Dos informes del repositorio de GitHub openai/codex muestran el coste de esa coordinación. En uno, el agente principal decidió que un subagente lento pero operativo se había bloqueado y repitió su trabajo sin avisar. Esto consumió más tokens y llenó el contexto principal de material duplicado [18].

En otro informe, los turnos de espera y estado representaron el 19,8 % del volumen bruto de tokens de un usuario porque el modelo se reanudaba cada 30 o 60 segundos para comprobar agentes que seguían trabajando con normalidad [19]. La cifra procede de telemetría del usuario, no de datos de facturación, pero la consecuencia práctica está clara: coordinar a los agentes puede convertirse en una tarea importante por sí misma.

Mi caso más frustrante fue un documento de arquitectura de sistemas. Fable 5 produjo un diseño coherente en una hora, aproximadamente, mientras que Sol Ultra tardó unas cuatro porque dividió un problema estrechamente conectado entre agentes paralelos y después tuvo que resolver sus supuestos contradictorios.

El equipo de ingeniería de Anthropic encontró el mismo límite en su propio sistema multiagente: el trabajo paralelo compensa cuando una tarea amplia tiene líneas independientes, mientras que la programación suele ofrecer menos oportunidades de dividir el trabajo que la investigación. Anthropic también informa de que sus ejecuciones multiagente utilizaron unas 15 veces más tokens que un chat normal [20]. En trabajos de arquitectura, demasiado paralelismo puede generar más coordinación de la que elimina. Más tarde, OpenAI describió un problema de coordinación aún más extraño, cuando sus agentes internos convirtieron el almacenamiento compartido de Artifactory en un tablón.

Ultra también puede responder desde un punto anterior de la conversación. Dos veces pedí a Sol una actualización de estado, recibí una respuesta útil y, media hora después, lo vi contestar otra vez al mismo mensaje. En GitHub hay informes de Codex muy parecidos: una sesión devolvió una respuesta copiada de muchos turnos antes [21], y otra issue describe cómo Codex respondió a un mensaje anterior en lugar del último [22].

Cuando ocurre, dejo de confiar en la conversación como registro del estado actual. Compruebo el repositorio con git y la suite de tests, y traslado la tarea a una sesión nueva.

Mi auditoría de lanzamiento: Sol encontró más, pero Fable juzgó mejor

Sol Ultra devolvió unos 400 posibles problemas en mi auditoría de lanzamiento, frente a unos 70 de Fable 5. La mayoría de los hallazgos adicionales de Sol no superó el triaje, pero unos pocos revelaron problemas reales que Fable había pasado por alto. Sol fue claramente mejor para la búsqueda amplia; Fable, para decidir qué importaba.

Antes del lanzamiento, di a ambos modelos el mismo gran sistema de producción y las mismas instrucciones de solo lectura sobre seguridad, lógica y consistencia entre servicios. La lista de Sol daba mucho peso a la severidad alta, mientras Fable colocaba primero los problemas críticos y mostraba poco interés por las numerosas posibilidades de severidad media.

hallazgos de Sol Ultra

400

muchos resultados de severidad alta y media

hallazgos de Fable 5

70

mismas instrucciones, primero los problemas críticos

La figura compara el volumen de resultados, no los bugs confirmados. Pedí a Fable que tratara los 400 hallazgos de Sol como afirmaciones sin demostrar y los revisara uno por uno. Rechazó muchos duplicados, casos límite teóricos y sugerencias de endurecimiento que Sol había presentado como bugs, pero también confirmó varios problemas reales que su propia auditoría había pasado por alto. La cobertura adicional de Sol resultó útil, pero solo después de que otra revisión eliminara el ruido.

Artificial Analysis muestra una diferencia parecida en dos benchmarks. Sol Max lidera su Coding Agent Index con una puntuación de 80 y Fable 5 queda por detrás. En el índice general de inteligencia, en cambio, Fable gana 60 a 59 y obtiene una ventaja más clara en la evaluación de calidad analítica [23]. Estas evaluaciones no reproducen mi auditoría, pero respaldan una conclusión más limitada: encontrar candidatos y juzgarlos son capacidades distintas.

Durante la semana del lanzamiento ignoré esa diferencia y pedí a Sol que corrigiera todos los elementos de su propia lista. Muchos cambios parecían razonables por separado, pero el resultado completo no era seguro para publicar. Al final, pasé un fin de semana eliminando el trabajo adicional.

La documentación de seguridad de OpenAI recomienda ahora casi exactamente el flujo que debería haber usado. Indica que hay que aceptar un hallazgo y generar un parche limitado, en vez de pedir a un agente que corrija en un solo chat todos los resultados de un análisis [24]. También recomienda el cambio seguro más pequeño, respaldado por pruebas de regresión específicas, con una tarea separada para cada hallazgo [25]. Y hay una distinción clave: los hallazgos importados siguen sin demostrarse hasta que un triaje de solo lectura emite un veredicto para cada uno [26]. Esa separación convierte la larga lista de Sol en material útil para revisión, no en una lista de tareas sin control.

Cómo uso GPT-5.6 Sol: auditoría amplia, parches acotados

Dejo que Sol busque de forma amplia, pero no le doy permiso para cambiar el código. Otro modelo decide qué hallazgos son reales y, después, un agente con límites estrictos corrige un problema aceptado cada vez. Así conservo la mejor cualidad de Sol sin dejar que decida el alcance, el presupuesto ni cuándo termina el trabajo.

arquitectura

• Fable 5 crea un diseño coherente

instrucciones fijas

auditoría

• Sol Ultra búsqueda amplia con acceso de solo lectura

afirmaciones, no hechos

triaje

• Fable 5 un veredicto por hallazgo

cola aceptada

corrección

• Agente acotado un hallazgo, presupuesto de cambio

El reparto es sencillo: Fable se encarga de la arquitectura y de las decisiones finales, Sol busca posibles problemas y el agente que implementa recibe una tarea acotada en vez de una misión general. Tres reglas prácticas mantienen esos papeles:

• Mantén las auditorías en modo de solo lectura e indica exactamente cuándo terminan. «Continúa hasta que no queden problemas» da permiso a Sol para buscar sin límite, mientras «una pasada, un veredicto por hallazgo y después para» define una tarea que sí puede terminar.
• Da a cada corrección un presupuesto de cambio. Nombra el hallazgo y los ficheros permitidos, fija un límite de líneas y prohíbe la limpieza no relacionada:

Fix only finding SEC-014.
Allowed files: src/billing/ and its tests.
Budget: at most 3 files and 120 net lines. No new dependencies.
No adjacent cleanup, no refactors, no extra hardening.

Revalidate the finding first. Then the smallest safe patch,
plus one regression test that fails before it and passes after.

Stop when that test and the existing suite are green.
If the budget does not fit, stop before editing and report
the blocker and the smallest viable alternative.

• Guarda las decisiones duraderas en el repositorio. Las reglas estables van en un fichero AGENTS.md breve [27]. El entregable actual y su condición de parada van en un goal, que OpenAI diseñó para conservar los objetivos tras la compactación [28]. Las decisiones y el estado actual van en Markdown con control de versiones, como recomienda la guía de OpenAI para tareas largas [29]. El chat sigue siendo útil para conversar, pero no debe ser el único lugar que recuerde el contrato.

Este flujo no convierte Sol en una simple advertencia. Sigue siendo el revisor más potente que he usado para análisis amplios y encontró problemas reales que Fable había pasado por alto. Incluso el hilo «72 hours», que registra bucles graves, atribuye a Sol haber reducido casi a la mitad el tiempo de ejecución de un pipeline paralelo complejo [4]. La idea es usar esa capacidad donde aporta valor.

En mi artículo anterior sobre Opus 5, defendí que incluso un modelo capaz necesita una gestión clara. Mi regla para Sol es más estricta: busca en todas partes, no cambies nada y envía cada afirmación a un juez distinto. Así conservo la cobertura adicional sin darle permiso para agrandar la tarea.