Tu CLI de coding se elige con tu repo, no con Terminal-Bench

TL;DR: El CLI de coding que encabeza Terminal-Bench esta semana no es necesariamente el mejor para tu código. El ranking mide tareas que no son las tuyas, y hasta 7 puntos de diferencia entre agentes vienen del harness, no del modelo. La decisión fiable es montar un mini-eval reproducible de 10-20 tareas reales de tu propio repo con criterio paso/no-paso. Aquí tienes la plantilla copiable y la regla para decidir si una suscripción te basta o necesitas dos.

El instinto: abrir el leaderboard y pagar al número uno

Ya tienes el dedo encima de cambiar de suscripción. Sale una comparativa nueva, ves que Codex CLI con GPT-5.5 lidera Terminal-Bench 2.1 con un 83,4% frente al 78,9% de Claude Code con Opus 4.8 (leaderboard de mediados de junio 2026), y la conclusión parece obvia: migrar al que puntúa más alto.

Ese instinto falla por un motivo técnico concreto, no por filosofía. Un benchmark agéntico mide el acierto medio sobre un set de tareas fijo y genérico: administración de sistemas, entrenar modelos, optimizar queries. Terminal-Bench 2.1 son 89 tareas en un entorno sandbox (según la nota oficial de la 2.1). Ninguna de esas 89 tareas es tu monorepo de FastAPI con 40 servicios, tu convención de imports ni tu suite de tests que tarda seis minutos. El número agrega un universo de tareas que no se parece al tuyo.

Hay un segundo problema que casi nadie mira: el harness pesa tanto como el modelo. El mismo GPT-5.5 puntúa 83,4% dentro de Codex CLI y baja a 76,4% ejecutado a través del harness Terminus 2 sobre el mismo benchmark (análisis de junio 2026). Son 7 puntos que no tienen nada que ver con el modelo y todo con el bucle de agente que lo envuelve: cómo gestiona contexto, reintentos y uso de herramientas. Elegir "el modelo del ranking" ignora que estás comprando un harness, no solo pesos.

Un benchmark de coding agéntico mide el acierto medio sobre tareas ajenas; tu decisión depende del acierto sobre las tuyas y del harness que las ejecuta.

La regla de decisión: tu repo es el único benchmark que cuenta

La regla, mojada: si vas a pagar o cambiar de CLI, primero corre 10-20 tareas reales de tu repo en cada candidato y compara acierto, coste y latencia por tarea. Si el ganador del leaderboard no gana en tu mini-eval, no migres. El benchmark público sirve principalmente para descartar (un agente que va 15 puntos por debajo en todo raramente te sorprenderá), no para elegir entre los de cabecera, que en junio 2026 están a 13,7 puntos entre el primero y el sexto (leaderboard de Terminal-Bench 2.1).

Esto conecta con una idea que ya tratamos al hablar de por qué los benchmarks de coding agéntico te hacen elegir mal el modelo: el problema no es el benchmark, es usarlo fuera de su contexto. Y enlaza con la disciplina de medir tu IA en producción y no solo offline: un eval propio es eso mismo aplicado a tu flujo de desarrollo.

El artefacto: plantilla de mini-eval para tu codebase

Define cada tarea con estos campos. La clave está en el criterio paso/no-paso binario y verificable sin opinión: o el test pasa, o no.

# mini-eval.yaml — 10-20 tareas reales de tu repo
- id: bugfix-01
  tipo: bugfix              # bugfix | feature | refactor | test | búsqueda
  prompt: "El endpoint /users/{id} devuelve 500 con id inexistente. Arréglalo."
  criterio_paso: "pytest tests/test_users.py::test_not_found pasa en verde"
  ground_truth: "Devuelve 404 con cuerpo {detail: 'not found'}"
  max_intentos: 1           # un solo turno, sin guiarlo a mano

- id: feature-02
  tipo: feature
  prompt: "Añade paginación cursor-based al listado de pedidos."
  criterio_paso: "tests nuevos pasan Y respeta el patrón de pagination.py existente"
  ground_truth: "Usa el helper Cursor ya presente, no reinventa"
  max_intentos: 1

Reparte las tareas según tu trabajo real, no a partes iguales: si el 70% de tu día es arreglar bugs y añadir endpoints pequeños, que el 70% del eval sea eso. Y mide tres columnas por candidato, no una:

Métrica	Cómo medirla	Por qué importa
Acierto	% de tareas que pasan al primer intento	Es tu SWE-bench privado; lo único que mide tus tareas
Coste/tarea	Tokens o créditos consumidos por tarea resuelta	Un acierto del 90% que quema el límite semanal en dos días no sirve
Latencia/tarea	Minutos hasta resultado verificable	En un monorepo grande, el contexto enorme dispara la espera
Fidelidad al repo	¿Respeta convenciones o reinventa?	El coste oculto es la revisión, no la generación

El score que decide no es el acierto pelado. Una fórmula práctica para puntuar cada candidato:

# Pondera acierto por el coste de revisar lo que genera
# (un agente que acierta el 70% pero hay que revisar todo puede salir más caro que hacerlo tú)
def score(aciertos, total, min_revision_media, min_tarea_manual):
    tasa = aciertos / total
    # ahorro neto = tiempo manual evitado menos tiempo de revisión
    ahorro = tasa * (min_tarea_manual - min_revision_media)
    return round(ahorro, 1)  # minutos netos ahorrados por tarea; si es <=0, no compensa

Si el score sale en negativo o cero, ese CLI te está costando tiempo, no ahorrándotelo, por mucho que lidere Terminal-Bench. Este es el punto que un tutorial genérico no te da: un agente que acierta el 70% puede costarte más en revisión que hacer la tarea tú mismo.

¿Una suscripción o dos? La regla del 90%

La pregunta práctica de fondo suele ser si merece la pena pagar dos CLIs. Regla: si un solo candidato cubre el 90% de tu mini-eval con score positivo, una suscripción basta; paga la segunda solo si el 10% restante son tareas frecuentes y caras donde el otro agente claramente gana.

Los precios a junio 2026 ayudan a calibrar (verifica siempre la página oficial, cambian cada mes):

• Claude Code: va con suscripción de Anthropic, desde unos 20€/mes (Pro) hasta Max 5x (~100€) y Max 20x (~200€). Ojo al cambio del 15/06/2026: la automatización (Agent SDK, headless) pasó a un pool de créditos medidos a precio de API, separado del uso interactivo (detalle de pricing).
• Codex CLI: incluido en ChatGPT Plus (~20€/mes) con GPT-5.5 como modelo por defecto y GPT-5.4 como alternativa (modelos disponibles en Codex); las features cloud (review en GitHub, Slack) piden tier superior.
• Gemini CLI: el único con tier gratis usable (1.000 peticiones/día con modelos Flash), pero está siendo reemplazado por Antigravity CLI, con el tier individual de Gemini CLI cerrando el 18/06/2026 (comparativa con límites). Si dependes de él, planifica la migración.

Para afinar el lado del coste, el criterio de elegir por coste real y no por el benchmark y el de leer el benchmark antes de creértelo complementan este mini-eval: el eval te da el acierto en tu repo, esos te dan el marco de coste y lectura crítica del ranking.

Cuándo NO aplica este enfoque

El mini-eval no es gratis: construir 10-20 tareas con criterio verificable te lleva una tarde. No compensa si tu uso es esporádico (unas horas sueltas a la semana): ahí elige por tier gratis o por el que ya tengas y olvídate del ranking. Tampoco aplica si tu trabajo es muy exploratorio y poco repetitivo, porque un eval de tareas cerradas no captura "ayúdame a pensar esta arquitectura"; para eso, el criterio de razonamiento del agente pesa más que un test verde.

Y un matiz honesto: el mini-eval mide acierto en tareas que ya sabes verificar. No mide lo que un agente hace bien en lo que no anticipas, ni su comportamiento en sesiones largas, donde el harness y la gestión de contexto importan más que en tareas de un turno. Úsalo para decidir entre candidatos de cabecera, no como verdad absoluta.

Preguntas frecuentes

¿Cuántas tareas necesito en el mini-eval para que sea fiable?

Entre 10 y 20 tareas reales de tu repo es un umbral práctico (no una cifra estadística): suficiente para distinguir candidatos sin que montarlo se vuelva un proyecto. Por debajo de 10, el ruido de una tarea afortunada distorsiona; por encima de 20, el coste de mantenerlo supera el valor para una decisión de suscripción.

¿Por qué el modelo que gana en SWE-bench puede perder en mi repo?

Porque SWE-bench y Terminal-Bench miden tareas genéricas, no tu contexto. En un monorepo con contexto enorme, la gestión de contexto del harness y la latencia pesan más que el acierto medio publicado. Un modelo mejor en el ranking puede tardar más y respetar peor tus convenciones, que es donde se va el tiempo de revisión.

¿Vale la pena cambiar de CLI cada vez que sale un modelo nuevo?

No por defecto. Reutiliza tu mini-eval: cuando salga un modelo nuevo, córrelo contra tus 10-20 tareas. Si no mejora tu score actual de forma clara (no marginal), el coste de cambiar de flujo, atajos y configuración no compensa la mejora del leaderboard.

El takeaway

El ranking de turno caduca con la siguiente versión; tu mini-eval no, porque mide lo único que no cambia: tus tareas. La decisión práctica es invertir una tarde en 10-20 casos reales con criterio paso/no-paso, medir acierto, coste y latencia, y dejar que tu repo vote. Cuando el agente que lidera Terminal-Bench no gana en tu eval, ya sabes a quién creer.