GPT-5.5 vs Opus 4.8: cómo leer el benchmark de coding 2026

TL;DR:

El titular engaña. GPT-5.5 gana a Opus 4.8 en Terminal-Bench 2.1 (78,2% vs 74,6%), pero ese número de GPT-5.5 sale con el harness de Codex CLI, no con el estándar Terminus-2. No es una comparación cara a cara.
Un benchmark de coding agéntico mide un sistema, no un modelo. El andamiaje (scaffold) puede mover el resultado entre 10 y 20 puntos con los mismos pesos del modelo.
Lo que importa en producción no es la tasa de aprobados, sino el coste por tarea resuelta, la varianza y si el benchmark se parece a tu trabajo real.

El problema: decidir tu modelo por un titular

Sale una comparativa nueva, "modelo X gana a Y en Terminal-Bench", y media comunidad cambia su CLI de coding esa misma tarde. El último ejemplo es GPT-5.5 contra Claude Opus 4.8 en coding por terminal. El veredicto que circula es simple: GPT-5.5 pasa más tareas, va más rápido y cuesta menos.

El veredicto no es falso. Es incompleto. Y elegir tu benchmark de coding agéntico de referencia por el porcentaje de la portada es la forma más rápida de meter en producción un modelo que no encaja con tu repo. Vamos a leer estos números con criterio, usando el caso GPT-5.5 vs Opus 4.8 como banco de pruebas.

¿Qué es un benchmark de coding agéntico?

Un benchmark de coding agéntico es una batería de tareas de programación reales que un agente resuelve de forma autónoma, ejecutando comandos, leyendo salidas e iterando, donde se mide cuántas completa correctamente. No puntúa solo al modelo: puntúa al modelo más su andamiaje, sobre una variante concreta y bajo condiciones concretas.

Las dos familias que vas a ver en cada lanzamiento:

SWE-bench: resolver issues reales de GitHub con su suite de tests. Tiene cinco variantes (original, Verified, Pro, Multilingual, Live) y comparar entre ellas es un error metodológico.
Terminal-Bench: tareas duras en una terminal, que exigen planificar, iterar y recuperarse de errores en un bucle de shell. Es el que más se parece a un agente de DevOps o de infraestructura.

Los números reales (y dónde está la trampa)

Esto es lo que publicó Anthropic en el lanzamiento de Opus 4.8 (mayo de 2026). Léelo en horizontal, no por la columna que más te conviene:

Benchmark	Opus 4.8	GPT-5.5	Qué mide
SWE-bench Pro	69,2%	58,6%	Issues reales, multi-archivo, resistente a memorización
SWE-bench Verified	88,6%	~88%	Subset solucionable, casi saturado
Terminal-Bench 2.1	74,6%	78,2%	Bucle agéntico en shell
OSWorld-Verified	83,4%	78,7%	Uso de ordenador / computer use
MCP-Atlas	82,2%	75,3%	Uso de herramientas vía MCP

La trampa está en la fila de Terminal-Bench. Según el desglose del propio lanzamiento, el 78,2% de GPT-5.5 se obtuvo con el harness de Codex CLI, no con Terminus-2, que es el que se usa para el resto de modelos. Estás comparando un modelo con su andamiaje optimizado contra otro con el andamiaje estándar. No es lo mismo, y por eso un único número de "Terminal-Bench" puede valer 74%, 78% o 83% según quién lo corra.

El harness lo cambia todo

Aquí está la idea que un tutorial de "qué modelo es mejor" nunca te da: el andamiaje (scaffold o harness) que rodea al modelo puede mover el resultado entre 10 y 20 puntos sobre los mismos pesos. El contexto que le inyectas, el límite de turnos, las herramientas disponibles, cómo gestionas la memoria. Todo eso puntúa.

Dicho de otra forma: una puntuación de SWE-bench es ininterpretable sin saber qué harness la produjo. Un número alto reportado por el fabricante con su andamiaje a medida y un número más bajo en un leaderboard estandarizado pueden ser, los dos, correctos para el mismo modelo. Si quieres entender por qué el andamiaje pesa tanto, esto conecta con la lógica del harness recursivo que orquesta subagentes en Claude Code: el agente no es el modelo, es el sistema entero.

Regla práctica: solo compara números producidos bajo el mismo harness. En cuanto el scaffold cambia, dejas de comparar modelos y pasas a comparar productos distintos.

Caso real: 10 tareas duras de Terminal-Bench 2.1

Un test de la comunidad que circuló esta semana ilustra bien el punto. Cogió 10 tareas difíciles de Terminal-Bench 2.1 y las pasó por Opus 4.8 (vía Claude Code) y GPT-5.5 (vía Codex), midiendo aprobados, coste, duración y tokens. Conversión a euros aproximada:

Métrica	GPT-5.5 (Codex)	Opus 4.8 (Claude Code)
Tareas pasadas	9 de 10	Menos, atascado en una tarea
Duración total	~1 hora	~2 h 23 min
Coste aproximado	~10,70 €	~22 € o más
Tokens de salida	126K	423K (~3,35x más)
Input cacheado	3,93M	15,39M (~4x más)

En el titular, GPT-5.5 arrasa: más rápido, más barato, más aprobados. Pero mira el detalle: Opus pasó password-recovery, que GPT-5.5 falló, y se quedó colgado casi una hora en regex-chess. Una sola tarea patológica le destrozó el tiempo y el coste medios. Con n=10, un caso atípico arrastra toda la media. Eso es varianza, y es justo lo que el porcentaje agregado esconde.

Qué mide un benchmark, y qué NO mide

El paper de Terminal-Bench deja un par de hallazgos incómodos para quien decide por número:

No hay correlación entre número de turnos y éxito. Un agente que da más vueltas no resuelve más.
Más tokens generados no implica mejor resultado. El perfil de Opus (mucho output, mucho cacheado) no se traduce en ventaja automática.
El coste por tarea va de céntimos a más de 90 € en una sola tarea larga. La media no te dice tu coste real.

Lo que un benchmark público no mide: tu base de código, tus convenciones, tu definición de "correcto". Es una señal poblacional útil, no una predicción sobre tu repo. Este mismo punto es el que defiendo cuando hablo de por qué tu evaluación offline miente y hay que medir en producción.

Cómo leerlo con criterio: replica un subset

La única forma de convertir un benchmark en una decisión es validarlo contra tus tareas. No necesitas correr las 200 tareas oficiales. Con 10 o 15 tareas representativas de tu trabajo real ya tienes señal.

Y la métrica que de verdad manda no es la tasa de aprobados, sino el coste por tarea resuelta. Un modelo que pasa el 70% a 1,80 € por tarea es una decisión de producción distinta a uno que pasa el 65% a 0,40 €. Calcularlo desde los logs de una corrida es trivial:

# Calcula coste por tarea RESUELTA, no por tarea intentada: es la metrica que decide en produccion
from dataclasses import dataclass

@dataclass
class Run:
    task_id: str
    passed: bool
    cost_eur: float  # coste de esa tarea en euros

def coste_por_exito(runs: list[Run]) -> float:
    resueltas = [r for r in runs if r.passed]
    if not resueltas:
        return float("inf")  # no resolvio nada: coste util infinito
    coste_total = sum(r.cost_eur for r in runs)  # pagas tambien los fallos
    return coste_total / len(resueltas)

# Caso minimo ejecutable con los numeros del test de 10 tareas
gpt = [Run(f"t{i}", i != 4, 1.07) for i in range(10)]   # 9/10, ~10,70 € total
opus = [Run(f"t{i}", i < 4, 2.20) for i in range(10)]   # 4/10, ~22 € total

print(f"GPT-5.5: {coste_por_exito(gpt):.2f} €/exito")
print(f"Opus 4.8: {coste_por_exito(opus):.2f} €/exito")
# GPT-5.5: 1.19 €/exito  |  Opus 4.8: 5.50 €/exito

Ese número, coste dividido entre tareas que de verdad resolviste (pagando también los intentos fallidos), reordena leaderboards. Es el mismo principio que aplico al elegir modelo de IA por coste real y no por el benchmark.

Cuándo fiarte de un benchmark y cuándo desconfiar

Fíate cuando...	Desconfía cuando...
Mismo harness para todos los modelos	Un modelo usa su CLI propietaria y el resto el estándar
Reporta coste y varianza, no solo % medio	Solo ves un porcentaje agregado de la portada
La variante está explícita (Pro, Verified, Live)	Dice "SWE-bench" a secas sin variante
Las tareas se parecen a tu dominio	Extrapolas de tareas triviales a tu enterprise repo
Hay logs reproducibles	Número del fabricante sin trazas públicas

En Producción

Lo que cambia entre el benchmark y tu lunes por la mañana:

Coste por tarea resuelta, no por millón de tokens. A precio de lista, ambos rondan ~4,70 € por millón de input; Opus está en ~23,50 € por millón de output y GPT-5.5 en ~28 €. Pero Opus genera 3x más output en tareas largas, así que el coste efectivo se invierte según el tipo de trabajo.
Latencia y tareas patológicas. En un agente desatendido, una tarea que se cuelga una hora (como regex-chess) no es una anécdota: es un timeout que tienes que cortar. Pon límites de turnos y de presupuesto por tarea.
Varianza entre corridas. Corre tu subset 3 veces, no una. Un único pase con n bajo te miente con confianza.
Reparto por tipo de trabajo. Opus 4.8 lidera en resolución de issues multi-archivo (SWE-bench Pro); GPT-5.5 en bucles de shell (Terminal-Bench). Si tu agente vive en la terminal arreglando CI, gana GPT-5.5; si hace migraciones a escala de repo, gana Opus.

Si al borrar esta sección el artículo siguiera igual, sería relleno. No lo es: el criterio operativo (coste por éxito, varianza, límites de presupuesto) es justo lo que el porcentaje de portada te oculta.

Errores comunes y depuración

Error: "GPT-5.5 saca 8 puntos más en Terminal-Bench, me cambio." → Causa: comparas su número con harness Codex contra el Terminus-2 de Opus. → Solución: exige el mismo andamiaje o ignora la comparación cruzada.
Error: media de coste baja pero la factura real se dispara. → Causa: una tarea atípica larga arrastra la cola de distribución. → Solución: mira la mediana y el percentil 95, no solo la media.
Error: el modelo que ganó el benchmark falla en tu repo. → Causa: el benchmark no se parece a tu dominio (enterprise, multi-archivo, contexto propietario). → Solución: replica un subset con tus tareas antes de fijar el modelo por defecto.

Preguntas frecuentes

¿GPT-5.5 es mejor que Opus 4.8 para programar?

Depende del tipo de coding. GPT-5.5 lidera Terminal-Bench 2.1 (coding agéntico en shell) y es más barato en input. Opus 4.8 lidera SWE-bench Pro (resolución de issues reales multi-archivo) por más de 10 puntos. No hay un ganador único: hay dos ganadores en dos tareas distintas.

¿Por qué el mismo modelo saca puntuaciones distintas en "SWE-bench"?

Porque "SWE-bench" no es un número, es una familia con cinco variantes, y el harness alrededor del modelo puede mover el resultado entre 10 y 20 puntos. Un 50% y un 70% pueden ser ambos ciertos para el mismo modelo según variante y andamiaje.

¿Cuántas tareas necesito para validar un modelo en mi caso?

Con 10 a 15 tareas representativas de tu trabajo real, corridas 2 o 3 veces, ya tienes señal útil de coste por éxito y varianza. Es más informativo que el porcentaje oficial sobre 200 tareas que no se parecen a tu repo.

Cierre

Hemos visto que un benchmark de coding agéntico mide un sistema completo, no un modelo suelto, y que el andamiaje pesa tanto como los pesos. La portada de GPT-5.5 vs Opus 4.8 es real pero incompleta: un harness distinto, una varianza alta y un coste por tarea que el porcentaje medio esconde. La clave está en mirar el mismo andamiaje para todos, exigir coste y varianza junto al porcentaje, y replicar un subset con tus propias tareas antes de cambiar nada. Si quieres profundizar en por qué la mayoría elige mal, esto enlaza directamente con cómo los benchmarks de coding agéntico te hacen elegir mal tu modelo.

¿Has corrido tu propio subset de Terminal-Bench o SWE-bench con tus tareas? Cuéntame qué número de portada te ha decepcionado en la práctica en los comentarios o en Twitter @sergiomarquezp_. En el próximo artículo monto un harness mínimo y reproducible para correr ese subset con tus propios casos.