En Tech86 ya vimos empresas quemando seis dígitos por mes en modelos premium para tareas que un modelo 21 veces más barato resuelve igual. El problema no es el modelo, es la ausencia de criterio económico en la selección. La selección de modelos es unit economics, no fanboyismo.
Los números que el mercado ignora
SWE-bench es el benchmark de referencia para capacidad de código. Y los números recientes son reveladores. MiniMax M2.5 entrega 80,2% por US$ 1,20 por millón de tokens de salida. Claude Opus 4.6 entrega 80,8% por US$ 25 por millón. La diferencia de performance es 0,6%. La diferencia de precio es 21x.
En la entrada, el gap es igualmente brutal: US$ 0,15/M en MiniMax contra US$ 5/M en Opus. MiniMax todavía ofrece ventana de contexto de 1M de tokens contra 200K de Opus. Y es código abierto.
Estos números no son teóricos. Son los precios publicados, los benchmarks ejecutados, las especificaciones declaradas. Cuando los ponemos en Excel, la conclusión es inevitable: para la mayoría de los workloads de código, pagar premium es capital mal asignado.
Lo que el benchmark no le cuenta
SWE-bench mide una cosa: capacidad de resolver issues de repositorios de código abierto. Es útil como referencia, pero no representa lo que sucede en producción. Lo que MiniMax no le cuenta: ¿cuántos tokens de reasoning quema por tarea? ¿Cuál es la latencia real en código complejo? ¿El modelo logra mantener contexto de 1M de tokens sin degradación? ¿La calidad del código generado es comparable o es "sintaxis correcta, lógica rota"?
En nuestra experiencia, los benchmarks son el punto de partida, nunca el veredicto. Ya vimos modelos con SWE-bench alto que generan código sintácticamente correcto pero lógicamente roto. Y vimos modelos con benchmark menor que entregan código más robusto porque fueron entrenados con datasets más alineados con el dominio del cliente.
SWE-bench no mide la robustez del código, los edge cases tratados, la arquitectura de la solución ni la legibilidad y mantenibilidad. Esas son las métricas que importan en producción. Y solo se pueden evaluar probando en su workload real.
El desperdicio silencioso: Opus para CRUD
Si usted está corriendo Opus 4.6 para generar código común, CRUDs, APIs simples, scripts de automatización, extracción de datos, está pagando premium por algo que un modelo 21 veces más barato hace igual o mejor. Esa es la realidad que nadie quiere admitir.
Ya auditamos operaciones de IA donde, en nuestra experiencia, el 80% de las solicitudes eran tareas comunes corriendo en modelos premium. El costo mensual era 5 veces mayor de lo que necesitaba ser. Y la calidad no mejoraba, porque para CRUD y boilerplate, cualquier modelo con 75%+ en SWE-bench entrega el mismo resultado.
Ahora, si usted necesita reasoning profundo sobre arquitectura, context window masivo para monorepos, agentic behavior con tool calling complejo, o safety y alignment de nivel enterprise, Opus todavía puede justificar el costo. La cuestión es: ¿cuántas de sus solicitudes realmente necesitan eso?
El costo real por tarea (y por qué nadie lo calcula)
El precio por millón de tokens es solo la superficie. El costo real de una tarea incluye tokens de entrada, tokens de salida y tokens de reasoning. Un modelo que cuesta 21 veces menos por token pero quema 3 veces más tokens de reasoning puede no ser tan barato como parece.
En la práctica descubrimos que el cálculo es más sutil. Los modelos premium tienden a ser más eficientes en reasoning: llegan a la respuesta con menos tokens intermedios. Los modelos más baratos pueden compensar el precio menor con más tokens de razonamiento. El costo por tarea completa es lo que importa, no el precio por token.
Nuestro proceso: ejecutamos el mismo workload en múltiples modelos, medimos los tokens totales consumidos (input + reasoning + output), multiplicamos por el precio y comparamos el costo por tarea. En 7 de cada 10 casos de uso de código, el modelo más barato gana incluso considerando el overhead de reasoning.
Model routing: la arquitectura que separa al aficionado del profesional
El model routing es la práctica de dirigir cada solicitud hacia el modelo más adecuado según la complejidad de la tarea. Las tareas simples van hacia modelos de alto throughput y bajo costo. Las tareas complejas van hacia modelos premium. Es la misma lógica de usar un sedán para el trayecto diario y un camión para una mudanza.
En Tech86 implementamos model routing basado en clasificación de complejidad. El sistema analiza el prompt, clasifica la tarea entre común y compleja, y la dirige hacia el modelo correcto. El resultado: reducción de 60-70% en el costo de inferencia en nuestra operación, sin pérdida de calidad en los outputs finales.
El mercado está reclasificando lo que es un "modelo de punta". Ya no lo define quien tiene el benchmark más alto. Lo define quien entrega más throughput por dólar. Y el model routing es la herramienta que convierte esa reclasificación en ahorro real.
FinOps para IA no es opcional
Si su caso de uso corre con el 80% de lo que el modelo ofrece, pagar 21 veces más es desperdicio de capital. Punto. No existe argumento de "brand" o "confianza" que justifique quemar presupuesto de infraestructura en modelos oversized.
FinOps para IA es el proceso de garantizar que cada dólar gastado en inferencia genere valor proporcional. Esto significa mapear casos de uso, medir el costo por tarea, implementar model routing y revisar continuamente. El mercado de LLMs cambia cada semana: el modelo que era premium el mes pasado puede ser común hoy.
En Tech86 diseñamos arquitecturas de IA con model routing basado en complejidad y costo real. Si usted está corriendo el modelo más caro porque "siempre fue así", es hora de recalcular. La consultoría FinOps para IA no es un costo, es ROI.