Benchmarks de coding agéntico: elige modelo sin fallar 2026

TL;DR: Los benchmarks de coding agéntico como Terminal-Bench y SWE-bench miden cosas distintas con harnesses distintos, así que comparar dos números sueltos para elegir modelo en tu CLI casi siempre lleva a una decisión equivocada. En este artículo aprenderás qué mide cada benchmark, por qué un mismo modelo gana en uno y pierde en otro, y cómo montar tu propia mini-evaluación reproducible en menos de una tarde para decidir con tus tareas reales, no con marketing.

El número que viste en Twitter no significa lo que crees

Cuando salió Opus 4.8 medio timeline repetía la misma frase: "supera a GPT-5.5 en coding". El mismo día, otra mitad decía justo lo contrario. Los dos bandos tenían razón, y ese es exactamente el problema.

En las pruebas públicas de junio de 2026, GPT-5.5 lidera Terminal-Bench 2.1 con un 78,2% frente al 74,6% de Opus 4.8. Pero en SWE-bench Pro, que es más difícil, Opus 4.8 saca un 69,2% contra el 58,6% de GPT-5.5. Mismo par de modelos, conclusión opuesta según el benchmark. Si eliges tu modelo por el primer titular que te cruzas, vas a pagar de más o a usar el modelo equivocado para tu tipo de trabajo.

La pregunta correcta no es "¿qué modelo es mejor?", sino "¿mejor en qué tarea, con qué andamiaje y a qué coste?". Vamos a desmontarlo.

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

Un benchmark de coding agéntico mide si un agente de IA puede resolver una tarea de programación completa de forma autónoma, no solo completar una función. El agente lee el repositorio, ejecuta comandos, corre tests, itera sobre sus propios errores y entrega un resultado que se valida automáticamente.

Esto lo distingue de los benchmarks clásicos tipo HumanEval, que solo comprueban si un fragmento de código pasa unos tests. Los dos benchmarks que más vas a ver hoy son distintos entre sí:

SWE-bench (Verified y Pro): mide si el agente arregla bugs reales de repositorios de GitHub. Premia comprensión de código y razonamiento sobre bases grandes. SWE-bench Verified ya está saturado (los modelos top rondan el 88%), por eso la señal útil está en SWE-bench Pro.
Terminal-Bench: mide tareas de línea de comandos que requieren planificar, encadenar herramientas y recuperarse de fallos. Es trabajo más "shell" y DevOps. Según el paper en arXiv, las tareas corren con un harness llamado Harbor que soporta Claude Code, Codex CLI, OpenHands y otros agentes.

La clave: un modelo puede ser excelente arreglando bugs de Python y mediocre coordinando comandos de terminal. Eso no es contradictorio, son habilidades diferentes.

Los números reales (junio 2026) y cómo leerlos

Esta es la comparativa pública de Opus 4.8 y GPT-5.5, con datos reportados por los proveedores y agregadores. Fíjate en que cada fila cuenta una historia distinta:

Benchmark	Qué mide	Opus 4.8	GPT-5.5	Quién gana
SWE-bench Verified	Bugfix autónomo (saturado)	88,6%	~88%	Empate técnico
SWE-bench Pro	Bugfix difícil	69,2%	58,6%	Opus 4.8 (+10pp)
Terminal-Bench 2.1	Flujos de terminal	74,6%	78,2%	GPT-5.5
MCP-Atlas	Uso de herramientas	82,2%	75,3%	Opus 4.8

La trampa número uno: esos números no siempre vienen del mismo harness ni de la misma configuración. Anthropic publica resultados de SWE-bench a veces con una modificación de prompt y promediados sobre varias pasadas; OpenAI reporta sobre su propio Codex. Tomar la cifra de un proveedor y restarla de la del otro no es una comparación limpia, es un espejismo. Un mismo modelo puede subir varios puntos solo cambiando el agente que lo envuelve.

Por eso un benchmark neutral como Terminal-Bench usa Terminus 2, un agente de referencia que ejecuta todos los modelos con el mismo andamiaje. Cuando compares, comprueba siempre que la fila usa el mismo harness. Si no lo dice, sospecha. Esta lógica de no fiarse del número aislado es la misma que aplica al decidir entre modelos dentro de tu CLI, algo que ya tratamos en la comparativa sobre cómo repartir planificación y ejecución entre Fable y Opus.

El coste no aparece en el ranking, y es lo que te arruina

Un benchmark de pass rate te dice quién acierta más, no quién te sale rentable. Y la diferencia es brutal en la práctica.

En una prueba reciente de la comunidad con Harbor sobre 10 tareas difíciles de Terminal-Bench 2.1, GPT-5.5 (vía Codex) resolvió 9 de 10 en cerca de una hora por unos 11€ aproximados. Opus 4.8 (vía Claude Code) tardó más de dos horas, se quedó atascado casi una hora en una sola tarea (un ejercicio de regex) y costó más de 23€. El detalle interesante: Opus generó alrededor de 3,3 veces más tokens de salida y casi 4 veces más input cacheado.

Traducción para tu factura: el modelo con mejor pass rate puede ser el que te vacía el plan antes de tiempo. A precios oficiales de API rondando los 5€ por millón de tokens de entrada y 25-30€ por millón de salida, el perfil de consumo de cada modelo pesa tanto como su acierto. Este es justo el agujero del que hablamos cuando un agente cruza los 200k tokens y dispara el presupuesto, y la razón por la que conviene vigilar tokens y coste en tiempo real desde tu editor.

Cómo leer cualquier benchmark sin que te engañen

Antes de creer un ranking, pásalo por estos cinco filtros. Si falla alguno, el número vale menos de lo que parece:

Mismo harness: ¿los modelos corrieron con el mismo agente, o cada proveedor usó el suyo? Sin esto no hay comparación.
Versión y fecha: ¿es Terminal-Bench 2.0 o 2.1? ¿SWE-bench Verified o Pro? Mezclar versiones invalida la resta.
Saturación: si todos pasan del 85%, el benchmark ya no discrimina. Busca el más difícil.
Effort y trials: ¿el número es de un intento o promedio de 25? ¿Con qué nivel de esfuerzo? Opus 4.8 a esfuerzo mínimo iguala a Opus 4.7 a máximo en SWE-bench Pro, así que el ajuste cambia todo.
Coste por tarea: ¿incluye tokens y precio? Un pass rate sin coste es media verdad.

Monta tu propia mini-evaluación en una tarde

Ningún benchmark público usa tu código ni tus tareas. La forma honesta de decidir es montar una evaluación pequeña y reproducible con problemas que se parezcan a tu día a día. No necesitas infraestructura: con Harbor, el mismo harness de Terminal-Bench, ejecutas un set fijo de tareas contra varios modelos.

Este comando lanza un subconjunto del benchmark con un agente y modelo concretos, repitiendo cada tarea 5 veces para tener señal estadística:

# Ejecuta Terminal-Bench con un agente/modelo y k=5 pasadas para medir varianza
harbor run -d terminal-bench@2.1 -a "claude-code" -m "claude-opus-4-8" -k 5

Para que la comparación sea tuya y no de un agregador, lo importante es fijar el set de tareas que de verdad haces. Define una lista corta y honesta, mejor 8-10 casos representativos que 200 genéricos:

# Tu mini-suite: tareas que reflejan tu trabajo real, no las del marketing
mi_suite = [
    "refactor_endpoint_fastapi",   # lo que haces a diario
    "fix_n1_query_orm",            # tu dolor recurrente
    "migrar_script_bash_a_python", # tarea de terminal real
    "anadir_test_pytest_cobertura",
]
# Corres cada tarea con 2-3 modelos y registras: pass rate, coste, tiempo

Con eso tienes tres columnas que sí importan: acierto en tus tareas, coste real y tiempo. Esa tabla decide mejor que cualquier titular. Si quieres ir más allá, la lógica de aislar el entorno de ejecución para correr estas pruebas sin riesgo encaja con lo que explicamos sobre por qué tu agente necesita un buen harness.

En Producción

Pasar del benchmark a tu flujo diario cambia varias cosas. Esto es lo que importa cuando el modelo deja de ser un número y se convierte en tu compañero de trabajo:

Routing por tarea, no por moda: si tu trabajo es shell y DevOps, el líder en Terminal-Bench te conviene; si es arreglar bugs en repos grandes, mira SWE-bench Pro. No hay un modelo por defecto universal.
Presupuesto de tokens: mide el coste por tarea en tu suite antes de cambiar el modelo por defecto del equipo. Un modelo que genera 3x más salida multiplica la factura aunque acierte igual.
Atascos: en producción un modelo que se cuelga una hora en una tarea no es un detalle, es un incidente. Pon límites de tiempo y de tokens por tarea.
Reproducibilidad en CI: si automatizas evaluaciones, fija la versión del benchmark y del harness. Un cambio de minor en el agente puede mover los resultados sin que toques el modelo.

Errores comunes y depuración

Error: Comparas el 88,6% de Opus en SWE-bench Verified con el 78,2% de GPT-5.5 en Terminal-Bench. → Causa: son benchmarks distintos, no se restan. → Solución: compara solo dentro de la misma fila, mismo benchmark y misma versión.

Error: Eliges el modelo con mayor pass rate y tu factura se dispara. → Causa: ignoraste el coste por tarea y el perfil de tokens. → Solución: añade coste y tiempo a tu tabla de decisión, no solo acierto.

Error: Tu mini-eval da resultados distintos cada vez. → Causa: una sola pasada por tarea tiene mucha varianza. → Solución: usa k=5 o más y mira la media con su margen de error, igual que hacen los leaderboards serios.

Preguntas frecuentes

¿Cuál es el mejor benchmark para elegir un modelo de coding?

No hay uno solo. Para bugfix en repos usa SWE-bench Pro; para flujos de terminal y DevOps usa Terminal-Bench 2.1. Lo más fiable es montar tu propia mini-suite con tareas parecidas a tu trabajo real y medir acierto, coste y tiempo.

¿Por qué Opus 4.8 gana en SWE-bench pero pierde en Terminal-Bench?

Porque miden habilidades distintas. SWE-bench premia comprensión de código y razonamiento sobre bases grandes, mientras Terminal-Bench premia planificar y encadenar comandos de shell. Un modelo puede destacar en una y quedarse corto en la otra sin contradicción.

¿Puedo correr Terminal-Bench yo mismo?

Sí. Las tareas corren con el harness Harbor, que soporta Claude Code, Codex CLI y otros agentes. Puedes ejecutar un subconjunto contra varios modelos con un comando y comparar pass rate, coste y duración en tu propia máquina.

Lo que te llevas

Hemos visto que un benchmark de coding agéntico no es un veredicto, es una medición acotada a una tarea, un harness y una configuración concretos. GPT-5.5 y Opus 4.8 se intercambian el liderazgo según mires terminal o bugfix, y el coste real (tokens, tiempo, atascos) rara vez aparece en el titular que comparte la gente. La decisión sensata no es creer el ranking más viral, sino montar una mini-evaluación con tus propias tareas y medir las tres cosas que de verdad pagas: acierto, dinero y tiempo.

La próxima vez que veas "el modelo X destroza al modelo Y", pregúntate en qué benchmark, con qué harness y a qué coste. Esa pregunta te ahorra más dinero que cualquier optimización de prompt.

¿Has montado tu propia evaluación para elegir modelo, o tiras de los leaderboards públicos? Cuéntamelo en los comentarios o en Twitter @sergiomarquezp_. En el próximo artículo monto una mini-suite completa con Harbor paso a paso y comparo tres modelos sobre tareas reales de backend.