GPT-6.1 Sol en COBOL: 86,6 % frente a 5,4 %, y solo una de las dos pruebas puede volver a ejecutarse

El 19 de octubre de 2026, O​penAI publicó dos evaluaciones de programación para lenguajes de bajos recursos, y la cifra principal corresponde a GPT-6.1 Sol: el 86,6 % de las tareas de migración de COBOL se superaron con un esfuerzo de razonamiento bajo, frente al 5,4 % de GPT-5.6 Sol con la misma configuración, y asciende al 97,9 % cuando aumenta el esfuerzo. La segunda evaluación, MultiLangBench, es la historia de otro modelo: GPT-6 Astra promedió el 87,4 % en veinte lenguajes con el esfuerzo máximo, pero es la mitad más útil del lanzamiento, porque O​penAI publicó su harness en GitHub bajo Apache-2.0 y puedes ejecutarlo tú mismo esta tarde. La evaluación de migración de COBOL, la que conlleva el 86,6 %, es otro asunto: sus pruebas están ocultas, su criterio de aprobación es la paridad de salida byte a byte con casos que nadie fuera de O​penAI ha visto, y ningún tercero la ha reproducido. Esa asimetría es toda la historia, y vale la pena decirlo claramente antes de que cualquiera de las dos cifras se cite en un caso de negocio de migración. Las fallas de IA documentadas y los incidentes de agentes detrás de lanzamientos como este se recopilan en el Archivo de Incidentes de IA de OrcaRouter donde cada entrada incluye sus propias fuentes, gravedad, grado de confianza y marca de disputa.

Una fecha que conviene tener clara. GPT-6.1 Sol en sí es del 29 de septiembre de 2026 — esto no es un lanzamiento, y nada de lo que hay aquí cambia los pesos, el precio ni la tarifa del modelo. Lo que ocurrió el 19 de octubre es que OpenAI publicó evidencia sobre lo que el modelo puede hacer en una categoría que antes no había documentado, y lanzó un benchmark que cualquiera puede volver a ejecutar. De eso trata este artículo.

Qué se publicó en realidad y para qué sirve cada mitad.

Las dos evaluaciones responden a preguntas distintas, y el propio planteamiento de OpenAI las separa. MultiLangBench pregunta si un modelo puede construir algo en un lenguaje con el que nadie entrena: implementar SQLite 3.40.1 desde cero en uno de veinte lenguajes de programación y luego superar una suite de conformidad de bases de datos. La evaluación de migración de COBOL pregunta si un modelo puede mover algo: traducir programas COBOL a C++, Java, Kotlin, Python o Rust preservando exactamente el comportamiento observable.

La primera es una prueba de umbral mínimo de capacidad. La segunda es la que realmente les importa a las empresas, porque COBOL no es una curiosidad de benchmarks — las estimaciones de larga data de IBM sitúan a COBOL detrás de más del 40 % de los sistemas bancarios en línea y de alrededor del 95 % de las transacciones en cajeros automáticos, y el código lo mantiene una fuerza laboral que no se está reemplazando.

• MultiLangBench, máximo esfuerzo — GPT-6 Astra 87,4%, GPT-6 Luna 40,3%, GPT-5.6 Sol 26,8%. Astra superó el 83% en 19 de 20 idiomas; COBOL fue su punto más débil con 72,1% frente al 10,9% de GPT-5.6 Sol, lo que indica que el lenguaje más difícil del conjunto sigue siendo el que tiene las herramientas más antiguas.

• Migración de COBOL, bajo esfuerzo — GPT-6.1 Sol 86,6 %, GPT-5.6 Sol 5,4 %, con un coste de API estimado del 61 % del modelo anterior para la ejecución de evaluación, o un 39 % menos.

• Migración de COBOL, mayor esfuerzo — GPT-6.1 Sol 97.9%, que OpenAI describe como cercano a la saturación.

• Detalle por lenguaje que OpenAI sí publicó — Fortran 83,5 % para Astra frente a 21,4 % para GPT-5.6 Sol; Visual Basic 89,4 % frente a 27,5 %; OCaml 85,8 % frente a 25,6 %; GPT-6 Luna con 17,1 % en COBOL, 31,4 % en Fortran, 34,1 % en OCaml y 41,6 % en Visual Basic.

• Costo por muestra en MultiLangBench — un estimado de $0.77 para GPT-6 Luna frente a $3.48 para GPT-5.6 Sol, aproximadamente un 78% menos, que es la cifra que hace que el modelo más débil de la tabla sea el interesante para un pipeline de generación de compilaciones.

La evaluación que puedes volver a ejecutar: qué pide realmente MultiLangBench

El repositorio es github.com/openai/MultiLangBench, Apache-2.0, y leer el arnés de pruebas resulta más informativo que leer la tabla de clasificación. La tarea es lo bastante específica como para que un modelo no pueda farolear con ella: producir un ejecutable que tome una ruta de base de datos como argumento de línea de comandos, lea una consulta SQL desde stdin y se comporte como SQLite 3.40.1. Las pruebas provienen de la propia suite TCL de SQLite —unas 51.000 pruebas en total, de las cuales aproximadamente 24.000 se convirtieron en las tripletas que usa el arnés: una base de datos inicial, una consulta del usuario y una consulta de validación. Los nombres de las pruebas son hashes SHA-256 de esos componentes, así que la suite no se puede memorizar por nombre.

Las reglas son donde vive la dificultad, y cada una cierra un atajo:

• Sin internet y sin SQLite en ninguna parte del entorno. El arnés indica que primero se elimine todo rastro de SQLite. Un modelo no puede invocar el motor real desde la shell ni puede obtener una implementación.

• La validación se ejecuta contra SQLite 3.40.1 real. Su implementación modifica la base de datos; el arnés la extrae y la verifica con el original auténtico. El comportamiento aproximado falla.

• Sesenta segundos por prueba, y una respuesta en el idioma equivocado obtiene cero. Mezclar idiomas falla, y el sistema de evaluación señala que puede usarse otro modelo para comprobar en qué idioma escribiste realmente. Esa última regla existe porque la trampa obvia —escribirlo en Python y envolverlo— es lo primero que intenta un modelo capaz.

• La ejecución rápida consta de 272 pruebas, no de 24.000. El README recomienda ejecutar solo las pruebas cuyos nombres empiezan por 00, 01 o 02 cuando quieras un número comparable. Ese es el detalle que hay que tener en cuenta antes de comparar tu propia puntuación con la de OpenAI: una ejecución del conjunto completo y una ejecución rápida no son la misma medición, y el README lo dice.

Eso es un benchmark real y verificable. También te dice algo que la cobertura de prensa no mencionó: el titular del 87,4% se midió en una suite que puedes aplicar a tu propio modelo, algo lo bastante raro como para merecer la descarga.

La evaluación que no puedes volver a ejecutar, y por qué eso no es automáticamente un escándalo.

La evaluación de la migración de COBOL está diseñada, ejecutada y puntuada por O​penAI, y sus casos de prueba no se publican. El umbral de aprobación se enuncia con precisión —una migración solo cuenta si cada prueba oculta produce una salida observable idéntica byte a byte—, y esa precisión es exactamente lo que hace que el resultado no se pueda verificar desde fuera: el 86,6 % es la medición de O​penAI contra los propios casos ocultos de O​penAI. Solo una de las dos evaluaciones de la publicación es algo que un lector puede reproducir.

No es indefendible retener las pruebas de migración. El corpus presumiblemente proviene de programas heredados reales, y publicarlo puede filtrar código de clientes o entregar a modelos futuros un conjunto de entrenamiento. La paridad byte a byte también es un criterio genuinamente conservador, más estricto que la mayoría de las evaluaciones de proveedores: no premia una traducción que solo sea aproximada.

Pero el criterio también es donde empiezan los problemas prácticos, y las propias advertencias de OpenAI lo señalan. El resultado de la migración sigue necesitando revisión experta y pruebas contra las reglas de negocio y las dependencias del sistema antes de producción. Y la paridad de bytes es difícil exactamente en los lugares donde COBOL es difícil: el lenguaje trunca y redondea la aritmética de punto fijo de formas en que la mayoría de los lenguajes destino no lo hacen, así que una traducción puede parecer correcta, pasar una suite que comprueba que "es suficientemente cercano", y aun así mover un saldo por un centavo. Una suite oculta que requiere igualdad exacta se encarga de eso; tu propio proceso de revisión también tiene que encargarse de ello, porque la puntuación del modelo no es una afirmación sobre tus programas.

La cifra de coste necesita el mismo cuidado. El ahorro del 39 % es una estimación para la ejecución de la evaluación —tokens de entrada y salida del benchmark—, no el coste de reemplazar un sistema en producción, que está dominado por el descubrimiento, la revisión por expertos, las pruebas de integración y los años de comportamiento no documentado que ninguna evaluación alcanza a muestrear.

Qué deberían cambiar el 86,6 % y el 97,9 % en una decisión

La lectura honesta es más limitada que los titulares y más útil que ellos. Una base del 5,4 % no es un modelo que funciona a medias; es un modelo que casi nunca produce una traducción que preserve el comportamiento, así que la generación anterior nunca fue candidata para este trabajo. GPT-6.1 Sol con un 86,6 % está en el rango en el que la economía se invierte: una herramienta que redacta la mayor parte de una traducción y deja que un revisor la compruebe es un producto distinto de uno que no produce nada utilizable.

El 97,9 % con mayor esfuerzo es la cifra de la que hay que desconfiar, no porque sea incorrecta, sino porque está saturada. Cuando un benchmark se acerca a su techo, deja de discriminar entre modelos y empieza a medir la suite, y O​penAI lo dice explícitamente. Para planificar, trata el 86,6 % con bajo esfuerzo como el punto de operación económico y el 97,9 % como el techo de lo que la evaluación puede mostrarte —no como una promesa de precisión para tu base de código.

También conviene hacer una verificación cruzada, y va en contra del hype. En la prueba de build, COBOL siguió siendo el lenguaje más débil de GPT-6 Astra con un 72,1%, aunque Astra es el modelo más fuerte en general con un 87,4% de promedio. El lenguaje es difícil en ambas direcciones. Un modelo que migra bien COBOL en una evaluación oculta no por ello es bueno en COBOL; es bueno en el patrón que muestrea la evaluación.

La otra cosa que ocurrió esta semana: la afirmación sobre la traza de razonamiento

Una publicación ampliamente compartida el 21 de octubre afirmaba que las trazas de razonamiento de GPT-6.1 Sol son "totalmente legibles, nada de qué preocuparse". Nada en la publicación de OpenAI del 19 de octubre, ni nada en la página de documentación del propio modelo, respalda que eso sea un cambio en lo que devuelve la API. La guía de razonamiento de OpenAI es explícita en que los tokens de razonamiento sin procesar no se exponen —los elementos de razonamiento siguen siendo opacos— y en que lo que se puede solicitar es un resumen del razonamiento mediante el parámetro summary, con el contenido de razonamiento cifrado reproducido entre turnos. GPT-6.1 Sol admite la forma all_turns de esa reproducción. Un canal de resumen no es una traza legible, y tratar ambos como si fueran lo mismo es como se hace una afirmación de seguridad mediante una captura de pantalla.

Lo que es medible es adyacente y más interesante para cualquiera que audite a un agente. La evaluación de Sonar del 9 de octubre de GPT-6.1 Sol, ejecutada frente a GPT-6 Sol con esfuerzo medio sobre 4.444 tareas de Java, encontró que los tokens de razonamiento cayeron un 51,4 % —de 2,64 M a 1,28 M—, mientras que la proporción de razonamiento dentro de la salida bajó del 41,8 % al 19,5 %, la salida aumentó y la tasa de aprobación funcional mejoró del 83,09 % al 85,29 %. La misma ejecución encontró una densidad de vulnerabilidades un 32,4 % menor, pero los hallazgos de fiabilidad de severidad crítica subieron de 21 a 46, con los errores de concurrencia como la categoría más grande, con 196 hallazgos. Esa es una contrapartida sobre la que un revisor puede actuar. «Las trazas son legibles» no lo es, porque las trazas no son lo que se devuelve.

Para un proyecto de migración, esto importa de una forma concreta: tu rastro de auditoría es el diff y la salida de las pruebas, no la narración del modelo. Presupuesta la capacidad de revisión en consecuencia — el hallazgo de Sonar de que un 39,4 % más de código generado produjo 12.982 hallazgos totales frente a 9.859 es la forma del costo que se esconde detrás de una puntuación de benchmark.

Ejecutar ambos brazos por tu cuenta

El problema práctico de una comparación como esta es que el brazo de referencia y el nuevo brazo suelen ser dos contratos, dos claves y dos relaciones de facturación, lo que genera suficiente fricción como para que nadie ejecute la línea base. Ambos modelos están en nuestro catálogo detrás de una sola clave: openai/gpt-6.1-sol y openai/gpt-5.6-sol, a los precios de lista de OpenAI con un 0 % de margen, es decir, los mismos $2.00 de entrada y $10.00 de salida por millón de tokens que pagaría al proveedor, con la entrada en caché a $0.10 y las escrituras en caché a $2.50, y el tramo de más de 272K repercutido a $4.00, $0.20, $5.00 y $15.00. Un cambio de tarifa del proveedor se aplica aquí el mismo día en que se publica, en lugar de en la próxima revisión del contrato.

Ese paso directo es lo que hace barato ejecutar un benchmark del mismo día: apunta la suite rápida de MultiLangBench a ambos modelos, paga el precio de lista en cada uno y tendrás una cifra sobre tu propia cadena de herramientas en lugar de la de OpenAI. La conmutación automática por error es la otra mitad del argumento: si el modelo más reciente se degrada a mitad de ejecución o una ruta queda limitada por velocidad, la solicitud no falla con él, lo que te permite poner un modelo no probado delante de una canalización de migración antes de tener tus propias evidencias.

El arnés de MultiLangBench es público y los casos de migración de COBOL no, así que la única prueba honesta del 86,6 % es la que construyas tú: toma una muestra de unos cientos de tus propios programas COBOL, tradúcelos y compara la salida byte por byte con el comportamiento original. Eso es una semana de trabajo y vale más que la tabla del proveedor.

Qué ver a continuación

Tres cosas cambiarían este panorama, y ninguna ha ocurrido todavía. Que O​penAI publique los casos de migración de COBOL, o que un laboratorio independiente los vuelva a ejecutar, convertiría una cifra de proveedor en una medición. Que un tercero reproduzca la tabla por lenguaje de MultiLangBench nos diría si el 72,1% de COBOL es una propiedad del lenguaje o del conjunto de pruebas. Y el historial independiente del modelo en los benchmarks —Artificial Analysis sitúa actualmente a GPT-6.1 Sol con un Intelligence Index de 52, duodécimo de 214 modelos, a 55,2 tokens de salida por segundo y 0,72 dólares por tarea del índice— es la comprobación que no depende en absoluto de las evaluaciones internas de O​penAI.

Hasta entonces, el resumen útil es breve. GPT-6.1 Sol es un modelo del 29 de septiembre cuya capacidad para código heredado se documentó el 19 de octubre, en una evaluación que puedes ejecutar y otra que no. La que se puede ejecutar dice que la nueva generación está en otra categoría en lenguajes de bajos recursos. La que no se puede ejecutar dice que la migración de COBOL ahora merece un piloto. Solo tu propio código base puede convertir cualquiera de las dos en una decisión.