Jev decide, tus LLM responden

TypeSafe lanzó su primer modelo el 15 de septiembre, y lo interesante de Jev es lo que se niega a hacer. No te escribe un párrafo. Le das una petición y te devuelve un valor estructurado — una etiqueta, una clase, una decisión — en, según ellos, 70 a 500 ms. La frase más clara del post es de su fundador, Diogo Almeida: "Think of Jev as a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out."

La mayoría de los modelos están hechos para hablar con personas. Jev está hecho para que lo llame el código — y el primer trabajo que le encaja esa forma es el enrutado.

Un modelo hecho para decidir, no para hablar​

El nombre cuenta la historia dos veces. "System One" es el término de Kahneman para el juicio rápido y automático — la decisión instantánea — frente a "System Two", el razonamiento lento y deliberado para el que recurrimos a un LLM grande. Y "Jev" es por William Stanley Jevons, el economista de la paradoja de la eficiencia: abarata algo y la gente lo usa mucho más. TypeSafe apuesta a que las decisiones de máquina baratas se usarán en todas partes.

Un modelo de chat genera tokens uno a uno hasta que existe un párrafo. Jev hace lo contrario — TypeSafe dice que "gives up string generation", muestrea todas las salidas en una única consulta paralela, y devuelve un valor de un conjunto que defines de antemano. Salen dos propiedades, y ambas importan para el enrutado:

• La salida es tipada y estructurada, de un conjunto conocido (SIMPLE, MEDIUM, COMPLEX, REASONING), no prosa que tengas que parsear. TypeSafe afirma que "never makes type errors" — y conviene ser preciso, porque ellos lo son: ese 0% "is not empirical. Schema matching is guaranteed, thus we can confidently add 0%." Es una propiedad de restringir la salida a un esquema, no un resultado medido.
• Cada decisión lleva una probabilidad calibrada — "higher confidence means higher accuracy", entrenada con un método que llaman Reinforcement Learning for Calibrated Decisions (RLCD). Si eso se sostiene, el código puede actuar sobre el número: toma la etiqueta con confianza, escala cuando no.

Sus cifras estrella ("40x-200x faster", salida "too cheap to meter", una workflow eval a "193.6x faster, 444.6x cheaper") son afirmaciones del proveedor sobre sus propias evals, y para su crédito señalan el sesgo — las evals fueron "made by individuals on our model capabilities team". Trátalas como afirmaciones hasta que alguien independiente las repita.

Cómo funciona el enrutado, y por qué el que decide es el problema​

Enrutar modelos es una jugada de coste. No toda petición necesita tu modelo más grande, así que pones un modelo barato y uno caro detrás de un mismo endpoint y algo delante decide cuál responde. Los turnos fáciles van al nivel barato; los difíciles al caro; la factura baja. Ese "algo delante" es un clasificador:

Construye ese clasificador de la forma habitual — pregúntale a otro LLM "¿esto es simple o complejo?" — y cada petición paga por una llamada a un LLM antes de pagar por la respuesta. Esa llamada es lenta y cuesta tokens, en cada petición, haya acabado en el nivel barato o no. La decisión que debía ahorrar dinero lo está gastando en silencio.

Jev en el hueco del que decide​

Jev encaja en ese hueco. No le pides que responda — le pides a qué nivel pertenece la petición, y la pasarela enruta según la etiqueta:

En el Auto Router de LiteLLM eso es un cambio de configuración, no código nuevo — nombras los niveles, mapeas cada uno a un modelo, y pones classifier_type: jev:

- model_name: jev-router
  litellm_params:
    model: auto_router/complexity_router
    complexity_router_config:
      tiers:
        SIMPLE: {{openai_small}}
        MEDIUM: {{openai_large}}
        COMPLEX: {{anthropic}}
        REASONING: {{anthropic_large}}
      classifier_type: jev

Cuánto vale el cambio — y dónde falla el LLM​

El 20 de septiembre, Moe Khalil, de LiteLLM, publicó un benchmark titulado "JEV Classifier: 5.43x as Fast as Haiku, 96% Lower Cost." Corrió 80 casos tres veces cada uno — 240 llamadas — con Jev (jev-1.13.0) contra Claude Haiku 4.5 como línea base de "clasificar con un LLM":

La media esconde el hallazgo real, que está en los números por nivel. En SIMPLE ambos fueron perfectos (100%). Pero en MEDIUM Haiku se desplomó a 38.33% donde Jev aguantó 85%, y en REASONING Haiku logró 76.67% frente al 100% de Jev. Dicho de otro modo, el clasificador LLM distingue bien lo trivial de lo no trivial, y es poco fiable justo en la banda intermedia donde las decisiones de enrutado de verdad te ahorran o te cuestan dinero.

Dos salvedades, ambas de LiteLLM, dichas claramente: los niveles esperados "were authored with the synthetic prompts, without independent review", y el benchmark midió la decisión de enrutado, no la calidad de la respuesta final — "downstream answer quality was not measured". Para su crédito, publicaron un archivo de reproducción congelado y verificado por hash para poder re-analizar la corrida. Léelo como "Jev eligió el nivel rápido, barato y como esperaban", no como "tus respuestas salen un 96% más baratas de extremo a extremo".

Dónde encaja en WEC​

Construimos este mismo montaje en el tutorial de enrutado por complejidad — una pasarela delante de la WEC Inference API que puntúa cada petición y la manda al nivel correcto, Qwen3.5:9B para los turnos simples y Qwen3.5:122B para los difíciles. Y ya mostramos cómo un clasificador se equivoca con un simple "yes", mandando trabajo al modelo equivocado.

En ambos, el clasificador es la parte que nadie cuenta. Pon un LLM en ese hueco y añades dos tercios de segundo y un cargo en tokens a cada llamada antes siquiera de elegir el modelo real. Un modelo como Jev es una apuesta a que la decisión delante de tus modelos puede ser casi gratis — para que enrutar compense en lugar de cobrarse a sí mismo.

Es pronto, está alojado, y los números todavía necesitan que alguien independiente los repita. Para un stack WEC que mantiene la inferencia en casa, "alojado" es el verdadero signo de interrogación — estarías mandando la decisión de enrutado de cada petición a un tercero. Pero la forma es lo que viaja: un modelo que decide en milisegundos, sentado delante de los modelos que responden.

Fuentes​

• Diogo Almeida, TypeSafe — Introducing System One Models and Jev (15 de septiembre de 2026)
• Moe Khalil, LiteLLM — JEV Classifier: 5.43x as Fast as Haiku, 96% Lower Cost (20 de septiembre de 2026)

Pfizer opera un gateway de IA — el único servicio con el que habla cada herramienta interna cuando quiere un modelo. Durante una verificación rutinaria de actualización, su throughput cayó a la mitad. Sin errores. Sin peticiones fallidas. Nada raro en ningún dashboard.

Publicaron lo que encontraron junto al equipo de LiteLLM, y la causa es lo bastante pequeña como para caber en un párrafo: alguien escribió una opción que decía no cifres esta conexión, y el sistema la cifró igual.

Qué salió mal exactamente​

El gateway mantiene una caché — un almacén lateral rápido llamado Redis que consulta antes de hacer trabajo costoso. La conexión a esa caché puede ir cifrada o no, y eso es una opción que escribes en un archivo de configuración.

El operador escribió la opción en off. Conexión plana, sin cifrado.

El código que leía esa opción comprobaba si la opción existía, no a qué estaba puesta. Escribir off crea la opción. La opción ahora existe. Así que la comprobación pasó, y el gateway abrió una conexión cifrada — contra una caché que no esperaba ninguna.

Aquí está la parte que lo vuelve peligroso y no solo incorrecto. Cuando un programa intenta iniciar una conversación cifrada con algo que no habla cifrado, no lo rechazan. Dice hola y espera una respuesta que nunca llega. No rechazado — ignorado.

Así que la caché no estaba caída. La caché estaba lenta. Y lo lento es mucho más difícil de ver.

Las cuatro líneas​

Para quien quiera mirarlo directamente, esto es get_redis_connection_pool tal como estaba en la versión afectada:

connection_class = async_redis.Connection
if "ssl" in redis_kwargs:
    connection_class = async_redis.SSLConnection
    redis_kwargs.pop("ssl", None)
    redis_kwargs["connection_class"] = connection_class

"ssl" in redis_kwargs pregunta ¿existe esta clave?. Existe — la creaste tú al ponerla en false. La rama se ejecuta, y obtienes la conexión cifrada que acabas de desactivar explícitamente.

Omite la opción por completo y todo funciona. Escríbela y di que no, y se rompe. La configuración cuidadosa es la que está rota.

Por qué nadie recibió un error​

Cada capa por encima de la caché está construida para tolerar que la caché no responda, y ese diseño es correcto — si la caché no está disponible, haces el trabajo por la vía lenta y sigues adelante. Que es precisamente lo que convierte esto en silencio:

Redis timeout errors appeared in the proxy's internal logs, but the gateway still returned HTTP 200 to every caller

HTTP 200 significa éxito. Cada una de las peticiones reportó éxito, durante todo el episodio. El post es preciso sobre dónde cayó el daño:

Redis operations were stalling on TLS handshake timeouts in the async hot path, degrading throughput without surfacing HTTP-level errors

Las cifras reportadas: throughput de unas 300 peticiones por segundo a unas 156 — aproximadamente la mitad — con tiempo de respuesta mediano bajo carga en 4.200 ms, medido contra 750 usuarios concurrentes simulados durante una ejecución sostenida de 60 segundos.

Esas mediciones vienen de las pruebas internas de Pfizer y se reportan en el post, no son reproducibles de forma independiente. El código es otra cosa — puedes abrir el archivo en esa versión y leerlo tú mismo.

Su propio resumen en una línea es la mejor frase del artículo:

A throughput drop with a 0% HTTP error rate is the worst kind of regression to catch after the fact

El bug ya estaba ahí​

Quise saber si esto llegó con la actualización que lo expuso. No fue así. Comparé el archivo relevante entre la versión que rendía bien y la que no — son idénticos byte a byte. El post dice lo mismo:

The underlying Redis bug existed in older versions too, but surfaced during Pfizer's v1.89.2 upgrade validation under this workload

Ese es el detalle que vale la pena masticar. Esto no era una release mala que pudieras revertir. El fallo llevaba tiempo en el código de conexión, atravesando versiones que rendían perfectamente bien en los benchmarks. Necesitó una configuración concreta y una carga concreta antes de hacer daño visible — y entonces costó la mitad de la capacidad de un gateway en producción sin levantar nada.

Cómo lo encontraron en realidad​

No con monitoreo, y no rastreando cambios recientes de código. Apagando y encendiendo funcionalidades hasta que el número se movió:

Enabled Redis caching. Median latency jumped to 4,200ms. That isolated it to the Redis connection path.

Un equipo con tráfico real en producción, observabilidad real y línea directa con el proveedor encontró esto a mano. No había señal en la tasa de error, porque no había errores. Nada en los códigos de estado, porque todos decían éxito. El único lugar donde aparecía era el tiempo de respuesta bajo carga sostenida — que solo ves si vas a buscarlo a propósito.

Eso coincide con lo que me encontré a una escala mucho menor cuando hice un load test a un gateway para encontrar el atasco que la mediana esconde: en este tipo de infraestructura, los fallos que más te cuestan son los que nunca levantan un error. Un callback bloqueante y una conexión atascada esperando un handshake son bugs completamente distintos con la misma huella — el throughput se desploma, las peticiones más lentas se vuelven mucho más lentas, y la tasa de error nunca se mueve.

Debo ser honesto sobre los límites aquí: no opero nada a la escala de Pfizer, así que no puedo reproducir sus mediciones. Lo que sí puedo hacer es leer el código, y el código es público.

El arreglo​

Una línea, en la versión actual:

if redis_kwargs.pop("ssl", None):
    redis_kwargs["connection_class"] = async_redis.SSLConnection

Esta versión lee el valor de la opción en lugar de limitarse a notar que existe. Off ahora significa off.

Está registrado como "Redis ssl handling — Presence check → value check" bajo LIT-4307 y PR #32590, publicado en v1.93.0. El título del pull request lo dice sin rodeos: honor ssl value instead of key presence when building async connection pool.

Qué llevarse de esto​

Dos cosas, si operas algo con una caché detrás.

Comprueba qué hizo tu sistema en realidad, no qué le dijiste que hiciera. Escribir una opción y que esa opción surta efecto son eventos distintos, y este es un ejemplo limpio de esa brecha. La conexión que obtuvo Pfizer era la contraria a la que pidieron, y nada en ninguna parte lo dijo.

Si tus pruebas miden promedios, no pueden ver esto. Tampoco las alertas construidas sobre tasas de error. Carga sostenida, tiempos de las peticiones más lentas, y throughput comparado contra una línea base conocida son lo que convierte un atasco silencioso en algo visible.

Los dashboards siguieron en verde durante todo el episodio. Eso no es una brecha de monitoreo que cierres añadiendo otra alerta sobre errores — no había ninguno sobre el que alertar.

El roadmap actual de los mantenedores de MCP nombra un problema que la mayoría de quienes construyen agentes ha sentido sin medirlo: el catálogo de herramientas de un servidor se le cobra al modelo antes de que alguien pregunte nada. Bajo Improved primitives, el artículo es directo al respecto — "Connecting to a server with a hundred tools means the model pays for that entire surface before the user has asked a single question, and tool selection tends to get worse as the list grows."

Lo que hace que esto valga la pena no es el roadmap. Es que el arreglo ya está escrito, en la documentación de clientes, junto a una advertencia de que puede costar más que el problema que resuelve — y esa advertencia recibe mucha menos atención que el arreglo al que pone condiciones.

El número que los docs le ponen​

La página de buenas prácticas para clientes que salió con la especificación 2026-07-28 describe el descubrimiento progresivo: el host sigue llamando a tools/list como siempre, pero posterga inyectar esas definiciones en el contexto del modelo. En su lugar le entrega al modelo una sola meta-herramienta liviana, search_tools, y carga los esquemas completos solo de lo que vuelva.

El propio diagrama de la página pone cifras a la diferencia — unos 150.000 tokens consumidos solo por las definiciones cuando se carga todo por adelantado, contra unos 2.000 con descubrimiento progresivo. Esa es la ilustración de la documentación, no un benchmark publicado, así que trátala como el orden de magnitud que afirman los mantenedores y no como una medición que puedas reproducir. Aun así la forma sirve: dos órdenes de magnitud, pagados antes de que empiece la conversación.

Los docs también dan un umbral en lugar de dejarlo al gusto:

Implement a threshold as a percentage of the context window. For example, 1%-5%.

Por debajo de eso, cargar todo está bien. Por encima, cambia de estrategia.

La trampa​

Aquí está la frase que cambia cómo construirías esto. En la misma página, bajo Interaction with Prompt Caching:

Adding or removing tool definitions mid-conversation invalidates that cache, and the resulting miss can cost more tokens than the definitions you removed.

La mayoría de los proveedores cachea el prefijo del prompt, y el arreglo tools vive cerca del principio de ese prefijo. Así que el mecanismo que te ahorra 148.000 tokens de definiciones por adelantado funciona mutando el prefijo — que es exactamente lo que una caché de prompt no tolera. Una caché de prefijo solo vale hasta lo primero que cambió: edita el arreglo en el turno seis y se va todo lo cacheado a partir de ahí, que en una conversación larga es casi todo.

Las mitigaciones que dan los propios docs conviene leerlas como restricciones de diseño más que como consejos: añadir las definiciones nuevas estrictamente después del punto de corte de la caché en vez de reordenar el arreglo tools, o enrutar cada llamada por una única meta-herramienta estable call_tool({name, args}) para que el arreglo no cambie nunca. Y tratar la desconexión de un servidor como una frontera de conversación, no como una operación por turno.

Tres cachés, y solo una es del protocolo​

Aquí es donde se vuelve genuinamente confuso, y vale la pena separar las capas porque es fácil colapsarlas en una.

La caché de transporte. Los resultados de tools/list llevan pistas ttlMs y cacheScope, definidas en la utilidad de caché de la especificación. Un cliente que las respete se salta el viaje HTTP. Esta sí es de MCP, en el sentido de que el protocolo la especifica.

El memo del lado del host. Consejo, no protocolo — una línea en las guías de implementación de la documentación de clientes, que recomienda memoizar una definición ya obtenida para que reinyectarla después no requiera otra llamada. Describe qué debe hacer un host con su propio estado; nada cruza el cable. La página es explícita sobre lo que no hace: "This is separate from what's currently in the model's context."

La caché de prompt del proveedor. No es de MCP en absoluto. Es de quien sirve tu modelo, se indexa por el prefijo, y la invalida exactamente aquello que el descubrimiento progresivo hace para vivir.

Con la primera nos topamos por la vía difícil al escribir la Parte 3 de la serie de LangGraph — un cache=True del lado del cliente no hace nada si el servidor no anuncia un TTL, y nada te avisa. Habiendo leído ahora esta página con calma, la lección más útil es que incluso acertando con eso lo que compras es un viaje de ida y vuelta y nada más. Los esquemas siguen aterrizando en el contexto. Son problemas distintos con arreglos distintos, y confundirlos es el error por defecto.

Qué significa si acotas herramientas a mano​

La Parte 4 partió un servidor MCP entre un agente de agenda y uno de facturación filtrando el catálogo por rol — una lista de permitidos estática, decidida antes de la corrida y fija durante toda ella.

Leído contra estos docs, eso resulta tener una propiedad que vale nombrar: como la lista no cambia a mitad de conversación, no toca el prefijo del prompt, así que esquiva por completo el problema de invalidación de caché. Es un instrumento más tosco que search_tools — decides por adelantado en lugar de dejar que el modelo busque — pero para un catálogo pequeño repartido entre roles conocidos, "tosco y estable respecto a la caché" puede ser simplemente el intercambio correcto. Los docs dicen algo equivalente en la otra dirección: por debajo del umbral del 1–5%, cargar todo está bien.

No generalizaría más allá de eso. No hemos medido el costo de un fallo de caché contra el costo de las definiciones en la WEC Inference API, y la posición honesta es que el punto de cruce depende del tamaño de tu catálogo, del largo de tus conversaciones y del comportamiento de caché de tu proveedor. Lo que los docs establecen es que ese punto de cruce existe.

Sobre que el roadmap no tenga fechas​

El roadmap nombra cinco áreas prioritarias y no se compromete a ninguna fecha de lanzamiento ni número de versión en ninguna parte. Es justo preguntar por qué, y la respuesta más justa viene de los propios mantenedores. Soria Parra, en el roadmap de marzo:

A release-oriented roadmap implies a level of predictability that open-standards work rarely has.

Es una postura razonable para una especificación que se desarrolla en grupos de trabajo, y el propio historial de marzo la respalda. "Transport Evolution and Scalability" era una de sus cuatro áreas prioritarias, y nombró el problema con precisión — llevar MCP a escala había dejado al descubierto "a consistent set of gaps: stateful sessions fight with load balancers, horizontal scaling requires workarounds" — sin comprometerse a ninguna fecha para arreglarlo. La especificación de julio entregó ese núcleo sin estado, cinco meses después.

El caché es otra historia. No aparece en ninguna parte del roadmap de marzo, y el descubrimiento progresivo llegó como documentación para clientes sin haber estado en ningún roadmap — algo que conviene tener en cuenta antes de tratar cualquiera de los dos roadmaps como un índice fiable de lo que viene.

La recepción no ha sido uniformemente cálida. El hilo de Hacker News sobre el roadmap llegó a 270 puntos y 161 comentarios, y la crítica va en tres direcciones, no en una. El costo del vaivén pasado, de colingauvin:

It's unreal how bad the initial rollout was between HTTP/streaming and stdio, bearer auth and OAuth. Virtually every client/MCP server pair had a different portion of that matrix implemented.

El diseño en sí, de nprateem:

The real disaster was making it stateful. Need to get some adults in the room.

Y si el protocolo justifica su complejidad, de zackify: "I think the spec overcomplicates everything honestly."

La primera es la que atañe a este post. Es un reclamo legítimo sobre la deriva entre implementaciones, y es el riesgo a vigilar también con el descubrimiento progresivo: hoy es un patrón del lado del cliente, con estrategias recomendadas en lugar de especificadas, lo que significa que dos hosts pueden ser ambos razonables y comportarse distinto.

La versión corta​

El roadmap te dice que el inflado del catálogo de herramientas está en la lista de los mantenedores. La documentación te dice qué hacer al respecto ahora y — hay que reconocérselo — te dice en la misma frase que el arreglo tiene una factura. Si estás cargando un catálogo grande en cada conversación, lee esa página antes de construir una capa de descubrimiento, y averigua dónde está el punto de corte de caché de tu proveedor antes de decidir que las cuentas de tokens te favorecen.

📖 Fuentes: Blog del Model Context Protocol — The New MCP Roadmap · Docs de MCP — Client Best Practices · Blog del Model Context Protocol — The 2026 MCP Roadmap · Hacker News — New MCP Roadmap

En julio la especificación de MCP arrancó las sesiones. Escribimos entonces que el cambio era infraestructura, no changelog — que un núcleo sin estado dejaría a los servidores sentarse detrás de balanceadores de carga corrientes y sobrevivir a los redespliegues, y que los clientes tendrían que ponerse al día.

Hoy LangChain se puso al día. El soporte de MCP salió del paquete separado langchain-mcp-adapters y entró en langchain mismo, reconstruido sobre FastMCP, con dos funciones que la especificación vieja hacía imposibles: elicitación como interrupt de LangGraph y un catálogo de herramientas cacheable.

Lo instalamos esa misma tarde y lo apuntamos a un servidor que escribimos contra la nueva especificación. El anuncio es correcto. El ecosistema alrededor no está listo — y uno de los huecos convierte silenciosamente una puerta de aprobación humana en una frase que el modelo se inventa.

Lo que realmente salió​

pip install "langchain[mcp]", que requiere 1.4.0 o superior, y en beta — lo dice al importar, como puedes ver en nuestras capturas más abajo. Python hoy, TypeScript "poco después".

• Una clase, en el paquete principal. MultiServerMCPClient se colapsa en MCPAdapter. async with MCPAdapter(url) as adapter: y luego await adapter.list_tools(), y lo que vuelve son herramientas de LangChain corrientes que van a donde van las herramientas.
• Construido sobre FastMCP, así que transportes, autenticación (bearer, OAuth 2.1, máquina a máquina, CIMD, o cualquier httpx2.Auth), gestión de conexiones y negociación de protocolo vienen del cliente de debajo. MCP tiene ahora dos eras — el protocolo con handshake del 2025-11-25 y el sin estado del 2026-07-28 — y el cliente de FastMCP elige una por conexión: "prueba el protocolo nuevo y recae en el handshake para un servidor que no se ha actualizado".
• Elicitación vía interrupts. Cuando una herramienta del servidor MCP no puede terminar sin preguntarle a un humano, la ejecución de tu agente se pausa como un interrupt() de LangGraph, y la reanudas con una respuesta estructurada. Esto solo es posible porque la especificación sin estado convirtió una pregunta a mitad de llamada en una ronda reintentable en lugar de algo mantenido abierto en un socket.
• Caché del lado del cliente. fastmcp.Client(url, cache=True) respeta las pistas de frescura del servidor para que el catálogo de herramientas no se vuelva a pedir en cada ejecución.
• ClientGroup para varios servidores a la vez, cada uno conservando su propia era y sus credenciales, con los nombres de herramienta prefijados por servidor — billing_search y docs_search se mantienen distintos.

El encuadre del anuncio es el mismo que usamos en julio: "un redespliegue ya no mata sesiones vivas, porque no hay ninguna."

Lo que la especificación sin estado realmente quitó​

Una llamada a una herramienta, antes y después, es la imagen más clara de lo que cambió — así que aquí está, con un tercer panel para lo que realmente obtuvimos:

Los dos primeros paneles son la promesa, y la promesa es real. El tercero es lo que hace un servidor recién creado la tarde en que sale el cliente.

Tres cosas que todavía no funcionan​

Construimos un servidor MCP que expone una pequeña base de datos de citas y facturas, apuntamos un agente de LangChain hacia él, y pusimos un reembolso detrás de un humano. (El modelo del propio agente corre sobre un gateway autoalojado — eso está entre el agente y el LLM, no entre el agente y MCP.) Funciona — ese es el tutorial. Llegar hasta ahí sacó a la luz tres huecos entre lo que está escrito y lo que corre.

1. La especificación es sin estado. Tu servidor no, por defecto.​

La primera petición a un servidor FastMCP 4.0.2 recién creado — aquí un curl simple pidiendo tools/list, para que nada del lado del cliente cargue con la culpa:

Un error sobre un concepto que la especificación borró hace cinco semanas. El cliente es sin estado; el servidor sigue usando por defecto el transporte con estado.

El arreglo no es una cabecera, ni una opción del cliente, ni nada que tú envíes. Es un argumento en la llamada que arranca tu servidor — la última línea del archivo del servidor, donde mcp es tu instancia de FastMCP:

from fastmcp import FastMCP

mcp = FastMCP("office-tools")

# ... tus funciones @mcp.tool ...

if __name__ == "__main__":
    # Sin stateless_http=True este servidor le responde a un cliente
    # del 2026-07-28 con "Bad Request: Missing session ID".
    mcp.run(transport="http", host="127.0.0.1", port=8770, stateless_http=True)

Nada en el anuncio lo dice — con razón, porque el post trata del cliente. Pero significa que la mitad cliente de la actualización es un pip install, y la mitad servidor es un flag que tienes que saber que existe.

Existen dos flags, y run_http_async (al que mcp.run llama para HTTP) acepta ambos. De su propio docstring:

stateless_http: Whether to use stateless HTTP (defaults to settings.stateless_http)
stateless: Alias for stateless_http for CLI consistency

Un interruptor, dos nombres, y el ajuste al que recae está apagado.

2. ctx.elicit es la API vieja — y el error va al modelo, no a ti​

Todos los ejemplos de elicitación que encontrarás llaman a await ctx.elicit(message, response_type) dentro del cuerpo de la herramienta, donde ctx es el objeto Context que FastMCP le pasa a tu herramienta. Ese es el mecanismo de la era del handshake: bloquea a mitad de ejecución y habla por el canal de retorno de la sesión — el canal de retorno que una conexión sin estado no tiene. La documentación de FastMCP es explícita en que es para conexiones ≤ 2025-11-25, y promete que llamarlo en una moderna "lanza un error de era claro en lugar de fallar de forma oscura".

Sí lanza uno. Ese no es el problema. Reconstruimos la herramienta de reembolso alrededor de ctx.elicit y ejecutamos el mismo agente contra ella:

Léelo en orden. FastMCP lanzó el error de era, exactamente como está documentado. LangChain lo capturó y lo convirtió en un ToolMessage con status="error". Eso es deliberado: langchain/mcp/tools.py conecta un manejador cuyo docstring dice que existe para entregarle al modelo el detalle del error del servidor "en lugar de terminar la ejecución". El modelo leyó ese error y le dijo al usuario:

He localizado a Maria Alvarez y he identificado su factura abierta (ID: 2) por 80,00 $. He iniciado la solicitud de reembolso para esta factura. Ten en cuenta que un humano debe aprobar el importe y dar una razón para completar el reembolso.

No se lanzó ningún interrupt. El proceso salió con 0. Nada está pendiente, nada está esperando a un humano, y a nadie se le va a preguntar nunca — y la factura sigue open, así que el reembolso tampoco ocurrió. Lo que obtienes no es una acción destructiva colándose por una puerta; es un flujo de aprobación que silenciosamente no existe, descrito en un español fluido por un modelo que leyó el error y lo parafraseó como progreso.

El arreglo es que el patrón moderno hace que la herramienta devuelva un InputRequiredResult describiendo lo que necesita, y salga. Tu agente lo expone como el interrupt de LangGraph, un humano responde, y el cliente MCP reemite el mismo tools/call con la respuesta adjunta. Pero el modo de fallo es la historia: un error de era es algo estupendo que lanzarle a un programa, y algo terrible que entregarle a un modelo de lenguaje al que se premia por sonar servicial.

3. cache=True es necesario, no suficiente​

La caché del cliente respeta las pistas ttlMs y cacheScope que un servidor adjunta a su respuesta de tools/list, y solo contra servidores de la era moderna que las envían. Un servidor FastMCP por defecto no envía ninguna — volcamos nuestra propia respuesta de tools/list y no lleva pistas de caché en absoluto. Así que enciendes la caché, llamas a list_tools(cache_mode="use") dos veces seguidas, cronometras ambas, y obtienes:

Concluyes que la caché está rota. No lo está — no había nada que cachear. Vale la pena notar que la caché pertenece al fastmcp.Client, no a MCPAdapter, y que un cliente por llamante evita que los catálogos se crucen entre inquilinos.

Y dos más pequeñas, en el propio anuncio​

El fragmento de elicitación lanza AttributeError. El post lee el interrupt como paused["__interrupt__"][0].value.requests[0] — acceso por atributo. En langchain/mcp/elicitation.py en 1.4.0:

class MCPElicitationInterrupt(TypedDict):
    type: Literal["mcp_elicitation"]
    tool_name: str
    requests: list[MCPElicitationRequest]

Un TypedDict es un dict en tiempo de ejecución, así que .requests no resuelve. Es value["requests"] — que el propio fragmento acierta unas líneas después, leyendo question["key"] por subíndice.

El enlace a la documentación de elicitación da 404. El post cierra la sección apuntando a docs.langchain.com/oss/python/langchain/mcp/elicitation para "declinar una pregunta, y poner herramientas destructivas detrás del mismo flujo de aprobación". Esa página devuelve 404 al momento de publicar, mientras que la página padre y sus otras hijas — mcp, mcp/connections, mcp/tools, mcp/auth — resuelven todas. Es, inconvenientemente, la única página que habría documentado el flujo de aprobación que el hueco 2 muestra cayéndose.

Por qué esto te importa a ti, específicamente​

Si consumes servidores MCP que ejecuta otra persona, esto son buenas noticias sin más y notarás sobre todo la ruta de import más corta.

Si escribes servidores MCP, la revisión de julio movió el suelo y las herramientas todavía se están asentando. Tres cosas son ahora tuyas para hacerlas bien: tu servidor no se vuelve sin estado porque la especificación lo hiciera — pones un flag; una herramienta que necesita entrada humana tiene que escribirse para ser reentrada en lugar de reanudada — interrupt() desenrolla la llamada completa, así que el cuerpo de la herramienta se ejecuta otra vez desde arriba cuando respondes; y cualquier ejemplo de elicitación anterior a agosto te está enseñando una API cuyo fallo aterriza en el contexto del modelo en lugar de en tus logs.

Eso último se generaliza más allá de MCP. A medida que los frameworks mejoran en mantener vivos a los agentes a través de los errores, la clase de bug que termina una ejecución se encoge y la clase que se le narra a un usuario crece. Una puerta que falla cerrada es un bug que encuentras en pruebas. Una puerta que nunca se instaló, descrita por un modelo como pendiente de tu aprobación, es una que encuentras en una auditoría.

La dirección es la correcta. El núcleo sin estado es lo que hace que la pausa de aprobación humana de un agente sobreviva a un redespliegue, y eso es una capacidad real más que una refactorización. Solo no esperes que tu primera petición funcione.

📖 Fuentes: LangChain — MCP en LangChain: protocolo sin estado, elicitación y más · Documentación de MCP en LangChain · Migrar desde langchain-mcp-adapters · Documentación del cliente FastMCP · Elicitación en FastMCP · Especificación MCP 2026-07-28

Versiones probadas: langchain 1.4.0, fastmcp 4.0.2, mcp 2.1.1, modelo servido sobre un gateway autoalojado. La captura de ctx.elicit es un render de la salida real de esa ejecución, no una captura de pantalla.

Solo reducir, nunca ampliar

Tu agente puede buscar en la web. Escribes en el prompt: usa solo sec.gov y los grandes medios financieros. Normalmente obedece. Las veces que no lo hace son las veces en que aprendes que una línea en un prompt es una petición, no una regla.

El 19 de agosto AWS añadió filtros de sitios a la herramienta de búsqueda web en Bedrock AgentCore. Función pequeña. Pero la forma en que maneja un desacuerdo vale la pena conocerla, porque es lo que la convierte en una barrera en lugar de una nota.

Lo que obtienes​

Dos filtros. Una lista de sitios a permitir y una lista a bloquear, más un rango de fechas para cuándo se publicó una página.

El agente puede pasarlos en la propia llamada de búsqueda:

{
  "method": "tools/call",
  "params": {
    "name": "WebSearch",
    "arguments": {
      "query": "latest SEC enforcement actions 2026",
      "filters": {
        "domainFilter": { "include": ["sec.gov"], "exclude": [] },
        "publishedDateFilter": {
          "from": "2026-07-01T00:00:00Z",
          "to": "2026-08-04T23:59:59Z"
        }
      }
    }
  }
}

Un administrador define el mismo tipo de lista en el gateway, donde el agente no puede verla ni cambiarla. Cada lista admite hasta 100 sitios.

La regla​

Así que el administrador tiene una lista y el agente tiene una lista. ¿Qué pasa cuando no coinciden?

Las listas de permitidos se intersectan. Las listas de bloqueo se combinan. "Los filtros en tiempo de ejecución pueden reducir pero nunca ampliar el alcance definido por un administrador."

La lista del administrador es el techo. El agente puede pedir menos, nunca más. Y todo lo que cualquiera de los dos bloquee queda bloqueado.

Dale la vuelta y verás por qué importa. Si las dos listas de permitidos simplemente se sumaran, la lista del administrador sería una sugerencia inicial. Un agente que quisiera otro sitio bastaría con nombrarlo en su propia llamada y lo obtendría. El filtro sería papeleo.

Esa es la diferencia entre los dos lugares donde puedes poner una regla. Pedirle a un modelo que se mantenga dentro de un límite significa pedirle que lo recuerde, a mitad de un trabajo, después de leer quién sabe qué. Un gateway comparando dos listas no está recordando nada.

El filtro de fecha es el traicionero​

La lista de sitios recibe toda la atención. El rango de fechas puede importar más.

Una página vieja no parece vieja. Una página de cuatro años sobre una regla fiscal o una API muerta se lee exactamente como una actual — mismo tono seguro, y ahora con una cita adjunta, lo que hace que una respuesta equivocada sea más convincente en lugar de menos. El modelo no puede juzgar qué tan fresca es una página cuando nada se lo dice. Definir una ventana le da un dato que de otro modo nunca tuvo.

El detalle​

La búsqueda cuesta 7 USD por cada 1.000 consultas y corre en tres regiones. El argumento de venta de AWS es que las consultas se quedan dentro de su red — "sin enviar los prompts de usuario ni las consultas de recuperación a proveedores de API de búsqueda externos fuera de AWS." Bueno si ya vives en AWS. Bastante irrelevante si no.

La idea viaja, sin embargo, porque la herramienta se alcanza sobre MCP: "Web Search usa un target de conector integrado en Bedrock AgentCore Gateway usando el Model Context Protocol (MCP)." Nada de las listas de permitidos se intersectan, las de bloqueo se combinan, el agente solo puede reducir necesita a Amazon. Cualquier gateway puede hacerlo, para cualquier herramienta — qué archivos puede leer algo, qué hosts puede alcanzar, qué tablas puede consultar.

Así que la pregunta que hay que hacer sobre una herramienta no es si puedes restringirla. Es dónde vive la restricción, y si el agente puede moverla.

Repasamos el protocolo que hay debajo de todo esto en la mayor actualización de MCP, y le dimos a un modelo búsqueda en vivo sin un servicio gestionado en búsqueda web en WEC Inference. El siguiente tutorial de la serie de agentes pone las herramientas de un agente detrás de un gateway que decide qué puede llamar.

Fuentes​

• Domain and publish date filters for Web Search on AgentCore — 19 de agosto de 2026
• Web Search in Amazon Bedrock AgentCore adds domain and published date filtering, expands to Europe and Asia Pacific — 19 de agosto de 2026
• Announcing Web Search on Amazon Bedrock AgentCore — 17 de junio de 2026

Clasificando la palabra "yes"

El trabajo de un router de modelos es leer una solicitud y decidir qué modelo debe responderla. Las preguntas baratas van a un modelo pequeño, las difíciles a uno grande, y la factura baja. Todo el arreglo depende de poder distinguir.

Entonces un usuario escribe "yes".

O "continue". O "hazlo". Nada en estas dos o tres letras dice si el trabajo que se está aprobando es una corrección ortográfica o una migración de base de datos. Un router que puntúa el mensaje actual de forma aislada ve una cadena muy corta sin vocabulario técnico, y hace lo obvio: modelo más barato.

Lo que significa que si rutas las solicitudes para ahorrar dinero, tu nivel más barato probablemente esté absorbiendo trabajo que nunca debería haber visto — y tu cifra de ahorro es en parte falsa. El 4 de agosto LiteLLM publicó un benchmark que mide ambas mitades de eso: qué tan mal se equivoca la ruta, y cuánto cuesta arreglarlo.

La medición​

El recorrido: 5.600 llamadas de clasificación en tiempo vivo contra proveedores reales, descritas como "dos recorridos de siete configuraciones cada una (tamaño de la ventana de contexto del clasificador de 0, 1, 2, 3, 5, 8, 10), uno con giros de asistentes en la ventana y otro sin, en tres conjuntos de datos multi-turno, con dos repeticiones por conversación."

La variable es cuántos giros anteriores puede ver el clasificador. Cero significa que juzga el mensaje actual solo. Diez significa que lee los diez giros anteriores primero.

Acuerdo con las capas de referencia, por tamaño de ventana:

Figura 1. Acuerdo con las capas de referencia por ventana de contexto, extraído de las cifras publicadas en el benchmark de LiteLLM. La línea roja es el subconjunto de 36 giros que solo resuelve la dificultad contra el historial.

Tres historias en tres columnas, que es lo primero que resulta útil aquí.

ShareGPT comienza en 83.8% y gana ocho puntos. MT-Bench no se mueve mucho en absoluto — 49.4% a 55.6% en todo el recorrido — y su propia advertencia explica por qué: "El techo de MT-Bench refleja sus etiquetas de referencia más que el comportamiento del router." El conjunto de respuestas cortas es donde le da, 50% a 90%.

El número que vale la pena citar, con su denominador​

Dentro de la primera columna se encuentra un subconjunto, y es el resultado más agudo en la publicación:

Acuerdo de 14% en N=0, 47% en N=1 y 78% en N=2, y plano desde allí hasta N=10.

Catorce por ciento a setenta y ocho por ciento, logrado mostrando al clasificador dos giros anteriores.

Esta cifra describe 36 seguimientos — los que "su giro final solo resuelve contra el historial" — es un subconjunto elegido deliberadamente, no una afirmación de precisión general, y leerlo como "los routers son 14% precisos" sería incorrecto. Lo que muestra es la forma del error: cuando la dificultad de un giro vive enteramente en lo que ha venido antes, un clasificador sin contexto es peor que adivinar, y casi todas las correcciones ocurren con el segundo giro de la historia.

La curva que permanece plana en N=2 es la parte prácticamente útil. Esto no es un resultado de "más contexto es mejor". Es un resultado de "dos giros es casi todo lo que necesitas".

Lo que costó, y lo que costó más​

Esta es la mitad que hace que el hallazgo sea accionable, y donde la respuesta honesta es más interesante que "es barato".

La ventana en sí es gratuita. Cada comparación emparejada contra la configuración de ventana cero tiene un intervalo de confianza bootstrap de 95% que abarca cero. Ventana 1 con giros de asistente desactivados llega a -17.8 ms, intervalo -68.9 a +29.6. Su explicación es que la ventana solo añade pre-relleno — la salida permanece una etiqueta de nivel pequeña y fija. En un rango de 318 a 1.043 prompts de tokens, los tokens y la latencia se correlacionan en r = 0.007.

El clasificador no es gratis. Añadir historia no cuesta nada, pero pedirle a un modelo que clasifique a toda costa "está a 600 ms en cada configuración" — y eso está delante del final de la finalización. El clasificador aquí es gpt-5.4-mini, y se ejecuta a 0.31–0.61 dólares por 1.000 solicitudes en todo el recorrido. Barato en dinero, medio segundo en tiempo.

Y la precisión aumentó el coste. Esta es la parte que vale la pena reflexionar sobre. Para el conjunto de respuestas cortas, el coste modelado de la ruta aumentó con la ventana — de 2.87 a 6.49 dólares por 1.000 solicitudes. No una regresión: la razón es "una mezcla de nivel del 66% SIMPLE en N=0 contra 30% en N=2". Dos tercios de esas solicitudes de seguimiento se estaban sirviendo por el modelo más barato. Una vez que el clasificador podía ver lo que estaban aprobando, dejaron de hacerlo.

Así que la ruta era barata porque estaba equivocada. El ahorro era una factura que alguien más estaba pagando, en respuesta a calidad, en solicitudes que nadie estaba auditando. En los otros dos conjuntos de datos el efecto va al revés — el coste modelado de ShareGPT disminuye ligeramente, porque el contexto permite que el clasificador se establezca en MEDIO en lugar de por defecto a REASONING.

Esto es lo que vale la pena quedarse con ello: un mejor contexto no corta de forma fiable los gastos. Mueve los gastos hacia donde realmente estaba el trabajo.

Dos cosas que esto no resuelve​

La configuración predeterminada es 3, y 3 no es el mejor número en ninguna columna. Diez es mejor para respuestas cortas de seguimiento en 90.0%, y simultáneamente el peor resultado para ShareGPT más allá de N=2, cayendo a 88.8% de 91.9%. Más historia no es un resultado monótonamente mejor, y el nivel predeterminado enviado es una llamada de juicio en los conjuntos de datos que no están de acuerdo.

Y nombran sus propios límites, que es la marca de un benchmark digno de confianza: "Las capas de referencia son llamadas de juicio", "El coste de finalización del enrutamiento se modela más que se factura", "Un clasificador de modelos fue recorrido", y "La latencia se midió en una sola máquina virtual a una concurrencia de 10". Una concurrencia de 10 en una sola máquina no es de producción, y un clasificador de modelos más pesado tiene más latencia absoluta que el que usaron.

Por qué importa si enruta algo​

La lección sobrevive a la implementación específica. Si está eligiendo modelos por solicitud — con una heurística, un clasificador o una regla hecha a mano — los giros que le avergonzarán no son los largos técnicos. Son los cortos. Una ruta que puntúa "yes" como una pregunta trivial, ruta la aprobación de una migración de arquitectura al modelo más pequeño que tiene — y nada en sus registros lo señalará, porque una respuesta barata a una pregunta barata es exactamente lo que le pediste.

Su solución es una ventana de giros anteriores. La solución más barata, si su clasificador no tiene tal opción, es darse cuenta de que las respuestas cortas en una conversación establecida son la población para preocuparse y dejar de puntuarla en su propio contenido.

Lo tomamos el mismo router por el otro lado recientemente — las siete dimensiones de puntuación, el cálculo en un prompt real, y lo que un escáner de palabras clave gratuito pierde que un modelo captura — en ruta por complejidad.

Fuentes​

• Auto Router v1.97: benchmarks de uso y mejor calidad para un menor coste — 4 de agosto de 2026
• Referencia de configuración de enrutamiento automático

Enmascara tus registros, no tus indicaciones

Casi cada guía de "asegura tu aplicación LLM" da el mismo consejo: antes de que una indicación llegue al modelo, elimina los datos personales de ella — intercambia nombres, correos electrónicos y números de cuenta por [REDACTED] o <PERSON>, luego llama al modelo.

Suena obviamente correcto. Yo también asumí que lo era. Luego fui y leí la investigación sobre lo que realmente hace el enmascaramiento a un modelo, y los documentos apuntan en la dirección opuesta. La versión corta: enmascara tus registros, no tus indicaciones.

Primero, ¿qué estamos protegiendo?​

PII es información de identificación personal — un nombre, un correo electrónico, un número de teléfono, un ID de cuenta o gubernamental. Datos que apuntan a una persona específica.

Cuando las personas recurren al enmascaramiento previo a la llamada, generalmente están combinando dos preocupaciones diferentes en una:

1. "No quiero enviar datos sensibles a quien ejecute el modelo."
2. "No quiero almacenar datos sensibles en mis registros."

El enmascaramiento previo a la llamada está dirigido a #1. Mantén eso — resulta que es importante.

Problema 1: una indicación enmascarada es un modelo confundido​

Aquí está el fallo más simple. Pon a tres personas en una indicación y enmascara a todas ellas como [REDACTED], y el modelo ya no puede diferenciarlas. ¿Quién firmó el contrato? ¿Quién fue copiado? Las palabras que llevaban esas relaciones han desaparecido, por lo que la respuesta se degrada.

Esto no es solo intuición. Un benchmark de 2026 llamado RedacBench midió el compromiso directamente, a través de 514 textos y 187 políticas. Incluso cuando un modelo capaz hace el enmascaramiento, subir el dial de seguridad a ~81% de contenido sensible eliminado te deja conservando solo 37.6% del significado no sensible del texto. Descartas aproximadamente 60% de lo que hacía útil la indicación para obtener esa privacidad.

"Pero yo uso tokenización inteligente" — aún así duele​

La solución obvia es dejar de usar marcadores tontos. La tokenización determinista asigna el mismo valor al mismo token cada vez — "John Smith" siempre se convierte en PERSON_42, "Jane Doe" siempre en PERSON_17 — así que el modelo aún puede rastrear quién hizo qué. Eso es genuinamente mejor.

Pero tampoco es gratis. Un ingeniero realizó 109 pruebas de enmascaramiento en flujos de trabajo de salud, legales, financieros y de desarrollo y escribió dónde falló. (Divulgación completa: él también vende una herramienta de tokenización, así que toma su marco con un grano de sal — pero los fallos que registró son concretos y fáciles de reproducir.)

• Rechazos por frases de contexto. Tokeniza un SSN en GOV_ID_8x3m, pero deja las palabras "número de seguro social" al lado, y el filtro de seguridad del modelo puede rechazar toda la solicitud — ve una etiqueta sensible junto a un token opaco y lo marca.
• Falsos positivos. La palabra "Will" en "esto actualizará el registro" fue atrapada por el detector de nombres.
• Faltantes. Un nombre corto como "Li" en una fila de tabla, o un SSN enterrado en comentarios de código, pasó desapercibido por el detector cuando no había suficiente contexto circundante.
• Corrupción en streaming. Un nombre o SSN puede dividirse en dos o tres fragmentos de streaming; procesarlos uno a la vez y estropeas la entidad.

Su detección general resultó en 89% — y su punto más agudo fue que el 11% que falta es donde duele: estás forzado a bloquear una solicitud legítima o filtrar. No hay un valor predeterminado cómodo.

Por qué nada de esto es sorprendente (mi lectura, no una prueba)​

Retrocede y encaja en un patrón que la investigación sigue encontrando: los modelos son frágiles a cómo se formula una indicación.

• "Sobre el peor rendimiento de indicaciones de LLMs" tomó la misma pregunta, la reformuló de maneras semánticamente idénticas, y observó que la precisión de un modelo oscilaba en 45 puntos (en el peor de los casos, 9.38%).
• El marco DETAIL encontró que las indicaciones más específicas razonan mejor, especialmente en modelos más pequeños y tareas paso a paso.

Ninguno de esos documentos probó el enmascaramiento de PII — así que este siguiente paso es mi inferencia, no su afirmación — pero el enmascaramiento es una edición de indicación. Hace que la indicación sea menos específica y cambia su redacción, que es exactamente la palanca a la que estos documentos muestran que los modelos son sensibles. Estás tirando dados que no necesitas tirar.

La factura oculta​

El enmascaramiento también cuesta dinero de una manera que es fácil de pasar por alto, porque cambia la indicación en cada llamada. Eso rompe silenciosamente el almacenamiento en caché de indicaciones — el descuento que obtienes cuando la apertura de una indicación es idéntica a una anterior.

Ambos proveedores principales almacenan en caché por prefijo, y ambos dicen que un cambio al principio lo invalida:

• OpenAI: "Los aciertos de caché solo son posibles para coincidencias exactas de prefijo… un cambio antes del punto de ruptura evitará un acierto de caché."
• Anthropic: "Los cambios en cada nivel invalidan ese nivel y todos los niveles subsiguientes."

Una lectura de caché cuesta aproximadamente 10% del precio normal de tokens de entrada. Así que cada indicación enmascarada que no acierta en la caché paga cerca de diez veces más por esos tokens, y también renuncia al primer token más rápido. Además, cuando un marcador enmascarado como PERSON_42 se filtra en una llamada a la herramienta, la herramienta lo rechaza y el agente vuelve a intentarlo — y un estudio de agentes de codificación encontró que pequeños cambios en la redacción de la indicación pueden multiplicar el uso de tokens 2.4–7.4× sin ganancia en éxito. (De nuevo: no específicamente enmascaramiento, pero el mismo mecanismo.)

El replanteamiento: el modelo nunca fue el riesgo​

Aquí está la parte que tenía al revés. El problema nunca fue que el modelo vea los datos. Un modelo que lee tu indicación para responderla simplemente está haciendo su trabajo — ese paso de inferencia no es donde se filtran los datos. La verdadera pregunta es retención: qué se almacena, y dónde.

Una vez que lo ves de esa manera, la solución es obvia. Coloca el enmascaramiento donde realmente ocurre el almacenamiento y donde tienes control: tus registros.

Enmascara tus registros, no tus indicaciones​

El patrón — a menudo llamado solo registro — es simple:

• La indicación cruda llega al modelo, por lo que el razonamiento se mantiene intacto, la caché aún acierta, y nada se rechaza.
• Tu enmascaramiento de PII se ejecuta solo en el camino hacia el almacenamiento — los registros de solicitud/respuesta y trazas que escribe tu puerta de enlace.

Piensa en ello como tres peldaños, de peor a mejor:

1. Enmascaramiento tonto ([REDACTED]) — destruye las relaciones de entidad.
2. Tokenización (PERSON_42) — mantiene identidades, pero aún activa rechazos y faltantes.
3. Solo registro — el modelo lee el texto real; el enmascaramiento ocurre donde descansan los datos.

Una advertencia honesta: sea cual sea el proveedor al que envíes indicaciones, vale la pena conocer su política de retención — esa es una pregunta separada de lo que lee el modelo, y es el lugar correcto para poner esa preocupación.

Si ejecutas tu propia puerta de enlace​

La parte agradable: esto es una configuración, no una reescritura. Si ya has desplegado una puerta de enlace en una instancia WEC, la barrera funciona en modo solo registro — indicación limpia hacia el modelo, copia enmascarada en los registros. Un tutorial de seguimiento lo conectará de extremo a extremo.

Enmascarar una indicación antes del modelo te compra un checkbox de cumplimiento y vende silenciosamente la inteligencia de tu modelo. Coloca el trabajo de privacidad donde los datos realmente descansan — en los registros — y deja que el modelo lea lo real.

Fuentes​

• RedacBench: ¿Puede la IA borrar tus secretos? — arXiv 2603.20208 — 80.9% de seguridad / 37.6% de utilidad con redacción agresiva
• Sobre el peor rendimiento de indicaciones de modelos de lenguaje grande — arXiv 2406.10248 — oscilación de 45.48%, 9.38% en el peor de los casos
• DETAIL importa: Especificidad de indicaciones y razonamiento — arXiv 2512.02246
• Desperdicio inducido por indicaciones en agentes de codificación — arXiv 2608.01347 — multiplicación de tokens de 2.4–7.4×
• Tokenización determinista vs. enmascaramiento para PII: 109 pruebas — r/LLMDevs — informe de un practicante (el autor vende una herramienta de tokenización)
• OpenAI — Almacenamiento en caché de indicaciones
• Anthropic — Almacenamiento en caché de indicaciones

Desarrollo guiado por especificaciones, probado

Alguien publicó el desarrollo guiado por especificaciones en LinkedIn esta semana como la respuesta al vibe coding — a hacerle prompts a un agente, entendiendo a medias lo que estás construyendo, y terminar con código del que no puedes responder. El kit enlazado tiene 127.000 estrellas y viene de GitHub mismo. El argumento convence.

Así que lo instalé y lo apunté a una tarea deliberadamente trivial. Uno de los tres principios que escribió para mí fue una política de dependencias que nunca pedí — guarda ese pensamiento.

Veinte minutos no son un veredicto, sin embargo. Dos ingenieros lo han probado de verdad, en problemas reales, durante suficiente tiempo para que se vean las costuras. Usaron herramientas distintas, en continentes distintos, con siete meses de diferencia — y ambos recurrieron a la misma comparación, sin que nadie se lo pidiera: la última vez que nuestra industria intentó generar código funcional a partir de documentos. En la única pregunta que decide si algo de esto sobrevive al contacto con funcionalidades de IA, se contradicen rotundamente. Ninguno de los dos tiene una medición.

Qué es el desarrollo guiado por especificaciones​

Si el término es nuevo para ti, la idea es simple. En lugar de hacerle prompts a un agente e iterar hasta que el código se vea bien, escribes primero una especificación estructurada — qué estás construyendo, por qué, y qué significa "terminado" — y el agente trabaja a partir de ese documento en lugar de tu prompt. La especificación, no el código, se convierte en aquello a lo que todos señalan.

Spec Kit es la implementación de GitHub. Se instala en un repositorio una vez, no por tarea, y le da a tu agente un conjunto de comandos: constitution para fijar los principios del proyecto, y luego specify, plan, tasks, implement. Nada corre en segundo plano — deja plantillas y definiciones de comandos en tu proyecto, y a partir de ahí estás hablando con tu agente. Más cerca de una configuración de linter que de un producto.

Antes de todo eso, sin embargo, viene constitution — escrita primero, antes de que nadie haya visto el problema, y todo lo que viene después se juzga contra ella. Guarda eso también.

El paso de instalación te dice a qué apunta realmente:

Más de treinta agentes. Esta no es una herramienta solo para GitHub — quiere ser la capa a la que se conecta todo agente de programación, lo que explica bastante el número de estrellas.

Qué pasa realmente cuando lo usas​

Birgitta Böckeler, Distinguished Engineer en Thoughtworks, probó tres de estas herramientas a mano — Kiro, Spec Kit y Tessl — y publicó lo que encontró en octubre de 2025.

Le pidió a Kiro que arreglara un error pequeño. Produjo cuatro historias de usuario y dieciséis criterios de aceptación, incluyendo — literalmente — "Como desarrollador, quiero que la función de transformación maneje los casos límite con elegancia, para que el sistema siga siendo robusto cuando se introduzcan nuevos formatos de categoría." Su resumen: "como usar un mazo para partir una nuez."

Con Spec Kit y una funcionalidad real — unos días de trabajo, según su propia estimación — nunca terminó la implementación, y calcula que podría haber construido la cosa a mano en el tiempo que pasó revisando artefactos. La frase que resonará con cualquiera que haya hecho una revisión de código:

Para ser honesta, preferiría revisar código que todos estos archivos markdown.

También encontró al agente ignorando los documentos que debían guiarlo. El paso de investigación de Spec Kit catalogó correctamente las clases existentes; el agente entonces leyó esas descripciones como una especificación y generó las clases otra vez, duplicadas. Y el fallo inverso — el agente yéndose "muy por encima porque estaba siguiendo las instrucciones con demasiado entusiasmo (por ejemplo, uno de los artículos de la constitución)."

Alex Punnen fue más estrecho y más profundo, y publicó la transcripción completa con citas por línea. Spec Kit v0.8.9, en un problema a escala real: consultar datos de elevación de Estados Unidos en 1.756 mosaicos de mapa — 23 mil millones de mediciones, 180 GB.

Su hallazgo es más sutil que "la herramienta inventa cosas". Pidió principios que cubrieran calidad de código, pruebas, consistencia y rendimiento, y dice claramente: "Los principios en sí mismos son razonables." Lo que salió mal, argumenta, es que uno de ellos inclinó silenciosamente todas las decisiones posteriores:

Las nuevas dependencias DEBEN justificarse por escrito: problema resuelto, alternativas consideradas, licencia verificada.

Sensato en aislamiento. Pero como lo plantea Punnen, "la opción de la biblioteca estándar siempre gana los empates porque cuesta cero entradas de justificación." Cuatro fases después el plan eligió SQLite porque — primera razón listada — "Biblioteca estándar, cero dependencias nuevas… esa es la respuesta más barata posible." Tres de las cuatro alternativas rechazadas cayeron por esa misma regla. Su veredicto: "La constitución hizo el rechazo; el agente solo era el micrófono."

Luego viene la parte que me costó más quitarme de encima. Antes en el proceso el agente había escrito un presupuesto de rendimiento de cinco minutos en la especificación — un número que adivinó, sin ninguna medición detrás, archivado bajo la etiqueta SC-008. Más tarde, esa adivinanza volvió como la razón por la que no se podía usar un mejor diseño: "El costo de transcodificación se pasa de SC-008." Solo bajo presión directa concedió: "Tienes razón en que sobrevaloré la razón #2." El mejor diseño, escribe Punnen, no necesitaba nada que no estuviera ya en la especificación, "excepto la disposición a revisar un número arbitrario que la propia especificación produjo."

Su resumen de esa fase se aplica a toda la categoría:

El artefacto parece terminado porque cada casilla de la plantilla está llena — no porque la pregunta de ingeniería esté respondida.

Dos cosas hacen que esto sea más que un caso aislado. Su prompt de constitución era esencialmente el propio ejemplo documentado de GitHub, ligeramente adaptado — siguió la guía rápida. Y la resistencia que encontró es en parte por diseño: el documento de metodología de GitHub llama a la constitución "un conjunto de principios inmutables," con una sección titulada "El poder de los principios inmutables."

Para ser precisos, el presupuesto de cinco minutos no era un principio constitucional — era un criterio de éxito que el agente generó a partir de uno. El documento nunca afirma que esos sean inmutables. Pero el número cargó esa autoridad de todos modos, y hizo falta un humano para desalojarlo. La metodología argumenta a favor de fijar principios y no dice nada sobre qué pasa cuando las adivinanzas derivadas de ellos heredan la misma jerarquía.

Los tres niveles en los que nadie está de acuerdo​

La contribución más útil de Böckeler es una distinción que el resto del debate se salta. "Desarrollo guiado por especificaciones" cubre tres prácticas diferentes:

Su veredicto sobre dónde están realmente las herramientas: "Todos los enfoques y definiciones de SDD que he encontrado son spec-first, pero no todos aspiran a ser spec-anchored o spec-as-source." Incluido Spec Kit. La metodología de GitHub aspira mucho más alto — "Las especificaciones no sirven al código—el código sirve a las especificaciones" — pero Spec Kit crea una rama por especificación, así que una especificación vive lo que dura una solicitud de cambio, no una funcionalidad. Su conclusión: "spec-kit sigue siendo lo que yo llamaría spec-first solamente, no spec-anchored en el tiempo."

Vale saber que IBM publicó la taxonomía idéntica de tres niveles siete meses después, con nota al pie. Si la has visto atribuida a IBM, es de ella.

Lo que obtuve en una tarea trivial​

Ejecuté Spec Kit en el commit 83883a2 con un prompt deliberadamente mínimo — "Principios para una pequeña utilidad de Python. Mantenlo mínimo — no tengo restricciones fuertes."

Uno de los tres principios que escribió:

### II. Minimal Dependencies
Prefer the Python standard library. A third-party dependency MAY be added only when it
removes clearly more complexity than it introduces, and MUST be recorded in the project's
dependency file (e.g. `requirements.txt` or `pyproject.toml`).

Una política de dependencias, escrita en el lenguaje MUST/MAY de un estándar formal, a partir de un prompt donde dije que no tenía restricciones. No está en la plantilla local ni en el archivo de skill — pero el Artículo I de los nueve artículos constitucionales de GitHub sí pide implementaciones "con límites claros y dependencias mínimas." Así que es consistente con la filosofía publicada más que inventado en el momento. No puedo decirte el mecanismo, solo qué entró y qué salió.

Una ejecución, una tarea trivial, y no me costó nada porque no había nada en juego. El caso de Punnen muestra lo que cuesta este tipo de sesgo cuando el problema es lo bastante difícil para que se equivoque. El mío solo muestra que aparece sin que se lo pidan — lo que importa porque, como señala Böckeler, la constitución de Spec Kit es su banco de memoria, "un archivo de reglas muy poderoso" aplicado a cada cambio. Una preferencia no solicitada no se queda en un documento que vas a descartar. Se convierte en una regla permanente.

Los dos recurrieron a los años noventa​

Esto es lo que me convenció de que vale la pena tomarlo en serio en lugar de descartarlo o evangelizarlo.

Böckeler, que trabajó en desarrollo guiado por modelos al inicio de su carrera, ve MDD:

Me pregunto si spec-as-source, e incluso spec-anchoring, podrían terminar con las desventajas tanto de MDD como de los LLMs: inflexibilidad y no determinismo.

Punnen, veinte años en telecomunicaciones, recurre independientemente a Rational Rose y UML — "tratado como la bala de plata de su década: dibuja cajas, flechas y diagramas, y la herramienta mágicamente los convertiría en código funcional."

Ninguno cita al otro. Herramientas distintas, problemas distintos, países distintos. Ambos aterrizan en la misma época: la última vez que nuestra industria creyó que un documento podía ser la fuente y el código el resultado.

Böckeler es cuidadosa con la comparación — "No siento nostalgia por mi experiencia con MDD." Su punto es que las herramientas de hoy dejan atrás las partes que hacían doloroso a MDD: ya no necesitas un lenguaje especial de especificación ni un generador hecho a medida. Lo que se pregunta es si el intercambio es bueno, ya que el enfoque antiguo al menos producía la misma salida cada vez.

Punnen nombra la trampa que hay debajo:

La especificación tiene que ser muy rigurosa desde el principio, pero para volverse rigurosa necesita refinarse iterativamente junto con el código generado.

Un Catch-22, en otras palabras: según él no puedes escribir una especificación rigurosa para un problema que aún no entiendes, y el entendimiento llega mientras construyes. Rastrea la idea hasta Fred Brooks, cuarenta años atrás: "las descripciones de una entidad de software que abstraen su complejidad a menudo abstraen su esencia."

Dónde discrepan — y por qué te importa​

En una pregunta estos dos están en oposición directa.

Böckeler, generando código repetidamente a partir de una especificación de Tessl: "He visto el no determinismo en acción… un ejercicio interesante iterar sobre la especificación y hacerla cada vez más específica para aumentar la repetibilidad de la generación de código."

Punnen: "Esto no es un problema mayor en la práctica. Los frameworks de SDD actúan como prompts estructurados, y los modelos modernos producen salidas muy consistentes cuando son guiados por ellos."

GitHub se pone del lado de Punnen y va más lejos, afirmando "Consistencia entre LLMs: modelos de IA diferentes producen código arquitectónicamente compatible." No el mismo modelo dos veces — modelos diferentes. Sin evidencia ofrecida.

Dos ingenieros experimentados, conclusiones opuestas, una afirmación de proveedor más fuerte que cualquiera de las dos, y ni un número entre ellos. Importa más de lo que parece. Mantener una especificación y su código sincronizados — la idea de spec-anchored — depende de pruebas automatizadas que atrapen la deriva. Eso funciona para código determinista, donde la misma entrada da la misma salida.

Apúntalo a una funcionalidad de LLM y la verificación deja de funcionar. assert response == expected no significa nada cuando la respuesta difiere en cada ejecución. A menos que cambies pruebas por evaluaciones, donde cada criterio de aceptación se convierte en una afirmación puntuada: ¿clasificó correctamente, devolvió JSON válido contra el esquema, se negó cuando debía?

Ese puente sobrevive al no determinismo, y es el arnés que he pasado varios tutoriales construyendo sobre la WEC Inference API. También hace que el desacuerdo sea medible: escribe la especificación, convierte sus criterios en afirmaciones de evaluación, y ejecútalas a lo largo de una sesión larga para ver si la adherencia se mantiene o decae.

Ese es el siguiente post.

Si vas a probarlo​

Las conclusiones prácticas de Punnen son mejores que cualquier cosa que yo inventara, y se las ganó:

• Trata las reglas de "sin dependencias nuevas" como sesgos, no como neutrales. Si la respuesta correcta necesita una dependencia, vas a tener que defenderla — el framework no lo hará.
• Trata los criterios de éxito generados como adivinanzas hasta que un ingeniero los ratifique. El agente te los va a citar después como si estuvieran medidos.
• Lee cada menú de aclaración como una propuesta de diseño disfrazada. Si la opción que quieres no está listada, ese es el fallo — no una invitación a elegir la mejor de tres.
• Presiona durante la aclaración, no durante el plan. Los planes son largos, internamente consistentes, y agotadores de revisar.

Una mía: escribe tus principios con una fecha y una justificación, para que un tú posterior pueda reemplazarlos. IBM sugiere tratar las especificaciones como "artefactos versionados apilables, como registros de decisiones de arquitectura" — y un ADR es algo que puedes marcar como reemplazado. La metodología llama a estos principios inmutables. Tu problema no lo es.

Añade la prueba de costo de IBM, la línea práctica más afilada que escribió cualquiera de ellos: el costo de refinar la especificación debería ser siempre menor que el costo de arreglar malentendidos en la implementación. Cuando ese equilibrio se invierte, deja de pulir y empieza a construir.

Y revisa la organización antes de instalar. El repositorio que circula en LinkedIn es un fork con once estrellas; el proyecto real es github/spec-kit. Eso importa más aquí que en la mayoría de herramientas: el trabajo de Spec Kit es escribir archivos de instrucciones que tu agente después obedece, y en la primera ejecución apruebas esa carpeta con una tecla sin haberlos leído.

Entonces, ¿reemplaza al vibe coding? No de la forma que sugiere el argumento de venta. No ayuda cuando no entiendes tu problema — ayuda cuando lo entiendes y lo comunicas mal. Esos son fallos diferentes, y solo uno de ellos tiene plantilla.

Ambos encontraron valor real en las fases iniciales — Punnen califica el paso de aclaración como el más útil de todos — y ambos encontraron que los artefactos se veían más autoritativos exactamente donde las decisiones debajo de ellos eran más arbitrarias. Punnen: "son más peligrosos cuando parecen más rigurosos."

Böckeler recurre a una palabra compuesta alemana para describirlo — Verschlimmbesserung. Empeorar algo en el intento de mejorarlo.

La parte difícil nunca fue escribir el código.

Un agente serio, sin necesidad de centro de datos

La mayoría de los anuncios de modelos "ejecutarlo localmente" vienen con un asterisco: más pequeños, más débiles, una versión de juguete de la cosa real. El lanzamiento más reciente de Meta no lo tiene: Muse Glimmer, un modelo multimodal de 30B construido específicamente para trabajo agentic, cabe en una sola GPU de consumo y supera a modelos más grandes en los benchmarks que realmente miden el comportamiento de los agentes.

Arquitectura​

Muse Glimmer tiene 30B parámetros en total: un codificador de visión estilo ViT de 2B acoplado a un decodificador de texto de 28B parámetros, 52 capas de transformadores utilizando un patrón de atención híbrido. Se destila del modelo más grande de Meta, Muse Spark: la capacidad de un modelo más grande, comprimida en algo que una sola GPU puede contener. Los datos de entrenamiento abarcan más de 100 idiomas, con un corte de conocimiento del 4 de enero de 2026.

Comprensión multimodal​

• Texto, imagen y video — comprensión de video de hasta 96 fotogramas a 2 fps (sin pista de audio procesada).
• Detección de objetos abierta — puede localizar e identificar objetos en una escena sin un conjunto de etiquetas predefinido, en lugar de solo reconocer una lista de categorías fijas.
• Ventana de contexto de 131K+ tokens, lo suficientemente larga para sesiones de agentes extendidas o documentos grandes sin fragmentación externa.

Uso de herramientas agentic​

La característica principal: llamada a herramientas multimodal con salidas estructuradas. Puede mirar una imagen y decidir qué función llamar según lo que ve, no solo analizar instrucciones de texto — por ejemplo, inspeccionando una captura de pantalla y llamando a la API correcta según lo que se renderiza, no una descripción textual de ello. También genera y ejecuta código, y está construido con un comportamiento de recuperación de fallos explícito en lugar de asumir que cada llamada a la herramienta tiene éxito en el primer intento.

Ejecución local​

• Cabe en una GPU de consumo — variantes cuantizadas funcionan en 24–32GB de VRAM.
• Soporte Day-0 en transformers, llama.cpp, vLLM, y Puntos de Inference — sin esperar a puertos comunitarios.
• Decodificación especulativa DFlash — hasta 3x más rápida en hardware compatible.
• No se requiere un viaje de ida y vuelta a la nube para ninguno de los anteriores; todo funciona en la máquina que posees.

Licenciamiento​

Apache 2.0 — sin restricciones de uso comercial, sin requisito de atribución, sin negociación de licencia separada para ejecutarlo en un producto. Vale la pena decirlo claramente porque no es algo dado en este momento: algunos modelos agentic de peso abierto recientes tienen restricciones de uso comercial que solo aparecen una vez que lees el texto de la licencia detenidamente. Este no las tiene.

Meta también realizó evaluaciones de seguridad para riesgos químicos/biológicos, ciberseguridad y pérdida de control — todos calificados como "moderados o inferiores".

Cómo se compara​

Los propios números publicados de Meta, contra Gemma4-31B y Qwen3.6-27B:

No es una barrida limpia: Qwen3.6 lo supera en SWE-Bench Verified — pero contra Gemma4 la diferencia es amplia, y contra Qwen3.6 es competitivo o superior en la mayoría de los benchmarks específicos de agentic. (Números de anuncio de Muse Glimmer de Meta; los benchmarks son direccionales, no evangelio.)

Por qué es importante​

La historia de la IA autoalojada siempre ha tenido un impuesto silencioso: los buenos modelos agentic necesitaban infraestructura real, por lo que "ejecutarlo tú mismo" a menudo significaba "ejecutar una versión peor de ello tú mismo". Un modelo que está genuinamente construido primero para agentes, se envía con licencia permisiva y cabe en hardware que una sola persona puede poseer es el cierre de la brecha en tiempo real: la misma tendencia en la que toda esta serie de tutoriales ha estado apostando.

¿Está en WEC?​

Aún no — y no vamos a pretender lo contrario. Lo estamos ejecutando a través de nuestra propia suite de evaluación de modelos ahora, la misma que evalúa todo lo que ya está en WEC Models, antes de que gane un lugar en el catálogo. Si se mantiene frente a lo que ya está allí, espéralo pronto.

📖 Fuentes: anuncio de Muse Glimmer de Meta (Hugging Face) · Tarjeta del modelo

Bucles, gráficos y el obituario de seis semanas

En junio de 2026, el mundo de la IA obtuvo una nueva palabra de moda: ingeniería de bucles — aproximadamente, el diseño disciplinado de un bucle de llamada a herramientas de un solo agente. Seis semanas después, supuestamente fue reemplazada por ingeniería de gráficos — conectando varios agentes a la vez — asesinada por doce palabras que 3.1 millones de personas vieron:

¿No sabes qué es la ingeniería de bucles? No te preocupes — la mayoría de las personas que la declararon muerta tampoco lo sabían. Aquí están ambos términos, cómo un nombre se convirtió en un obituario en seis semanas, y el giro que nadie verificó antes de escribir sobre ello.

La división se muestra mejor en un trabajo con trabajo independiente que puede ejecutarse a la vez y donde una respuesta incorrecta es costosa — un informe de investigación: "Reúne lo que sabemos sobre X — la web abierta, nuestra propia documentación y el repositorio — y dame un informe de una página con fuentes."

El agente OpenClaw que configuras en estos tutoriales funciona de la manera de bucle — un agente ciclando a través de sus herramientas, un turno a la vez. La ingeniería de gráficos conecta a un equipo de especialistas en su lugar. Mismo trabajo, dos formas:

Lee el bucle a la izquierda como una rueda: un agente visita cada herramienta, luego vuelve. Empújalo más allá de tareas simples y aparecen dos grietas: es lento (tres búsquedas independientes aún se ejecutan una tras otra, un trabajador a la vez), y es difícil de confiar (el mismo agente buscó, leyó y escribió el informe, así que una afirmación incorrecta no tiene dirección — no puedes saber si la búsqueda fue superficial o si el agente la inventó).

El gráfico a la derecha soluciona ambos problemas: los especialistas dividen el trabajo, un planificador lo dirige. Las búsquedas ahora se inician al mismo tiempo — el informe llega en el tiempo de la más lenta, no la suma — y cada agente posee una fuente, por lo que una mala afirmación tiene una dirección. Un nodo de verificación de hechos, el paso que un bucle apresurado omite, se convierte en una verdadera puerta.

Nada de eso es gratis: un aviso se convierte en un planificador, cuatro agentes y un verificador — un nuevo modo de fallo donde la coordinación misma puede romperse. Problema de confianza cambiado por un problema de plomería. Y cada caja en el gráfico aún ejecuta su propio bucle interno: un gráfico contiene bucles — ese es el punto.

Ambos términos, en una imagen​

La ingeniería de bucles trata sobre un solo agente. Un agente de IA es solo un modelo en un while loop con herramientas: dale un objetivo, elige una herramienta, tu código la ejecuta, el resultado vuelve a entrar, repite. ChatGPT respondiendo a una pregunta es una llamada. Un agente que edita un archivo, ejecuta las pruebas, las ve fallar y vuelve a intentarlo — ese es el bucle, cinco veces. La ingeniería de bucles es diseñar ese ciclo deliberadamente: qué lo desencadena, quién verifica el trabajo, cuándo se detiene, qué sucede en caso de fallo. El lema es bueno — la inteligencia vive en el modelo, la fiabilidad vive en el bucle.

La ingeniería de gráficos trata sobre varios agentes. Los nodos son agentes, los bordes son dependencias, además del estado compartido y los permisos entre ellos. Si la ingeniería de bucles es "hacer que un agente sea fiable", la ingeniería de gráficos es "hacer que diez agentes no se pisen entre sí."

Diferentes problemas, diferente escala. Así que "la ingeniería de bucles está muerta, la ingeniería de gráficos la reemplazó" nunca fue una frase sensata — es como decir que las ruedas reemplazaron a los coches.

El nombre para el primero llegó en junio de 2026, de Addy Osmani. Se popularizó rápidamente porque todos ya lo estaban haciendo, mal, sin un vocabulario compartido. Recuerda esa fecha.

El libro de texto lo resuelve​

Aquí está la cosa que nadie verificó antes de escribir una guía: "gráfico" no es una invención de 2026, y los recibos están en un libro de texto gratuito del MIT. De Mathematics for Computer Science (6.042J), capítulo 6, página 189 — Definición 6.1.1:

"Un gráfico dirigido G = (V, E) consiste en un conjunto no vacío de nodos V y un conjunto de bordes dirigidos E… Un gráfico dirigido es simple si no tiene bucles (es decir, bordes de la forma u→u) y no tiene bordes múltiples."

La definición formal de un gráfico ya contiene la palabra bucle, como una característica ordinaria de los gráficos — no su opuesto. La definición 6.1.2 añade que un ciclo es un recorrido que regresa a donde comenzó, que es lo que es un bucle.

Un bucle no es el opuesto de un gráfico. Es un gráfico que regresa a un nodo anterior. Las matemáticas han sabido esto desde que Euler caminó por Königsberg en 1736.

Lo que realmente sucedió en julio​

La chispa no fue un descubrimiento de ingeniería — fue dos lanzamientos de productos colisionando. DeepLearning.AI lanzó un curso sobre gráficos de conocimiento con sistemas multiagente, impartido por Andreas Kollegger de Neo4j. Al mismo tiempo, Linear lanzó una función de agente llamada — de todas las cosas — Bucles. Dos empresas, dos productos no relacionados, dos palabras que sonaban como filosofías rivales.

Luego Steinberger, quien construyó OpenClaw, publicó sus doce palabras a las 9:34 PM del 17 de julio. Cuatro horas y media después Hamel Husain publicó un artículo en X titulado "La ingeniería de bucles está muerta. Entra la ingeniería de gráficos," y Santiago Valdarrama lo recogió el mismo día. En 48 horas, el nuevo término tenía tres definiciones en competencia y una ola de publicaciones imitadoras.

La parte que debería haberlo terminado​

Ninguno de los posts fundacionales fue serio — los escritores que rastrearon el ciclo lo dicen abiertamente. Louis-François Bouchard lo expresó claramente: "mi feed entero decidió que tenemos una nueva disciplina. Para ser honesto, ambos tweets eran bromas." El propio seguimiento de Husain solo amplió la broma, prometiendo que el artículo "no es lo que piensas que es."

Y casi nadie pudo verificar: el artículo estaba detrás del muro de pago Premium de X. El texto fundacional de un paradigma era algo que pocos de los que lo citaban habían leído realmente. Lo que se propagó no fue un argumento — fue una forma: un título impactante, una broma justo detrás de él, y una industria que respondió a una broma escribiendo documentación para ello.

Las respuestas fueron más inteligentes que los anuncios​

La respuesta más aguda vino de fuera del grupo de agentes. David Khourshid creó XState — una biblioteca ampliamente utilizada para modelar exactamente este tipo de máquina de estados en código — y ha estado modelando estas estructuras durante una década:

Su explicación toma dos minutos. Una máquina de estados responde a una pregunta — dado el estado actual, cuando ocurre un evento, ¿cuál es el siguiente estado? Dibuja y los estados se convierten en nodos, las transiciones se convierten en bordes. Luego lo aplica al argumento de julio:

"Sorpresa… los bucles son gráficos: dirigidos, cíclicos."

Un bucle, señala, es la máquina de estados más básica que existe: dos estados, looping y done. Publicó un diagrama de ello con el título "Esta es la cosa tonta por la que todos ustedes hicieron hype durante semanas."

Ese es el objeto sobre el que se discutió durante seis semanas. Y los verdaderos agentes — los que vuelven a intentar, retroceden, esperan a un humano — nunca fueron secuenciales y nunca acíclicos desde el principio ("lo siento, amantes de DAG").

El creador de LangChain llegó allí desde la dirección opuesta, su LangGraph siendo la implementación a la que todos seguían apuntando:

Cuatro días después, él y Sydney Runkle publicaron una respuesta más larga, 3 Años de Ingeniería de Gráficos con LangGraph, que es lo más útil escrito durante todo el episodio. Su línea de apertura es la mejor descripción del fenómeno que he leído:

"Es el último término que sale de la fábrica de contenido de IA de X, uniéndose a la ingeniería de prompts, la ingeniería de contexto, la ingeniería de harness y la ingeniería de bucles."

Y luego, de las personas cuyo producto es literalmente el gráfico:

"Los bucles son gráficos simples. La ingeniería de bucles no es una alternativa a los gráficos, sino una versión simple de ellos."

También confirman lo que la mayoría de las publicaciones de julio entendieron al revés: los gráficos de agentes de producción generalmente no son DAGs. Los verdaderos agentes vuelven a intentar, piden información faltante, revisan después de la validación, hacen pausas para un humano. Los ciclos no son un defecto de diseño que deba eliminarse — son el trabajo.

El marco más claro de todos, sin embargo, vino de una respuesta:

Cómo está la situación hoy​

Es 5 de agosto, aproximadamente dos semanas y media después del obituario. Nadie ganó. El debate no se resolvió y no murió — se absorbió en el marketing de contenido. Cada proveedor de infraestructura de agentes ahora tiene una "guía definitiva sobre la ingeniería de gráficos," y detrás de ellos una larga cola de páginas de SEO diciendo lo mismo en el mismo orden.

Nada se aprendió en ese tiempo. No se realizó ningún benchmark, ningún sistema de producción demostró que un enfoque superara al otro. Dos empresas lanzaron productos no relacionados, dos desarrolladores bien seguidos hicieron una broma, y mucha gente acordó una palabra — luego acordaron una palabra diferente.

Eso tiene un costo real. Si intentaste mantenerte al día adoptando cada término a medida que se ponía de moda, reescribiste tu arquitectura dos veces en julio por razones que eran sociales, no técnicas. Mientras tanto, el ingeniero que ignoró ambas publicaciones y pasó ese mes añadiendo reglas de detención y estado tipado salió adelante, porque esas cosas importaban bajo cualquier etiqueta.

El fallo que nadie está vendiendo una guía​

Una idea de este mes merece más atención que la guerra de nombres, y proviene de Towards AI's breakdown: más agentes no significa más juicio.

Veinte agentes ejecutando el mismo modelo, leyendo el mismo contexto defectuoso y verificando contra la misma métrica rota estarán de acuerdo entre sí a escala industrial. Peor es la versión circular: un agente verifica un informe contra otro informe, un agente de auditoría verifica ambos contra un panel de control, y el panel de control se construyó a partir de los mismos datos. Cada nodo está de acuerdo. Nada tocó la realidad. El sistema parece bien gobernado, porque el diagrama tiene revisores en todas partes.

La solución es lo que ellos llaman anclas de realidad — evidencia del exterior del sistema de agentes. Pruebas que realmente se ejecutaron. Dinero que llegó al banco. Clientes que se quedaron. Reglas que el optimizador no puede reescribir silenciosamente. Su línea es la que pondría en la pared:

"Sin anclas, un gráfico es una alucinación más grande con mejor gestión de proyectos."

La misma trampa existe un nivel más abajo, dentro de un solo bucle: si el agente que realiza el trabajo también decide si el trabajo es bueno, has construido una máquina costosa para estar de acuerdo consigo misma. Un verificador solo cuenta si realmente puede fallarte.

Qué hacer realmente​

La línea de Khourshid es el filtro, y no es cinismo: el próximo mes será otra cosa. Cuando llegue el próximo término, la pregunta nunca es "¿es este el nuevo paradigma?" Es "¿qué fallo específico nombra este término, y ya tengo ese fallo?"

Diagnostica dónde está realmente tu cuello de botella:

• Un agente degradándose durante una sesión larga — olvidando, repitiendo llamadas a herramientas, quemando tokens? Ese es un problema de bucle: reglas de detención, qué salida de herramienta vuelve a entrar en el contexto, si los errores se muestran o se tragan. Ningún marco de gráfico soluciona nada de esto.
• ¿Varios agentes duplicando trabajo o bloqueándose en un estado compartido? Ese es un problema de coordinación, y necesita un plano de control explícito, sea cual sea su nombre.

Y un caso para ninguno: si la tarea es genuinamente abierta — investigación, exploración — forzarla en caminos fijos es el movimiento equivocado. El equipo de LangChain hace este punto en contra de su propio producto: construyeron una investigación profunda temprana sobre flujos de trabajo de LangGraph predefinidos y luego se trasladaron a un bucle agente más suelto, y GPT Researcher hizo lo mismo. La estructura que no has ganado te cuesta.

Y cualquiera que tengas, estos sobreviven al vocabulario: cada bucle necesita una regla de detención; el estado necesita una forma y puntos de guardado; los nodos que actúan necesitan límites de permisos y una puerta humana en cualquier cosa irreversible; añade complejidad solo cuando un fallo real lo pida.

Si quieres los dos conceptos que valen la pena en todo esto, toma la recomendación de Khourshid sobre cualquiera del vocabulario de julio: máquinas de estados y el modelo de actores. Ambos preceden este argumento por décadas y sobrevivirán a lo que lo reemplace — probablemente en unas seis semanas.

Fuentes​

• Addy Osmani, nombrando "ingeniería de bucles" (junio de 2026) — X
• Publicación de Peter Steinberger — X
• Hamel Husain, "La ingeniería de bucles está muerta. Entra la ingeniería de gráficos" — Artículo de X, 18 de julio de 2026 (detrás de X Premium) · su seguimiento público
• Santiago Valdarrama — X
• David Khourshid (XState), "Máquinas de estados en 2 minutos" — X
• Harrison Chase (LangChain) — X · Eric Osiu — X
• Louis-François Bouchard, "Ingeniería de gráficos explicada: ¿Qué cambió realmente?"
• "Dos ingenieros hicieron una broma sobre la ingeniería de gráficos. Seis días después tenía cursos." — AI Advances
• SmartScope, sobre si el "obituario" es verdadero
• MIT 6.042J Mathematics for Computer Science, Ch. 6 "Gráficos Dirigidos" (PDF gratuito) — Definiciones 6.1.1–6.1.2, pp. 189–191

El Modelo de Protocolo de Contexto acaba de tener su mayor revisión desde su lanzamiento. La especificación del 2026-07-28 no añade una característica — reescribe cómo cada servidor MCP se comunica con cada cliente. Si has desplegado un servidor MCP en algún lugar más allá de "funciona en mi laptop", este cambio afecta tu infraestructura, no solo tu registro de cambios.

Qué se lanzó realmente​

El cambio principal: MCP ahora es sin estado en la capa de protocolo. Cada solicitud lleva su propia versión de protocolo, identidad del cliente y capacidades — ya no hay más apretón de manos initialize/initialized, no hay ID de sesión, no hay requisito de que la solicitud N+1 llegue a la misma instancia de servidor que manejó la solicitud N. El mantenedor principal David Soria Parra lo llamó "un salto en la prestación de servidores MCP escalables", basado en 18 meses de ejecución de MCP más allá de la etapa de herramienta local.

Ese cambio desbloquea una cadena de cambios prácticos:

• Balanceo de carga simple. Un servidor que antes necesitaba sesiones pegajosas y un almacén de sesiones compartido puede estar detrás de un balanceador de carga ordinario de round-robin.
• Enrutamiento basado en encabezados. Las solicitudes ahora llevan los encabezados HTTP Mcp-Method y Mcp-Name, por lo que las puertas de enlace y los cortafuegos pueden enrutar y limitar la tasa inspeccionando encabezados en lugar de analizar cada cuerpo JSON.
• Resultados de lista cacheables. tools/list, prompts/list, resources/list, y resources/read ahora devuelven ttlMs y cacheScope, para que los clientes sepan cuánto tiempo se les permite omitir la reobtención.
• Solicitudes de Múltiples Viajes (MRTR). El antiguo patrón de entrada de flujo mantenido abierto iniciado por el servidor (confirmaciones, parámetros faltantes) ha desaparecido. Un servidor ahora devuelve resultType: "input_required"; el cliente reintenta la misma llamada con inputResponses completado — no se requiere conexión persistente.

El estado no desapareció, solo se volvió explícito: si tu herramienta realmente lo necesita, crea un identificador y se lo devuelve al cliente para que lo pase en la siguiente llamada, en lugar de ocultarlo en la capa de transporte.

La autorización recibió una reescritura real, no un parche​

Esta es la parte que debería llamar la atención de un ingeniero de IA antes de que lo haga el cambio de protocolo. La autorización de MCP ahora se alinea con OAuth 2.1 y OpenID Connect en lugar de dejar que cada implementador conecte su propia versión, como desglosa WorkOS:

• Los servidores deben implementar Metadatos de Recursos Protegidos de OAuth 2.0 (RFC 9728) para descubrimiento y Indicadores de Recursos (RFC 8707) para que un token creado para un servidor MCP no pueda ser reproducido contra otro.
• La verificación del emisor ahora es obligatoria — los clientes deben verificar el parámetro iss antes de canjear un código, cerrando la clase de errores de confusión del servidor de autorización.
• Los Documentos de Metadatos de ID de Cliente (CIMD) reemplazan el Registro Dinámico de Clientes como la ruta preferida (DCR sigue funcionando, por ahora).

La consecuencia práctica: el problema del "deputado confundido" — una llamada a la herramienta ejecutándose con credenciales destinadas a un servidor diferente — se cierra a nivel de protocolo en lugar de depender de que cada autor de servidor recuerde verificar. Si estás ejecutando múltiples servidores MCP detrás de una puerta de enlace (lo cual, según nuestra propia cobertura de puerta de enlace, es hacia donde todos se dirigen), esta es la parte de la actualización que realmente reduce tu superficie de riesgo, no solo tu carga operativa.

La parte honesta: esto rompe cosas, y los mantenedores lo dicen​

Nada de esto es compatible hacia atrás por accidente. Soria Parra, en el informe de The Register, no lo endulzó: "Si construiste tu propia implementación, va a ser mucho trabajo para corregir esto," y el rediseño sin estado, por su propia admisión, "hace que las cosas en la red sean un poco más complicadas de lo que solían ser" incluso mientras elimina el estado de sesión. Roots, Sampling y Logging están ahora formalmente deprecados — Sampling por semánticas confusas, Roots como "algo muy nicho," Logging por ser excesivamente verboso — con un mínimo de doce meses antes de que realmente sean eliminados, junto con el transporte HTTP+SSE heredado.

Leído con benevolencia, esto es un protocolo madurando: una política de deprecación formal significa que obtienes un año de aviso en lugar de una ruptura sorpresa. Leído con escepticismo — y The Register lo hace — esto está solucionando problemas que solo aparecieron una vez que MCP dejó las herramientas de desarrollo locales para el despliegue en la nube, lo que dice algo sobre cuánta infraestructura de carga se construyó sobre el diseño anterior antes de que alguien lo sometiera a pruebas de estrés a gran escala. Ambas lecturas son verdaderas a la vez. Eso no es una razón para entrar en pánico; es una razón para leer realmente la guía de migración antes de que tus pruebas de integración lo hagan por ti.

Por qué esto importa para ti, específicamente​

Si estás construyendo agentes contra servidores MCP que no controlas, probablemente no notes nada de inmediato — los SDK de Nivel 1 (TypeScript, Python, Go, C#, con Rust en beta) manejan la negociación. Si ejecutas un servidor MCP — para un pipeline RAG, un puente de herramienta interna, cualquier cosa más allá de una demostración — esto cambia tres cosas que posees directamente: cómo se escala (sin estado significa que tu historia operativa se vuelve más simple), cómo se asegura (la alineación con OAuth 2.1 significa menos de tu propio código de autorización que puede estar mal), y tu reloj (doce meses para moverte de Roots, Sampling, Logging y el transporte SSE antes de que desaparezcan). Ninguna de esas cosas es opcional solo porque no solicitaste la reescritura.

📖 Fuentes: Blog del Modelo de Protocolo de Contexto — la especificación del 2026-07-28 · WorkOS — cambios de autenticación en la especificación MCP 2026-07-28 · The Register — MCP rompe con su pasado con estado · VentureBeat — la mayor actualización de MCP, qué cambia para los agentes de IA

La carrera de frontera acaba de cambiar de carril: de más inteligente a más barato por tarea

OpenAI lanzó GPT-5.6 el 9 de julio — una familia de tres modelos (Luna, Terra, Sol) — y la afirmación principal no es una puntuación de tabla de clasificación. Es un número de eficiencia: rendimiento de codificación de frontera en menos de la mitad de los tokens de salida. Si construyes agentes, eso es una afirmación sobre tu factura, no sobre derechos de fanfarronear. También es exactamente el tipo de afirmación que deberías medir tú mismo.

Lo que se lanzó​

Tres niveles, del más barato al más fuerte, disponibles en ChatGPT, Codex y la API de OpenAI:

Las tres variantes incluyen el uso nativo de herramientas y razonamiento multimodal, con evaluaciones de contexto largo que llegan hasta 1M de tokens; Sol también impulsa el nuevo nivel profesional ChatGPT Work. Las afirmaciones que vale la pena conocer (de anuncio de OpenAI — direccional, no evangélica): Sol puntúa 80 en el Índice de Agentes de Codificación de Análisis Artificial, 2.8 puntos por encima del Fable 5 de Anthropic — mientras usa menos de la mitad de los tokens de salida, en menos de la mitad del tiempo, a aproximadamente un tercio del costo estimado — y 88.8% en Terminal-Bench 2.1. En El Último Examen de Agentes, una evaluación de flujos de trabajo profesionales de larga duración en 55 campos, informan que Terra y Luna superan a Fable 5 a alrededor de una dieciseisava parte del costo estimado. La formulación de Sam Altman: Sol es "54% más eficiente en tokens" en tareas de codificación. El lanzamiento también se enfoca fuertemente en ciberseguridad — "rendimiento de frontera con significativamente menos tokens."

Dos características de la API se lanzan bajo la misma bandera de eficiencia, y son la parte más relevante para los desarrolladores del lanzamiento: Llamada de Herramienta Programática, donde el modelo escribe y ejecuta pequeños programas en memoria que coordinan herramientas y procesan resultados intermedios — en lugar de pasar cada respuesta de herramienta de vuelta a través del modelo, de modo que las tareas que requieren muchas herramientas consumen menos tokens y menos viajes de ida y vuelta — y una beta de múltiples agentes en la API de Respuestas (la nueva configuración Sol Ultra ejecuta cuatro agentes en paralelo por defecto).

Una primera más, enterrada en la línea de tiempo: GPT-5.6 estaba planeado para junio y se lanzó tres semanas tarde porque una revisión del gobierno de EE. UU. bloqueó el lanzamiento — el Centro de Normas e Innovación de IA del Departamento de Comercio realizó pruebas adicionales antes de que OpenAI obtuviera permiso para un lanzamiento público. Más sobre por qué eso importa a continuación.

Por qué la eficiencia de tokens es la verdadera historia​

Para el chat, los tokens de salida son un error de redondeo. Para agentes, son la factura: una sesión de codificación de agentes quema tokens en cada paso — planes, diferencias, reintentos, llamadas a herramientas — y los tokens de salida cuestan 5–6× los tokens de entrada en cada tarjeta de precios anterior. Un modelo que resuelve la misma tarea con la mitad de los tokens de salida sería efectivamente la mitad de precio y el doble de rápido con calidad igual, incluso si solo es un par de puntos de referencia mejor. Si se mantiene en tus tareas — y ese "si" es todo el tema de la siguiente sección — eso es un cambio real y bienvenido en lo que los proveedores compiten.

Por eso "54% más eficiente en tokens" es un movimiento competitivo más agresivo que cualquier salto en la tabla de clasificación. Y OpenAI no estaba sola — toda la frontera pasó esta semana compitiendo en precio por tarea: Meta lanzó Muse Spark 1.1 para codificación de agentes a $1.25/$4.25 por 1M de tokens (con $20 de créditos gratuitos por cuenta), y SpaceXAI lanzó Grok 4.5 — coentrenado con Cursor — a $2/$6, comercializado como aproximadamente 6× más barato que modelos de frontera comparables. Incluso las noticias de infraestructura de OpenAI apuntaron en la misma dirección: los ingenieros informaron que redujeron a la mitad los costos de inferencia solo a través de la optimización del software. La carrera ha cambiado visiblemente de carril, de puntos de referencia a costo por tarea.

La escalera de tres niveles importa por la misma razón. El patrón emergente es enrutamiento por dificultad de tarea: nivel barato para clasificación y extracción, nivel medio para generación cotidiana, insignia solo para el trabajo difícil de múltiples pasos. Si ejecutas una puerta de enlace (hemos escrito sobre por qué esa capa importa), esto es para lo que es.

Las afirmaciones de los proveedores son preguntas de evaluación​

Aquí está la cosa sobre "54% más eficiente" y "2.8 puntos por encima": esos números provienen del proveedor, medidos en el banco de pruebas elegido por el proveedor, con el arnés del proveedor. Eso no es una acusación — los números son muy probablemente reales en ese banco de pruebas, y aplicamos el mismo descuento a los de todos, incluidos los modelos de peso abierto que nos gustan (dijimos exactamente esto sobre las tablas de GLM-5.2). Es un punto estructural: ningún banco de pruebas de proveedor puede conocer tu carga de trabajo.

Ni siquiera tienes que salir de la propia tabla de codificación de OpenAI para verlo — y crédito para ellos por publicar las filas mixtas en lugar de solo las halagadoras:

(Números del anuncio de OpenAI.)

Cuatro bancos de pruebas de codificación, y "cuál es el mejor modelo de codificación" cambia dependiendo de la fila — con la brecha más grande apuntando en la otra dirección. Eso no es un golpe a ninguno de los modelos o a la tabla; es lo que son los bancos de pruebas. Si la propia página de un proveedor no puede producir una sola respuesta, un título del día del lanzamiento ciertamente no puede decirte qué sucede en tu base de código. La eficiencia de tokens complica el problema: varía enormemente según la forma de la tarea — un modelo que es conciso en refactorizaciones de Python puede ser verboso en SQL o respuestas largas, y un arnés de agente diferente al del proveedor puede borrar (o amplificar) toda la ventaja.

La buena noticia: este es un problema resuelto, y ya tienes las herramientas si seguiste nuestra serie de evaluaciones. La misma configuración de Promptfoo de parte 1 compara cualquier par de puntos finales compatibles con OpenAI en tus prompts — con aseveraciones de costo y latencia, no solo calificaciones de calidad. Y el enfrentamiento que vale la pena ejecutar esta semana no es GPT-5.6 contra su propia tabla de lanzamiento — es GPT-5.6 contra el modelo de peso abierto más fuerte que puedes servirte a ti mismo:

providers:
  - openai:chat:<new-model-id>          # el retador del que todos están hablando
  - id: openai:chat:gemma4              # el modelo de peso abierto ya en WEC
    config:
      apiBaseUrl: https://inference.wiline.com/v1
      apiKeyEnvar: WEC_API_KEY
defaultTest:
  assert:
    - type: latency
      threshold: 5000
    - type: cost
      threshold: 0.002

Los mismos prompts, ambos modelos, y la evaluación informa calidad, tokens, latencia y costo uno al lado del otro. Una tarde de esto te dice lo que ningún post de lanzamiento puede: si la afirmación de eficiencia sobrevive el contacto con tu tráfico. (Y si el modelo respalda un servicio RAG o agente, constrúyelo como lo hicimos nosotros en el proyecto final — juzga por semántica, regresiones determinísticas para errores conocidos.)

El subtexto: la portabilidad acaba de volverse más valiosa​

Dos cosas sucedieron alrededor de este lanzamiento que importan más juntas que por separado.

Primero, la puerta de gobierno: por primera vez, el lanzamiento público de un modelo de frontera necesitó una revisión federal para proceder — y la preocupación no era abstracta. La misma semana, Sysdig documentó JadePuffer, la primera operación de ransomware de agente de IA completamente autónoma, que explotó un CVE de Langflow y luego realizó reconocimiento, movimiento lateral y extorsión por su cuenta, recuperándose de intentos fallidos en segundos. Cualquiera que sean tus políticas, el hecho de ingeniería es que el acceso a modelos de frontera cerrados ahora tiene una válvula más que no controlas — junto con precios, deprecaciones y límites de tasa. Hicimos este argumento cuando un modelo de peso abierto rompió el top 10 propietario; este lanzamiento lo hizo por nosotros.

En segundo lugar, el mundo de peso abierto también tuvo una semana ruidosa: Google lanzó Gemma 4, una familia de peso abierto, nativamente multimodal de 2.3B a 31B de parámetros (variantes densas y MoE, entrada de visión y audio, un modo de pensamiento); Mistral abrió acceso anticipado a una nueva familia de Mixture-of-Experts de peso abierto dirigida directamente al vacío de frontera; y Together AI cerró una Serie C de $800M con una valoración de $8.3B gracias a la inferencia de modelos abiertos — citando más de $1B al año en reservas. El dinero está diciendo lo mismo que la demora de GPT-5.6 está diciendo: los modelos que puedes descargar y ejecutar son una cobertura que vale la pena pagar.

La conclusión — y algo que puedes probar hoy​

La conclusión para los desarrolladores es la misma que ha mantenido toda la serie: mantén la elección del modelo como un cambio de configuración. Codifica contra la API compatible con OpenAI, coloca una puerta de enlace al frente, y cambiar modelos — cerrados, abiertos, o lo que sea que llegue al catálogo de Modelos de WEC siguiente — es una edición de URL base y ID de modelo, no una reescritura. No ofrecemos GPT-5.6 en WEC hoy; el punto es que si construyes de manera portátil y evalúas antes de migrar, ese hecho te constriñe exactamente cero.

Porque aquí está la trampa en cada semana de lanzamiento: nuevo comienza a sentirse como una razón. No lo es — es una hipótesis. La pregunta que tu evaluación debería responder es si el brillante modelo cerrado supera a un modelo de peso abierto que controlas — en tus prompts, dentro de tu presupuesto de latencia, por dólar — por suficiente como para valer la válvula en la que está la mano de otra persona. A veces lo hará, y entonces cambias con evidencia en lugar de hype. Y a veces el modelo abierto mantiene la línea en las tareas que realmente ejecutas, y acabas de ahorrarte una migración y una dependencia en una tarde.

Puedes ejecutar ese experimento hoy, porque Gemma 4 — la familia de peso abierto, nativamente multimodal que Google lanzó esta misma semana — ya está activa en la inferencia de WEC. Y es un contraparte seria, no un premio de consolación. Lo que Gemma 4 aporta a la mesa:

• Nativamente multimodal — comprensión de imagen y audio en un modelo abierto, por lo que capturas de pantalla de documentos, formularios escaneados y grabaciones de llamadas pasan por el mismo punto final que tus prompts de texto.
• Variantes de pensamiento para las cadenas más difíciles de múltiples pasos — el mismo intercambio de "gastar tokens para razonar" que GPT-5.6 está vendiendo, en pesos que controlas.
• Una escalera de tamaño propia (tamaños E2B/E4B hasta 31B) — el mismo patrón de enrutamiento por dificultad de arriba, sin un contrato de proveedor por nivel.
• 140+ idiomas, y bancos de pruebas de proveedores que colocan el 31B en compañía de frontera — Google afirma un rendimiento comparable a modelos 10–30× más grandes. Se aplica el mismo descuento que a los números de OpenAI, y la misma herramienta lo resuelve: ponlo en la evaluación.

Un cambio de ID de modelo y estás en ello:

curl https://inference.wiline.com/v1/chat/completions \
  -H "Authorization: Bearer $WEC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "model": "gemma4", "messages": [{"role":"user","content":"Resume este informe de incidentes…"}] }'

El impulso de eficiencia de tokens de GPT-5.6 es una buena noticia para todos — incluso si nunca envías a OpenAI una sola solicitud, arrastra a todo el mercado hacia la honestidad en los precios. Toma lo positivo al pie de la letra, toma los números como hipótesis, y deja que tu propia evaluación — GPT-5.6 de un lado, Gemma 4 en WEC del otro — tome la decisión.

📖 Fuentes: OpenAI — anuncio de GPT-5.6 · Google DeepMind — Gemma 4 · TechCrunch — OpenAI lanza GPT-5.6 · CNBC — lanzamiento público después de límites gubernamentales · Axios — GPT-5.6 y ChatGPT Work · Engadget — tiempo de lanzamiento · TechTimes — acceso anticipado de Mistral a MoE de peso abierto · Asanify — ronda de $800M de Together AI · NLPlanet — boletín semanal de IA, 13 de julio (Muse Spark 1.1, Grok 4.5, Gemma 4, JadePuffer, artículos de costo de inferencia)

Un modelo de pesos abiertos acaba de meterse en el top 10 propietario

Mira casi cualquier ranking de modelos actual y la cima es un muro de Anthropic y OpenAI. Y luego, dentro del top 10, hay un caso aparte que no es propietario en absoluto: GLM-5.2 de Z.ai — pesos abiertos, licencia MIT. Esa es la historia que vale la pena mirar.

Dónde está parado​

En el ranking de agentes de Arena.ai, GLM-5.2 (Max) aparece en el #10 — el único modelo de pesos abiertos en el top 10, rodeado por completo de modelos de frontera cerrados de Anthropic y OpenAI. (Los rankings se mueven; esto es una foto del momento — revisa el ranking en vivo.)

Ese es el titular: no que encabece la tabla, sino que un modelo con licencia MIT que puedes descargar, autoalojar y enviar comercialmente ya esté midiéndose con modelos que solo puedes alquilar.

Qué es GLM-5.2 en realidad​

• Pesos abiertos, licencia MIT — sin límites regionales; descárgalo, autoalójalo, haz fine-tuning y úsalo en un producto comercial (pesos en Hugging Face).
• Un sólido contexto de 1M tokens (~750k palabras), pensado para tareas de agente de largo horizonte. Su nueva atención IndexShare reutiliza un mismo indexer cada cuatro capas dispersas — Z.ai reporta ~2,9× menos FLOPs por token con 1M de contexto, que es lo que mantiene esa ventana asequible de correr.
• Dos niveles de esfuerzo de razonamiento (High / Max) para cambiar latencia por profundidad — Max para código complejo de varios pasos, High para trabajo más liviano y rápido.
• API compatible con Anthropic/OpenAI — conéctalo a Claude Code, OpenClaw, Cline y otros con un cambio de base-URL + model-ID; tu harness y tus prompts quedan intactos.

Cómo se compara​

Los benchmarks publicados por Z.ai ponen a GLM-5.2 codo a codo con la frontera cerrada en código, y por delante en algo de razonamiento:

Le gana a Opus 4.8 en Terminal-Bench, a GPT-5.5 en FrontierSWE, a ambos en AIME, y queda por detrás de Opus en SWE-bench Pro — notablemente cerca para un modelo que simplemente puedes descargar. (Cifras de los benchmarks de GLM-5.2 de Z.ai; los benchmarks son orientativos, no dogma.)

Por qué importa​

La brecha entre los modelos de pesos abiertos y la frontera propietaria se ha venido cerrando todo el año. Lo que cambió son los términos: con licencia MIT y una API limpia, GLM-5.2 es algo que puedes poseer y desplegar, no solo invocar. Cuando el acceso a los modelos cerrados puede cambiar de un día para otro por controles de exportación o precios, un modelo de pesos abiertos con calidad de top 10 es una base que no se mueve.

Córrelo en WiLine Edge Cloud​

No necesitas una cuenta de terceros para probarlo — GLM-5.2 está disponible en WiLine Edge Cloud a través de WEC Models, nuestra inferencia compatible con OpenAI. Apunta cualquier herramienta compatible al endpoint de inferencia de WEC y usa GLM-5.2 como modelo:

curl https://inference.wiline.com/v1/chat/completions \
  -H "Authorization: Bearer $WEC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "model": "glm-5.2", "messages": [{"role":"user","content":"Refactor this for performance…"}] }'

Si seguiste la serie de Self-hosting OpenClaw, este es el siguiente paso natural: conserva tu agente, cambia el modelo — apunta OpenClaw a GLM-5.2 en WEC en vez de a un proveedor cerrado, y estarás corriendo un modelo de top 10 que controlas por completo.

📖 Fuentes: ranking de agentes de Arena.ai · GLM-5.2 en Hugging Face · docs del modelo de Z.ai · reporte técnico de GLM-5 (arXiv)

El ecosistema de IA está atravesando, en silencio, la misma transición que vivió la infraestructura web hace años: las piezas críticas para el rendimiento se están moviendo de runtimes interpretados a lenguajes de sistemas como Rust. Que LiteLLM reescriba su gateway de IA en Rust es la evidencia más clara hasta ahora — y una señal de que el stack de IA está madurando de experimento a infraestructura de producción.

El gateway se está volviendo infraestructura crítica​

LiteLLM es el proxy de código abierto que muchos equipos colocan frente a sus modelos para obtener un único endpoint compatible con OpenAI sobre 100+ proveedores. Si alguna vez corriste uno en producción, esta frase del anuncio te resultará familiar:

Bajo carga real, la CPU y la memoria suben con la concurrencia, y los pods reciben OOM-kill en el peor momento.

Ese es el impuesto silencioso de un gateway: está en la ruta crítica de cada solicitud — cada completion, embedding, llamada de moderación y acción de agente pasa por ahí — así que su sobrecarga y su huella de memoria se multiplican entre pods y regiones. Durante años las conversaciones de IA giraron en torno a la calidad del modelo. A medida que los equipos llevan agentes, RAG y enrutamiento multi-modelo a producción, la capa frente al modelo se convierte en una preocupación de infraestructura de primer nivel. Moverla a Rust es cómo se ve esa realización en código.

Los números​

De los benchmarks publicados por LiteLLM (reproducibles — el harness viene con el post):

Esto mide la ruta de reenvío del gateway (transformar → reenviar → manejar la respuesta), no una carga de producción completa — pero esa es justamente la capa que no quieres que consuma CPU y memoria bajo concurrencia.

La verdadera victoria es la memoria, no la latencia​

La mayoría se fijará en los 150× menos de sobrecarga. Pero para cualquiera que opere un gateway, el número más consecuente es 11× menos memoria: 359 MB → ~32 MB. La latencia es una mejora por solicitud; la memoria es lo que mueve tu factura y tu fiabilidad.

Un gateway que ocupa ~32 MB en vez de ~359 MB cambia la matemática operativa en todos los frentes:

• Dimensionamiento en Kubernetes — pods más pequeños, mayor densidad por nodo.
• Costo de nube — esa huella se multiplica por cada pod, región y réplica que corres.
• Autoescalado — memoria más baja y predecible significa menos vaivén de escalado.
• Caídas por OOM — el modo de fallo que te tumba en el pico prácticamente desaparece.

Cuando un componente está en la ruta crítica de cada solicitud, recortar un orden de magnitud en su memoria compone a escala mucho más que la cifra de latencia del titular.

Un despliegue de bajo riesgo​

Esto no es un v2 ni una reescritura a la que tengas que migrar. Los archivos de configuración, el esquema de base de datos, las APIs de cliente y la cobertura de proveedores siguen igual. Lo están moviendo en etapas cuidadosas — primero un núcleo puro en Rust vía bindings PyO3 (transformación de datos, sin I/O), luego el servidor completo sobre axum/hyper — y cada ruta pasa a producción detrás de pruebas de paridad antes de empezar la siguiente:

El registro a la beta ya está abierto; la hoja de ruta apunta a las rutas de OCR para mediados de agosto de 2026, /chat/completions y /messages para septiembre, y el servidor completo para el 1 de diciembre de 2026.

Qué significa para quienes construyen IA​

Para los desarrolladores que construyen sobre WiLine Edge Cloud, el gateway está justo entre tus aplicaciones y tus modelos — así que un gateway más liviano y rápido se traslada directo a las apps que entregas:

• APIs de IA más rápidas. Menos sobrecarga del proxy significa respuestas más rápidas donde la latencia del modelo ya es baja — embeddings, reranking, moderación, clasificación. En esas cargas el gateway era el impuesto; ahora casi no lo es.
• Mejor fiabilidad. Menos presión de memoria reduce los OOM kills, los fallos de solicitudes y el vaivén de autoescalado — las cosas que erosionan en silencio el uptime de un producto de IA en producción.
• Despliegues multi-modelo más eficientes. Si enrutas tráfico entre muchos proveedores, el costo del gateway deja de escalar tan agresivamente con el tráfico — sirves más sin que tu flota de proxies se infle.
• Cimientos de infraestructura más sólidos. A medida que las apps de IA se vuelven sistemas de producción y no experimentos, las capas de infra debajo importan tanto como la calidad del modelo.

Si seguiste la serie de OpenClaw, ya pusiste algo con forma de gateway en la ruta crítica — un proxy inverso, un enrutador de modelos, un runtime de agentes. La lección se generaliza.

La lección de fondo​

Durante años, la mayor parte de la conversación sobre IA se centró en la calidad del modelo. Pero a medida que las organizaciones despliegan agentes, sistemas de recuperación y flujos multi-modelo en producción, la capa frente a tus modelos es infraestructura — y cada milisegundo y megabyte en la ruta crítica compone a escala. El movimiento de LiteLLM a Rust refleja una realización más amplia de la industria: la eficiencia de la infraestructura ya no es una nota al pie del rendimiento del modelo, es parte de él.

Vale la pena observarlo, todavía no cambiar: está en beta y el proxy en Python no va a ninguna parte. Pero la dirección del viaje es clara.

📖 Lee el anuncio completo — los benchmarks, el plan de migración ruta por ruta y los diagramas de arquitectura valen tu tiempo: LiteLLM — Building the fastest AI gateway in Rust.