Resumen de la publicación
Satya Nadella salió a decir en dos apariciones distintas de la misma semana que la empresa que no controla su capa de modelos «esencialmente tercerizó su pensamiento», y que el harness tiene que mantenerse separado del modelo para que cualquier modelo sea intercambiable. En paralelo, Microsoft presentó su propia familia de modelos y Anthropic lanzó Opus 5 igualando a Fable 5 a la mitad del precio por tarea.
Lo que me interesa de esto no es la disputa comercial entre proveedores, sino una consecuencia práctica para cualquiera que esté construyendo con LLMs: el costo de estar atado a un solo modelo dejó de ser hipotético y se puede calcular. Y en la mayoría de las arquitecturas que veo, ese costo está escondido en lugares donde nadie lo mide.
La semana del 27 de julio Satya Nadella dijo dos veces lo mismo en contextos distintos, y creo que vale la pena tomárselo en serio aunque venga con un interés comercial evidente detrás.
El domingo, en el programa de Fareed Zakaria, lo puso así: «cualquier empresa que no tenga este control, voy a afirmar que no seguirá siendo una empresa, porque esencialmente tercerizó su pensamiento».
El miércoles, frente a analistas de Wall Street, lo repitió en versión técnica: hay que mantener el harness separado del modelo, y eso significa que cualquier modelo, en cualquier momento, sea intercambiable.
Sí, obviamente le conviene decirlo
Empecemos por lo evidente, así nos lo sacamos de encima.
Microsoft invirtió en OpenAI y en Anthropic, y esa misma semana presentó su propia familia de modelos MAI, su primer modelo de razonamiento, su chip Maia 200 y un modelo especializado en ciberseguridad.
Cuando el que vende la capa de abstracción te dice que la capa de abstracción es imprescindible, corresponde levantar una ceja.
Ahora bien: que el mensajero tenga interés no vuelve falso el mensaje. Y en este caso puntual, los números de las últimas semanas lo respaldan bastante mejor que cualquier argumento de arquitectura.
El argumento que sí me convence: el precio se movió solo
Miremos lo que pasó con Opus 5, lanzado el 24 de julio.
El precio por token no cambió respecto de Opus 4.8: sigue en 5 dólares por millón de tokens de entrada y 25 por millón de salida. Sin embargo, en benchmarks agénticos iguala o supera a Fable 5, que cuesta 10 y 50.
O sea que el mismo trabajo pasó a costar la mitad, sin que se moviera la lista de precios. Lo que se movió fue la eficiencia de tokens.
Este es el punto que más me cuesta transmitir en las charlas: el precio por token no es el precio. El precio es el costo por tarea completada, y ese número depende de cuántos tokens necesita el modelo para llegar al resultado.
Hay un dato que lo ilustra al revés: Opus 4.7 terminó costando entre un 30% y un 40% más por tarea que Opus 4.6, con exactamente la misma tarifa base.
Si tu arquitectura tiene el modelo cableado en el código, cada uno de estos movimientos te pasa por al lado. No podés capturarlos.
Dónde está escondida la deuda
Cuando hablo de estar atado a un modelo, casi nadie cree estarlo. «Cambiamos el string del modelo y listo», es la respuesta habitual.
En la práctica, en los proyectos que vengo mirando, el acoplamiento está en otros lados:
- Los prompts. Están afinados contra el comportamiento de un modelo específico. Cambiás de proveedor y la calidad se cae, no porque el otro modelo sea peor sino porque el prompt está sobreajustado.
- El formato de tool calling. Cada proveedor tiene el suyo, y la lógica de parseo suele estar desparramada por el código en vez de vivir detrás de una interfaz.
- La memoria y el contexto. Si la estrategia de contexto asume una ventana y un comportamiento de caché particulares, mudarse implica rediseñar, no reconfigurar.
- Las evaluaciones. Este es el más caro y el que menos se ve. Si no tenés un set de evaluación propio, no tenés forma de saber si el modelo nuevo es mejor o peor para tu caso. Y sin eso, cambiar es un salto al vacío que ningún responsable va a aprobar.
La cuarta es la que convierte lo que parecía una decisión técnica reversible en una decisión estratégica difícil de deshacer.
El costo que aparece cuando escalás
Ya escribí sobre el costo oculto de los tokens en agentes de IA y el tema no hizo más que agravarse.
Circuló hace poco el relato de un equipo que migró a una arquitectura multiagente y se encontró con la factura de tokens multiplicada por tres sin haberlo decidido.
El patrón se repite bastante: cada agente que agregás rearma su propio contexto, y el costo crece de forma que nadie modeló al principio.
Lo que quiero subrayar es la conexión entre las dos cosas. Si tenés observabilidad a nivel de token y una capa que te deja rutear por modelo, ese descubrimiento se transforma en una decisión de ingeniería: mando las tareas simples a un modelo barato y reservo el caro para lo que lo justifica.
Si no la tenés, es simplemente una factura más alta que aparece a fin de mes y sobre la que no podés hacer nada en el corto plazo.
Qué implica esto en un contexto argentino
Acá hay un factor que en las discusiones de Silicon Valley no aparece y que para nosotros pesa mucho.
Cuando el presupuesto de infraestructura está en dólares y los ingresos no, la diferencia entre pagar 5 y pagar 10 por millón de tokens no es una optimización elegante: puede ser la diferencia entre que un proyecto exista o no.
Y no es solo el precio. La disponibilidad regional, los límites de tasa, la latencia desde acá y hasta las restricciones de acceso que puedan aparecer son variables que un equipo local no controla.
Ya vimos este año lo que pasa cuando el acceso a un modelo depende de decisiones ajenas. Diseñar asumiendo que el proveedor va a estar siempre disponible en las mismas condiciones es, hoy, una apuesta.
Lo que sí haría, en orden
No estoy proponiendo que armes una abstracción gigante que soporte todos los proveedores del mercado. Eso es sobreingeniería y termina siendo peor que el problema que resuelve.
Lo que sí haría, en este orden:
- Armar el set de evaluación propio antes que cualquier otra cosa. Veinte o treinta casos reales de tu dominio, con criterio de éxito definido. Sin esto, todo lo demás es opinión.
- Medir costo por tarea, no por token. Es la única métrica que permite comparar modelos de manera honesta.
- Sacar el modelo del código de negocio. Una interfaz fina, con el proveedor detrás. No hace falta más que eso.
- Guardar los prompts y las respuestas. Es tu insumo para evaluar alternativas y, como señala Nadella, es lo único que queda del lado tuyo en toda esta ecuación.
- Probar un modelo alternativo cada tanto, aunque no pienses migrar. El ejercicio te dice cuánto te costaría hacerlo si tuvieras que hacerlo con urgencia.
El punto tres es más barato de lo que parece si se hace al principio, y carísimo si se deja para cuando ya hay treinta llamadas al SDK repartidas por todo el sistema.
El MCP resuelve una parte, no todo el harness
El 28 de julio se publicó la especificación 2026-07-28 del Model Context Protocol, la revisión más grande del protocolo desde su lanzamiento.
El cambio de fondo es que el núcleo pasó de stateful a stateless. Se eliminaron el intercambio initialize/initialized y el header Mcp-Session-Id, junto con la sesión a nivel de protocolo que venía con ellos.
Ahora cada request lleva su propia versión, identidad y capacidades. En la práctica eso significa que cualquier instancia del servidor puede atender cualquier request, y que un balanceador común alcanza: se terminaron la afinidad de sesión y el store compartido que antes hacían falta para escalar horizontalmente.
Conviene ser preciso con el alcance, porque acá es fácil pasarse de rosca. El estado no desapareció: lo que desapareció es el estado obligatorio a nivel de protocolo y transporte. Tu aplicación puede seguir manejando estado, pero tiene que hacerlo de forma explícita (devolviendo un identificador que después se manda en otra llamada) en vez de esconderlo en la sesión del protocolo.
La misma versión trae varias piezas más que apuntan al mismo lugar:
- Requests multi round-trip: una herramienta puede pedir confirmación o datos adicionales sin mantener una conexión abierta.
- Ruteo por headers
Mcp-MethodyMcp-Name, para que el balanceador decida sin mirar el cuerpo del mensaje. - Catálogos de herramientas y recursos cacheables, con
ttlMsycacheScope. - Un framework formal de extensiones y mejoras de autorización alineadas con OAuth y OIDC.
- Una política de ciclo de vida de funcionalidades con un mínimo de 12 meses entre que algo se deprecia y el momento más temprano en que puede removerse.
Esa última es la que más me importa para el tema de esta nota. Un compromiso escrito de 12 meses es lo que permite apoyar una arquitectura sobre el protocolo sin quedar rehén de la próxima versión.
Ahora bien, y esto es importante: el MCP estandariza la interfaz con las herramientas, no todo el harness.
Que tus servidores MCP sean replicables y balanceables no elimina las diferencias entre modelos en tool calling, en cómo responden a los prompts o en su comportamiento de razonamiento. Esas siguen ahí y siguen siendo el grueso del trabajo de migrar.
Va en la dirección que menciona Nadella cuando habla de separar el harness del modelo, y desacopla una pieza real. Pero es una pieza, no la solución completa.
Elegí un modelo, no te cases con él
Que quede claro: no estoy diciendo que no elijas. Elegir un modelo y aprovechar bien sus particularidades es lo correcto, y andar cambiando cada dos meses por moda es una forma cara de no avanzar.
Lo que digo es que la elección tiene que ser reversible, y que hoy hay demasiados equipos que no saben cuánto les costaría revertirla porque nunca lo midieron.
Esa distancia entre «elegimos» y «quedamos atados» es la deuda técnica de la que hablo, y a diferencia de otras, esta se puede cuantificar en una tarde.
¿Vos sabés cuánto tardarías en cambiar de modelo si mañana tuvieras que hacerlo? Contame en los comentarios, tengo curiosidad por saber qué tan atados estamos en la región.
