Elegir modelo de IA por coste: evals que no mienten 2026

TL;DR: Para elegir tu modelo de IA por coste no necesitas un benchmark de marketing, necesitas una eval propia: una tarea pequeña y repetible que mida cómo se comporta el modelo en TU caso. El equipo de VS Code ejecutó la misma tarea trivial 50.974 veces sobre 30 modelos y encontró diferencias de hasta 70 veces en tokens de salida para un resultado idéntico. En este artículo verás qué es una eval, por qué el tamaño del modelo no predice el gasto y cómo montar una para decidir por coste y esfuerzo, no por hype.

El problema: eliges modelo por la tabla equivocada

La escena se repite cada vez que sale un modelo nuevo: lees el benchmark, ves que gana en SWE-bench o Terminal-Bench, y lo enchufas a tu agente. Tres semanas después llega la factura y no cuadra. El modelo "más listo" gastaba tres veces más tokens que el anterior para hacer lo mismo.

El benchmark mide si el modelo puede resolver la tarea. No mide cuánto le cuesta resolverla en tu flujo. Y con la facturación por uso que ya es estándar en herramientas como GitHub Copilot desde junio de 2026, cada token de salida es dinero y latencia. La pregunta operativa no es "¿cuál saca mejor nota?", sino "¿cuál me sale a cuenta para la tarea que hago de verdad?".

Esto conecta con algo que ya he tocado antes: los benchmarks de coding agéntico y por qué eliges mal tu modelo. El experimento de VS Code lo demuestra con datos a una escala que pocos equipos pueden igualar.

¿Qué es una eval?

Una eval es un test repetible que mide cómo se comporta un modelo en tu tarea concreta, no en un benchmark genérico. Le das al modelo la misma entrada fija, registras lo que hace (salida, pasos, herramientas usadas) y comparas entre modelos o entre versiones. Si la tarea no cambia, todo lo que cambie entre ejecuciones viene del modelo o del sistema que lo rodea.

La clave es la estabilidad. Una tarea simple con una respuesta correcta inequívoca se convierte en un instrumento sensible: reacciona a regresiones en tu harness, a cambios de versión del modelo y a diferencias de comportamiento, sin el ruido de un problema complejo que interpretar.

El experimento de las 50.000 ejecuciones

VS Code montó la eval más tonta posible, que llaman say_hello: una sola instrucción, "Add HELLO to HELLO.txt", con dos comprobaciones (que el archivo exista y contenga "HELLO"). Empezó como un simple smoke test antes de cada suite de benchmarks. En seis meses acumuló 50.974 ejecuciones sobre 30 modelos.

El resultado interesante no es que todos los modelos sepan escribir un archivo de cinco caracteres. Es cuánto trabajo gastan en hacerlo. Un desarrollador haría una sola llamada: crear el archivo. Los modelos, en cambio, se reparten en cuatro bandas muy distintas de tokens de salida para el MISMO resultado.

Banda	Tokens de salida (media)	Múltiplo del mínimo	Comportamiento típico
Eficiente	menos de 150	1-3×	Va directo a crear el archivo
Moderada	150-400	3-8×	Lee estado o explora un poco antes
Alto coste	400-1.000	8-12×	Planifica y explora siempre
Extrema	1.441-3.676	29-74×	Narra su razonamiento sin parar

El mínimo realista para esta tarea es unos 50 tokens. La diferencia entre el modelo más austero y el más pesado es de aproximadamente 70 veces para una salida idéntica. Eso, multiplicado por miles de peticiones al mes, es la diferencia entre 10€ y 50€ de factura por exactamente el mismo trabajo.

El hallazgo que rompe la intuición: el tamaño no predice el gasto

La primera hipótesis era que los modelos grandes razonan más y por tanto gastan más. Los datos dicen lo contrario. En el estudio, dentro de una misma familia:

El modelo grande usaba 160 tokens y 2,1 llamadas de herramienta de media. El más disciplinado de su familia.
Su hermano pequeño usaba 485 tokens y 3,7 llamadas. Más overhead que el grande.
El modelo más derrochador de todos era un "mini": 3.676 tokens de media para escribir cinco caracteres.

La conclusión es que lo que predice el coste no es el número de parámetros, sino la calibración del esfuerzo: si el modelo sabe distinguir una tarea de un paso de una de treinta pasos. Las generaciones más nuevas, dentro de cada familia, tienden a ser más disciplinadas. Es madurez de entrenamiento, no tamaño. Y esa calibración aparece directamente en la factura.

Dónde se va el esfuerzo (y por qué te cuesta dinero)

Como la eval captura la secuencia completa de llamadas, se ven los patrones de derroche. Estos son los que repiten los modelos sobre una tarea de un solo paso:

Planificar antes de actuar (52-99% de las veces): dibuja un checklist antes de crear un archivo de cinco caracteres.
Explorar un workspace vacío (56-96%): lista directorios o busca archivos en una carpeta que está vacía. Como buscar pistas en una habitación vacía.
Narrar el razonamiento (1.441-3.676 tokens): emite mucho más texto del que cualquier llamada necesita, reconfirmando la tarea una y otra vez.
Usar la herramienta equivocada: un patch/edit complejo en vez de una creación simple. Como usar una fresadora CNC para cortar un folio.

Ninguno de estos es un fallo de corrección: todos pasan la eval. Pero todos cuestan tokens, latencia y presupuesto. En tareas largas, planificar y explorar previene errores caros y vale la pena. En una de un paso, es puro desperdicio.

Implementación: monta tu propia eval mínima

No necesitas una suite privada de benchmarks. Empieza con la tarea más pequeña que tenga una respuesta correcta inequívoca, ejecútala muchas veces y registra bien. Aquí va un esqueleto funcional en Python que vale para cualquier modelo con API.

Primero, define la tarea y la métrica. Lo importante: guarda la secuencia de herramientas, no solo el contador.

# Define una eval: entrada fija, verificacion clara y traza de comportamiento
from dataclasses import dataclass, field

@dataclass
class EvalResult:
    passed: bool
    output_tokens: int
    tool_sequence: list = field(default_factory=list)  # ["plan", "create_file"] no solo "2"

def check(workspace: dict) -> bool:
    # La asercion inequivoca: el archivo existe y contiene lo esperado
    return workspace.get("HELLO.txt") == "HELLO"

Segundo, ejecuta la tarea N veces contra un modelo y acumula resultados. Aquí run_agent es tu llamada real al modelo (la que ya tengas montada con tu SDK), que devuelve el workspace, los tokens de salida y la secuencia de tools.

# Ejecuta la misma tarea N veces para que las diferencias vengan del modelo, no del azar
def run_eval(model: str, n: int = 50) -> list:
    results = []
    for _ in range(n):
        workspace, out_tokens, tools = run_agent(model, prompt="Add HELLO to HELLO.txt")
        results.append(EvalResult(check(workspace), out_tokens, tools))
    return results

Tercero, y esto es lo que de verdad importa: traduce los tokens a coste por respuesta correcta. Un modelo que acierta a la primera con pocos tokens puede salir más barato que uno "barato" que necesita tres reintentos.

# Coste por acierto = lo unico que importa al elegir modelo en produccion
def cost_per_correct(results: list, price_per_1k_eur: float) -> float:
    correct = [r for r in results if r.passed]
    if not correct:
        return float("inf")
    total_tokens = sum(r.output_tokens for r in correct)
    return (total_tokens / 1000) * price_per_1k_eur / len(correct)

# Ejecucion minima: compara dos modelos sobre la misma tarea
for model, price in [("modelo-grande", 0.012), ("modelo-mini", 0.004)]:
    res = run_eval(model, n=50)
    print(f"{model}: {cost_per_correct(res, price):.5f} EUR/acierto")

El truco del cost_per_correct es que un modelo con precio por token más alto pero que va directo puede ganarle a uno barato que narra 3.000 tokens. La factura no la decide el precio por token, la decide el comportamiento.

Aplicación práctica: ¿cuándo usar esto?

Esta tabla resume cuándo una eval pequeña te da criterio real y cuándo te engaña:

Úsala para	Evítala (o complétala) para
Detectar regresiones del harness o del proveedor	Concluir que un modelo es "mejor" en general
Comparar coste/esfuerzo de modelos en tu tarea típica	Tareas largas multi-paso (mide eso aparte)
Preflight antes de cambiar de versión de modelo	Optimizar tu producto sobre una sola tarea
Decidir el modelo por defecto de un agente	Sustituir la evaluación en producción real

Un patrón que funciona bien: separar planificación y ejecución. Usar un modelo con buen razonamiento para planificar y luego cambiar a uno más austero y rápido para implementar. Lo he descrito en detalle al hablar de planificar con un modelo y ejecutar con otro en Claude Code, y encaja exactamente con lo que dicen estos datos: no pongas el modelo que sobrepiensa a escribir un "HELLO".

En Producción

Llevar una eval del cuaderno al día a día cambia varias cosas. Estas son las que importan:

Registra la secuencia, no el conteo. Saber que hubo 4 llamadas es incompleto. Saber que el modelo planificó, listó el directorio, buscó y luego creó el archivo te dice de dónde vino el coste. Loguea tool_sequence y output_tokens, no solo pass: true.
Coste real en euros. Para un desarrollador con tráfico modesto, la diferencia entre la banda eficiente y la extrema es pasar de unos 10€/mes a 40-50€/mes en APIs por exactamente el mismo trabajo. Multiplica tokens por tu precio y decide con el número delante.
Vigila el cache y los cambios a media sesión. Reanudar una sesión tras una pausa larga con la caché expirada, o cambiar el nivel de esfuerzo a mitad de tarea, dispara el coste sin avisar. Esto enlaza con cómo cruzar los 200k tokens te vacía el presupuesto: el harness importa tanto como el modelo.
No optimices sobre una sola tarea. say_hello es un termómetro, no el mapa entero. Para decidir el modelo de un agente real, corre un set diverso de tareas. La eval pequeña es la señal de alarma, no la decisión final.
El esfuerzo es ajustable. Muchos modelos de 2026 traen un dial de reasoning effort. Si ves que un modelo sobrepiensa tareas simples, baja el effort por defecto y reserva el alto para planificación o debugging de varios pasos.

Errores comunes y depuración

Error: tu eval da resultados distintos cada vez sin tocar nada. → Causa: la tarea es ambigua o el workspace no parte del mismo estado. → Solución: fija el estado inicial y elige una aserción binaria. Si la tarea tiene varias respuestas válidas, no es una eval estable.

Error: dos modelos "empatan" en pass rate pero uno cuesta el triple. → Causa: solo mides si pasa, no cómo. → Solución: añade output_tokens y tool_sequence a cada resultado y compara coste por acierto, no acierto pelado.

Error: el modelo pequeño que elegiste "para ahorrar" gasta más que el grande. → Causa: asumiste que tamaño igual a coste. → Solución: mídelo. La calibración del esfuerzo no se ve en la ficha técnica, solo en las trazas.

Preguntas frecuentes

¿Una eval de cinco líneas sirve de algo de verdad?

Sí, como termómetro. Una tarea trivial y estable, ejecutada con consistencia y bien registrada, detecta regresiones del harness, incidentes de infraestructura y cambios de comportamiento del modelo. No reemplaza la evaluación en producción, pero es la alarma más barata que puedes montar.

¿Por qué un modelo más pequeño puede costar más que uno grande?

Porque el coste lo manda el comportamiento, no el tamaño. Un modelo poco calibrado planifica, explora y narra incluso en tareas de un paso, gastando miles de tokens de salida. Uno mejor entrenado reconoce que la tarea es simple y va directo, aunque tenga más parámetros.

¿Esto solo aplica a agentes de coding?

No. Cualquier sistema con LLM (RAG, clasificación, extracción) se beneficia de una eval mínima con respuesta inequívoca para vigilar coste y comportamiento. El principio es el mismo: mide tu tarea, no el benchmark de otro.

La lección que se queda

Hemos visto que elegir modelo por el benchmark de marketing es elegir por la métrica equivocada. Lo que separa una factura controlada de una sorpresa a fin de mes no es qué modelo saca mejor nota, sino cuál calibra el esfuerzo a la tarea que tú haces de verdad. Y eso solo se ve montando una eval propia, pequeña y estable, que registre la secuencia de pasos y traduzca tokens a euros. La selección de modelo no es un "elige el más listo y ya": es una decisión continua de coste y fiabilidad. Si quieres ir un paso más allá de la eval offline, vale la pena leer por qué tu evaluación offline miente y conviene medir en producción.

¿Has montado evals propias para decidir tu modelo, o sigues tirando del benchmark del día? Cuéntamelo en los comentarios o en Twitter @sergiomarquezp_. En el próximo post quiero entrar en cómo automatizar el routing de modelos para que esa decisión deje de ser manual.