Claude Code 2.1.144, Cursor Composer 2.5, Stainless, Notion, Vercel AI SDK y Cloudflare Mesh

[00:00] Apertura sobre los cambios en Claude Code CLI Claude Code CLI 2.1.144 es la versión que primero hay que revisar porque apunta a las superficies exactas donde fallan los agentes desatendidos: sesiones en segundo plano y desenganchadas, comportamiento de inicio en redes degradadas, transporte MCP e higiene de llamadas de herramientas. Las correcciones principales son concretas. El bloqueo de inicio de hasta setenta y cinco segundos cuando el endpoint de API no era accesible detrás de un portal cautivo, firewall o VPN se ha eliminado, porque las llamadas de canal lateral ahora tienen un tiempo de espera de quince segundos. Los servidores MCP que paginan su lista de herramientas ya no devuelven solo la primera página. Las imágenes MCP con tipos MIME no soportados se guardan en disco en lugar de romper la conversación. Las sesiones en segundo plano obtienen soporte de reanudación y notificaciones de finalización con duración transcurrida, y el selector de modelo ahora tiene alcance de sesión con un valor predeterminado separado.

Esta es una versión de mantenimiento, y ahí está el punto. El trabajo está en los modos de fallo: un agente desenganchado que debería seguir ejecutándose, una lista de herramientas silenciosamente truncada, una imagen que rompió una conversación, una sesión reanudada que eligió el modelo incorrecto. Después de la lectura del lanzamiento, el episodio cubre cinco movimientos más relevantes para constructores: Cursor Composer 2.5 como un modelo de codificación de horizonte largo más económico, Anthropic adquiere Stainless y trae la generación de código SDK internamente, Notion convierte su espacio de trabajo en un entorno de ejecución de agentes alojado, el Vercel AI SDK reescribe su adaptador de LangChain y LangGraph, y Cloudflare Mesh pone la red de confianza cero bajo el ciclo de vida del agente.

[02:30] Lectura del lanzamiento de Agent-stack — Claude Code CLI 2.1.144 Comenzamos con el bloqueo de inicio, porque es el ejemplo más claro de una corrección que importa más para agentes que para usuarios interactivos. Cuando el endpoint de API no era accesible, la CLI podía bloquearse hasta setenta y cinco segundos antes de hacer algo útil. Un humano lo nota y espera. Una ejecución de agente desatendido, un trabajo programado o una sesión en segundo plano en una red inestable convierte eso en un bloqueo, un tiempo de espera o una ventana perdida. La corrección limita las llamadas de canal lateral a quince segundos. La lección para constructores es que la resiliencia de inicio en redes degradadas es una propiedad de confiabilidad del agente, no algo cosmético.

Las correcciones de MCP son el segundo bloque importante. Los servidores MCP con respuestas de lista de herramientas paginada anteriormente devolvían solo la primera página, lo que significa que un agente podría estar silenciosamente faltándole herramientas que se suponía debía tener. Eso es un error silencioso de corrección: nada falla, el agente simplemente no puede hacer algo que debería poder hacer, y la ejecución parece un fallo de razonamiento en lugar de un error de transporte. El lanzamiento también evita que las imágenes MCP con tipos MIME no soportados, como SVG, rompan la conversación; la imagen se guarda en disco y se referencia en su lugar. Y el comando MCP list ahora reporta el problema real cuando un archivo de configuración no puede ser analizado, en lugar de mostrar silenciosamente que no hay servidores.

Las sesiones en segundo plano y desenganchadas reciben la mayor cantidad de correcciones individuales, lo que te dice dónde ha estado el verdadero dolor operacional. Las sesiones en segundo plano ahora soportan reanudación y muestran duración transcurrida al completarse. Se corrigió el bloqueo de sesiones en segundo plano en macOS cuando el proyecto está bajo una carpeta protegida con Acceso Total al Disco. El desplazamiento, la rueda del mouse y la navegación en sesiones en segundo plano adjuntas en Windows ahora funcionan, y cerrar la terminal mientras está adjunta ya no causa bloqueo. Las sesiones reanudadas mantienen el modelo que estaban usando en lugar de heredar la elección de otra sesión. Edit y Write ya no rechazan con un error de aislamiento de árbol de trabajo justo después de desenganchar. Respawn ya no reporta incorrectamente una sesión en ejecución como detenida, y un fallo breve al despertar ya no se marca permanentemente como un bloqueo de inicio. Juntos, estos cambios hacen que el ciclo de vida de desenganchar, ejecutar, despertar, re-spawn y reanudar sea algo que un constructor puede poner un supervisor alrededor.

La higiene de llamadas de herramientas es la cuarta área. Las vistas de head y tail ahora satisfacen la verificación de leer-antes-de-editar, y los resultados vacíos de grep, git grep o git diff ya no se reportan como fallos de herramientas. Los errores falsos de herramientas no son gratuitos: un agente que piensa que una búsqueda exitosa sin coincidencias falló reintentará, cuestionará o tomará un peor camino. Eliminar fallos espurios elimina comportamiento espurio del agente y turnos desperdiciados. El selector de modelo ahora tiene alcance de sesión, con un valor predeterminado separado para nuevas sesiones, por lo que cambiar el modelo para una tarea no cambia silenciosamente en todas partes, incluyendo para usuarios de Bedrock y Vertex que seleccionan una opción Opus de contexto largo.

La postura práctica de actualización es instalar 2.1.144 y luego ejercitar las superficies cambiadas en lugar de asumirlas. Inicia una sesión en segundo plano, desengánchala, despiértala, reanúdala y confirma que mantiene su modelo. Ejecuta un servidor MCP que pagina su lista de herramientas y confirma que el conjunto completo es visible. Alimenta un tipo de imagen no soportada a través de una herramienta MCP. Ejecuta en una red donde el endpoint de API está brevemente no accesible y confirma que el inicio ya no se bloquea. El lanzamiento solo tiene valor si los modos de fallo que elimina son los que tus agentes realmente estaban encontrando.

[18:00] Cursor Composer 2.5 — un modelo de agente de codificación de horizonte largo más económico Cursor lanzó Composer 2.5 el 18 de mayo, construido sobre una base Kimi K2.5 con post-entrenamiento más pesado y enfocado en sesiones de codificación autónoma más largas. Los números reportados: SWE-Bench Multilingüe subiendo de 73.7 a 79.8 por ciento, Terminal-Bench de 61.7 a 69.3 por ciento, un empate con Opus 4.7 en Terminal-Bench 2.0 mientras va detrás de GPT-5.5, a cincuenta centavos por millón de tokens de entrada y dos dólares cincuenta por millón de tokens de salida. El titular es el precio: aproximadamente una décima parte de Opus 4.7 por token con rendimiento de benchmark de codificación comparable.

El método de entrenamiento es la parte que vale la pena explicar. Cursor reporta tres cambios. Primero, aprendizaje por refuerzo con retroalimentación textual: en lugar de solo una recompensa al final de la ejecución, el modelo obtiene pistas localizadas en llamadas de herramientas fallidas. Para un agente de codificación de horizonte largo, eso es un cambio en la asignación de crédito. Una sola señal de pasa-o-falla al final de una sesión larga le dice al modelo muy poco sobre cuál de las cincuenta llamadas de herramientas fue el error. La retroalimentación textual localizada en el punto de fallo da una señal de aprendizaje mucho más nítida. Segundo, veinticinco veces más tareas sintéticas, incluyendo rompecabezas de reconstrucción con eliminación de características con verdad de tierra exacta. Tercero, infraestructura de entrenamiento a escala MoE usando optimizadores Muon fragmentados y HSDP de doble malla, con la ejecución de aprendizaje por refuerzo dentro de sesiones reales de Cursor usando el mismo harness que usa el modelo desplegado.

Ese último detalle, RL fiel al harness, es el que los constructores no deben skim. El comportamiento de un agente de codificación está moldeado tanto por el harness como por los pesos: cómo se presentan las herramientas, cómo regresan los errores, cómo se recorta el contexto, cómo funcionan los reintentos. Entrenar el modelo en un harness diferente al que se envía introduce una brecha de distribución que se manifiesta como que el modelo se siente peor en producción que en evaluación. Ejecutar RL dentro del harness desplegado cierra esa brecha. El takeaway del constructor es económico: cuando un modelo alcanza benchmarks de codificación adyacentes a la frontera a una décima parte del costo por token, las matemáticas sobre ejecutar muchas sesiones largas cambian, y un patrón de enrutamiento de predeterminado-barato-con-escalación-a-frontera se vuelve atractivo. La precaución es que la paridad de benchmark no es paridad de flujo de trabajo; la prueba real es el costo total por tarea completada en tu propio harness en tu propia distribución de sesión larga.

[28:00] Anthropic adquiere Stainless y trae la generación de código SDK internamente Anthropic anunció el 18 de mayo que adquirió Stainless, la empresa de herramientas de desarrollo cuyo servicio convierte especificaciones de API en SDKs listos para producción y mantenidos automáticamente en Python, TypeScript, Go, Kotlin y Java. Stainless era utilizado por una larga lista de laboratorios de IA y empresas de infraestructura. Anthropic planea discontinuar los productos Stainless alojados, incluyendo el generador de SDK; los clientes existentes mantienen los SDKs ya generados pero pierden acceso futuro al servicio alojado.

La razón por la que esto es una historia del stack de agentes es lo que realmente es un SDK en un sistema de agentes. El SDK es el límite tipado que un agente cruza cada vez que llama a una API externa. Cuando un agente invoca una herramienta que envuelve un servicio, la corrección de esa llamada depende de que el cliente coincida con la API en vivo: los endpoints correctos, formas de solicitud y respuesta, tipos de error y comportamiento de paginación. Un pipeline de generación de código que convierte una especificación en ese cliente, y lo mantiene sincronizado a medida que la especificación cambia, es infraestructura directamente debajo de la capa de herramientas del agente. El modo de fallo es deriva de especificación-a-SDK: un cliente que compila y se ve bien pero silenciosamente no coincide con la API en vivo. Para un humano eso emerge como un reporte de bug; para un agente autónomo emerge como una llamada de herramienta devolviendo algo inesperado que el agente luego razona incorrectamente. Para equipos que dependían del generador alojado, la elección es generadores OpenAPI de código abierto, SDKs de proveedores, o envolver la API detrás de un contrato interno estable como un servidor MCP, y el patrón del constructor es fijar la versión de la especificación, diffing de la especificación en vivo en un calendario, y tratar la deriva como una alerta en lugar de un descubrimiento hecho cuando un agente comienza a comportarse de manera extraña.

[36:00] La Plataforma de Desarrolladores de Notion convierte el espacio de trabajo en un entorno de ejecución de agentes alojado Notion lanzó su Plataforma de Desarrolladores el 13 de mayo. El cambio es que el espacio de trabajo se convierte en un lugar donde los agentes se ejecutan, no solo un lugar donde leen. Workers es un sandbox de código alojado sin servidores que aprovisionar. La API de Agente Externo permite que agentes de terceros como Claude Code, Cursor y Codex actúen como participantes de primera clase del espacio de trabajo. Database sync mantiene sistemas externos de registro actualizados dentro de Notion sin infraestructura. Webhooks bidireccionales permiten que un Worker reciba un evento, ejecute lógica y actúe de vuelta en Notion o llame a otras APIs. Un CLI maneja autenticación, despliegue de Worker y automatización desde la terminal.

La pieza técnicamente interesante para constructores es herramientas deterministas de Worker. En lugar de una llamada de herramienta mediada por LLM, un agente personalizado puede invocar un Worker que ejecuta código predecible con ejecución eficiente en tokens. Ese es el patrón correcto cuando un paso necesita determinismo y lógica personalizada que una llamada mediada por modelo no puede garantizar. El tradeoff a razonar es el límite de confianza: ejecutar agentes de terceros y código personalizado dentro de un espacio de trabajo que contiene datos reales de la empresa significa que el modelo de gobernanza — confianza progresiva, revisión humana, ejecución en sandbox, visibilidad de actividad unificada — está haciendo trabajo estructural, no decoración. Los constructores deben tratar la API de Agente Externo como una superficie de integración multivendor y el límite de confianza como algo a diseñar, no heredar.

[42:00] Vercel AI SDK reescribe su adaptador de LangChain y LangGraph La reescritura del adaptador @ai-sdk/langchain importa porque la mayoría de los equipos no ejecutan un framework de extremo a extremo. Prototipan en uno, despliegan en otro, y necesitan que los formatos de mensaje y stream interoperen sin pegamento escrito a mano. El nuevo adaptador proporciona toBaseMessages y convertModelMessages para convertir objetos de mensaje de AI SDK al formato LangChain BaseMessage, y toUIMessageStream para transformar streams de modelo de LangChain, salida de LangGraph y resultados de streamEvents() al UIMessageStream de AI SDK. LangSmithDeploymentTransport es un ChatTransport que conecta un cliente de navegador directamente a un despliegue de LangSmith o LangGraph sin ruta backend personalizada.

La lente del constructor es interoperabilidad como infraestructura. La normalización de eventos de stream, incluyendo streamEvents() granular para observabilidad y partes de datos personalizados tipadas, es lo que permite que una UI construida en un stack renderice un agente construido en otro sin traducción con pérdida. La abstracción de transporte eliminando el pegamento backend entre un navegador y un grafo desplegado es una reducción real de piezas móviles. Los adaptadores de puente de framework no son una conveniencia; para constructores de agentes de stack mixto son la costura que evita que un stack heterogéneo se fragmente en conectores personalizados.

[46:00] Cloudflare Mesh pone la red de confianza cero bajo el ciclo de vida del agente El empujón de agente-cloud de Cloudflare incluye Mesh, que aplica redes privadas de confianza cero e identidad a cómo los agentes alcanzan servicios y entre sí, además de cambios datados en herramientas de desarrollo como la eliminación del 18 de mayo de la bandera legacy wrangler dev --remote para Durable Objects respaldados por KV. El punto del constructor es que a medida que los agentes pasan de un proceso en una laptop a muchos workers en sandbox llamando servicios internos y externos, la red entre ellos deja de ser un detalle de implementación. Se convierte en una superficie de ataque y un límite de política. La identidad por-agente con credenciales con alcance supera a las claves ambientales compartidas, la política de red debe attacharse a la identidad a través del ciclo de vida spawn-act-retire, y la paridad de desarrollo local-versus-remoto para estado de Durable Object es el tipo de detalle que decide si un agente se comporta igual en desarrollo y producción. La recomendación es tratar la red del agente como algo que diseñas con identidad y política con alcance, no algo que los agentes heredan con acceso ambiental amplio.

[50:00] Cierre: prioridades de actualización Para Claude Code, instala 2.1.144 y valida las superficies cambiadas directamente: desenganchar, despertar, re-spawn y reanudar de sesiones en segundo plano; paginación de lista de herramientas MCP y manejo de imágenes no soportadas; comportamiento de inicio en una red degradada; y que las sesiones reanudadas mantienen el modelo correcto. Para selección de modelo, haz benchmark de Composer 2.5 dentro de tu propio harness en tus propias tareas de sesión larga y compara el costo total por tarea completada, no tasas de aprobación de portada. Para clientes de herramientas, audita de dónde viene la generación de SDK o cliente y trata la deriva de especificación-a-cliente como un modo de fallo monitoreado. Para agentes de espacio de trabajo, trata la API de Agente Externo de Notion como una superficie multivendor y diseña el límite de confianza deliberadamente. Para stacks mixtos, usa el adaptador reescrito de Vercel para conectar LangGraph y AI SDK en lugar de hacer conectores a mano. Para red de agentes, attacha identidad y política con alcance al ciclo de vida del agente en lugar de depender de acceso ambiental amplio.