Fijar un modelo de IA en el código ya es deuda técnica

Los equipos que mueven más de mil millones de tokens al mes por el AI Gateway de Vercel usaron en promedio 42 modelos distintos en septiembre de 2026, y casi la mitad de todos los equipos cambió su modelo más usado ese mes. Ese es el número que merece reacción — no el titular de que los modelos open-weight se quedaron con el 71,5% de los tokens y el 23% del gasto. Elegir modelo dejó de ser una decisión de arquitectura y pasó a ser de runtime, lo que significa que un id de modelo fijo en el código de tu producto ya es deuda técnica.

Qué dice realmente el dato de producción

No son resultados de benchmark. Son cifras agregadas y anonimizadas de tráfico que corrió de verdad, publicadas en el índice de producción del AI Gateway de Vercel correspondiente a septiembre de 2026.

La cobertura de The New Stack enmarca la otra mitad del mismo hecho: open weight se lleva el volumen, mientras Anthropic sola sigue llevándose el 64% del dinero.

"Open weight" no es una sola cosa

El agregado esconde una dispersión lo bastante grande como para invalidar la categoría. Dentro de ese mismo 71,5%:

• DeepSeek: 58% de los tokens por 6,6% del gasto.
• Z.ai (GLM): 7,2% de los tokens por 4,5% del gasto.
• Moonshot (Kimi): 3,6% de los tokens por 13,2% del gasto — la razón se invierte por completo.

Es decir, un modelo open-weight cuesta cerca de un orden de magnitud más por token que otro. "Migramos a open weight para recortar costos" no es una estrategia; es una frase que puede ser verdadera o falsa según qué modelo open-weight elegiste y para qué tarea. La diferencia entre modelos abiertos hoy es mayor que el abismo que la gente imagina entre abierto y cerrado.

Tokens más baratos produjeron cuentas más grandes

Los dos números más contraintuitivos del índice están uno al lado del otro: el precio medio por token cayó 47% y el gasto en el gateway creció 13x en la misma ventana.

Es la paradoja de Jevons llegando a la inferencia. La caída del costo unitario no redujo la línea del presupuesto — quitó la restricción que contenía el uso. Cada funcionalidad que era demasiado cara para existir a los precios del año pasado se volvió viable, y los equipos la entregaron.

La consecuencia de planificación es concreta: no presupuestes inferencia como un costo que baja. El precio del modelo cae y tu cuenta crece, porque lo que gobierna lo que construyes es capacidad por dólar. Un founder que proyecta gasto de IA estable porque los precios bajan está proyectando la variable equivocada.

El acoplamiento que va a doler

Junta los dos hallazgos — la mitad de los equipos cambia de modelo principal cada mes, y la dispersión de costo dentro de una categoría es de 10x — y la conclusión arquitectónica se escribe sola. Cualquier cosa que encarezca cambiar de modelo pasó a ser lo caro.

Cómo se ve eso en el código, por lo que vemos llevando software hecho con IA a producción:

1. Ids de modelo inline en el punto de llamada. Un literal repartido en doce archivos es una migración, no un cambio de config. Un lugar, un nombre, inyectado.
2. Prompts escritos para las mañas de un modelo. Trucos de formato afinados a una familia específica dejan de funcionar en silencio con la siguiente. Mantén el prompt especificado por comportamiento y pruébalo contra al menos dos modelos.
3. Sin mapa tarea→modelo. Clasificación, extracción, resumen masivo y razonamiento difícil tienen perfiles de costo que difieren 10x o más. Enrutar por clase de tarea es donde está el ahorro real — no en elegir un default más barato para todo.
4. Sin suite de evals. Sin ella, cambiar de modelo es un acto de fe, así que el equipo no cambia, así que paga de más en las tareas que nunca necesitaron el modelo caro. La suite de evals es lo que convierte una baja de precio en un recorte de presupuesto.
5. SDK del proveedor repartido por la capa de dominio. El patrón de gateway existe por algo: un adaptador, un lugar para el fallback, un lugar para ver el gasto.

Nada de esto es exótico. Es la disciplina normal para cualquier dependencia que cambia más rápido que tu ciclo de release — y ahora mismo esa dependencia cambia cada mes.

Qué construiríamos primero

Si ya hay una funcionalidad de IA en producción y nada de esto está en su lugar, el orden que seguiríamos: extraer el id del modelo a configuración, escribir evals para las tres tareas de mayor volumen y enrutar esas tres por clase de tarea. Esa secuencia captura la mayor parte del beneficio de costo antes de cualquier reescritura, y convierte el próximo cambio de modelo en un cambio de configuración en vez de un proyecto.

Es esa la capa sin glamour entre una funcionalidad que hace demo y un sistema cuya economía sobrevive un año — el trabajo que hacemos con software hecho con IA que va a producción. Y rima con algo que ya escribimos: la generación se volvió abundante, el juicio se volvió escaso. El enrutamiento de modelos es juicio, codificado.

Conclusiones clave

• Los equipos sobre 1B de tokens usaron 42 modelos en promedio en septiembre de 2026, y cerca de la mitad de todos los equipos cambió su modelo más usado ese mes. La elección de modelo es ahora una decisión de runtime.
• Los modelos open-weight se quedaron con el 71,5% de los tokens pero solo el 23% del gasto; Anthropic sola siguió llevándose el 64% del dinero.
• "Open weight" no es un solo precio: DeepSeek corrió 58% de los tokens por 6,6% del gasto, mientras Moonshot corrió 3,6% de los tokens por 13,2%.
• El precio por token cayó 47% mientras el gasto total creció 13x — la inferencia más barata expande el uso en vez de encoger el presupuesto.
• El acoplamiento caro es todo lo que dificulta el cambio: ids de modelo inline, prompts atados a un modelo, ausencia de evals, ausencia de enrutamiento por tarea.

Preguntas frecuentes

¿Deberíamos migrar a modelos open-weight para recortar costos?

Solo con un mapa tarea→modelo y evals. Open weight se quedó con el 71,5% de los tokens por el 23% del gasto en agregado, pero dentro de esa categoría un modelo corrió 58% de los tokens por 6,6% del gasto mientras otro corrió 3,6% por 13,2%. La categoría no dice nada; lo que determina el costo es el par tarea-modelo.

¿Por qué creció el gasto si el precio bajó?

Porque el precio era la restricción del uso. El precio medio por token cayó 47% entre diciembre de 2026 y septiembre de 2026 mientras el gasto en el gateway creció 13x. La inferencia más barata vuelve viable lo que antes no cerraba, y los equipos lo entregan.

¿Con qué frecuencia cambian de modelo los equipos?

En septiembre de 2026, casi la mitad cambió su modelo más usado y uno de cada tres cambió de laboratorio entero — récord del índice. Esa es la tasa que tu arquitectura tiene que absorber.

¿Qué es lo primero que hay que corregir en un código existente?

Sacar el id del modelo de los puntos de llamada y llevarlo a configuración. Es un cambio pequeño que convierte cada cambio futuro de migración de código en un deploy, y cuesta casi nada hacerlo ahora.

¿Necesitamos un producto de gateway para esto?

Un producto no necesariamente — pero el patrón sí: un adaptador entre tu código de dominio y cualquier SDK de proveedor, para que el enrutamiento, el fallback y la visibilidad del gasto tengan dónde vivir.

Fuentes: Índice de producción del AI Gateway de Vercel, octubre de 2026 · The New Stack