El modelo de IA más barato ganó el benchmark

Cuando tienes veinte modelos de IA para programar delante, el atajo mental es elegir el más caro. La intuición dice que cuesta más porque es mejor, y con esa regla no te equivocas lo bastante como para notarlo. Nosotros la usábamos hasta que dejamos de fiarnos.

Montamos un benchmark. La misma tarea para los veinte, en autopiloto, cada uno aislado en una carpeta vacía y con su variante de razonamiento más alta. El resultado incómodo: el modelo que mejor nota sacó costó tres céntimos, y hay modelos que costaron veinte veces más y quedaron por debajo.

Cómo se mide algo así

Con tres tareas de dificultad creciente. En todas hay que construir un motor desde cero en TypeScript, sin librerías externas:

El enunciado es el mismo para todos y vive fuera de sus carpetas, para que nadie lo lea como contexto extra. La nota de 0 a 10 no es la impresión de un humano: combina una suite de tests oculta que el modelo no conoce, la valoración de un juez sobre el código y los tests, la autonomía (cuántas veces hubo que intervenir) y la robustez. El juez es Claude Sonnet, un modelo que no compite, y trabaja sobre una copia fuera del repo. La suite oculta no se publica justo para que siga sirviendo en tiradas futuras.

El barato ganó, y no es un accidente

En RRULE, la tarea de dificultad media, terminaron los veinte. Estos son los que quedaron arriba:

Tres modelos empataron a 9,8. El de tres céntimos y el de cincuenta y ocho obtuvieron la misma nota; la diferencia de precio era de veinte veces y la de tiempo, de casi cinco. En SQL, la tarea difícil, DeepSeek V4.1 Flash volvió a quedar primero con 173 casos de 173 y $0,08. GPT-5.6 Luna repitió segundo en las dos.

La conclusión no es "lo barato es mejor". Es que el precio no mide lo que crees que mide. Cuando pagas más por un modelo pagas tokens, caudal, latencia, disponibilidad o marca, no corrección sobre una tarea acotada. En un problema bien especificado, un modelo barato con la variante de razonamiento al máximo puede aguantar el tipo perfectamente.

La dificultad no reparte: se lleva por delante a la mitad

El dato más útil del benchmark no es quién gana, es cuántos terminan:

• RRULE: 20 de 20.
• SQL: 4 de 19.
• Regex: 2 de 20.

Con la tarea fácil, la tabla no discrimina: casi todos aprueban y las diferencias son de matiz. Con la difícil, el pelotón se rompe y aparecen los que de verdad sostienen el problema. Un benchmark con una sola tarea amable sirve para ordenar modelos por nota, no para saber cuál aguanta cuando la cosa se pone fea.

Y hay una decisión de honestidad en cómo se puntúa al que no termina. Dos modelos se detuvieron a mano por tardar o gastar demasiado: uno llevaba el código completo y compilando pero sin tests ni README, otro iba por el 95 %. Se les valora lo que habían hecho y se les pone autonomía cero, porque un modelo que no termina en un tiempo usable no es un modelo usable aunque su código a medias sea bueno.

Lo que la tabla no dice

La variante de razonamiento más alta no garantiza nada. Un modelo se pasó la sesión pensando y se cortó sin escribir casi nada. El problema no era el modelo: era el arnés. opencode limita cada respuesta a 32.000 tokens de salida, razonamiento incluido, así que subimos ese tope para que el pensamiento no se cortara a medias. Es un recordatorio de que en un benchmark mides también la herramienta con la que mides.

El aislamiento se mide, no se asume. Cada modelo corre con el acceso fuera de su carpeta denegado, y el resultado registra si lo intentó. Uno lo intentó y se quedó bloqueado. Otro llegó a leer rutas donde estaban los resultados de otros, así que su fila va marcada como contaminada y no cuenta igual que las demás. Sin esa columna estarías comparando soluciones que vieron las respuestas, y no te enterarías.

El juez tiene nervio. Es un LLM puntuando a otros, con una variabilidad de medio punto arriba o abajo. No es una medida de laboratorio y no lo disfrazamos de una: cuando vuelve a ejecutarse, reutiliza el veredicto guardado y solo re-pasa la suite oculta.

La frontera de eficiencia

La tabla que de verdad usamos no es "quién saca más nota", es nota frente a coste, y también frente a tokens, pasos y tiempo. En la versión interactiva del benchmark los pesos de la nota son ajustables, porque no es lo mismo priorizar corrección que autonomía o robustez. El gráfico dibuja una frontera: por encima de ella ningún modelo la mejora sin gastar más.

Para un estudio pequeño, la pregunta nunca fue "cuál es el mejor modelo", sino "cuál rinde más por euro en este tipo de tarea". Un 9,8 a tres céntimos gana a un 9,8 a cincuenta y ocho, y los dos ganan a un 6,3 con ochenta y cuatro céntimos que encima no terminó.

Lo que nos llevamos

• El precio no es un proxy de la calidad. Mide tokens, velocidad y disponibilidad. Para elegir modelo hay que medir lo otro, y medirlo no es caro.
• Lo que discrimina es la dificultad de la tarea. Con una prueba fácil todos aprueban; la información está en la que rompe al pelotón.
• La variante de razonamiento más alta no es una garantía, y a veces el cuello de botella es tu propio arnés.
• Hay que medir el aislamiento. Un benchmark sin control de contaminación compara soluciones que no crees que está comparando.

Si estás eligiendo modelo de IA para tu equipo y no sabes por dónde empezar, escríbeme. El benchmark es público en github.com/rldona/opencode-models-benchmarks, con una web interactiva para cambiar los pesos de la nota y ver la frontera de eficiencia.