Vercel lleva Session Traces al CLI: cómo depurar requests y agentes sin salir de terminal

Una de las cosas más torpes de depurar en flujos agentic es esta: el fallo aparece en terminal, pero la evidencia útil vive dispersa entre toolbar, dashboard, logs y spans. El anuncio de Vercel del 3 de junio de 2026 ataca exactamente ese hueco con dos comandos nuevos:

• vercel curl --trace
• vercel traces get

La mejora parece pequeña hasta que la miras desde trabajo real. Si un agente rompe una ruta, devuelve un 500, se pierde en middleware o deja un request raro en producción, ahora puedes disparar el request desde CLI y pedir el trace desde la misma superficie.

Qué hace exactamente

El changelog es muy concreto:

• vercel curl --trace genera un OpenTelemetry trace hacia el endpoint que indiques;
• vercel traces get recupera el trace por request ID;
• y está disponible en todos los planes.

Eso cambia bastante el loop de verificación para builders y para agentes. Antes, si querías depurar algo más allá de un status code, muchas veces tenías que saltar a la UI, buscar manualmente o depender de una traza iniciada desde toolbar. Ahora puedes empezar desde el mismo sitio donde ya estás reproduciendo el bug.

Dónde sí ayuda a agentes

Yo lo dividiría en tres usos claros.

1. Verificación de previews y rutas rotas

Cuando un agente hace deploy o toca routing, el primer paso no es leer un dashboard bonito. Es reproducir el request exacto. Con vercel curl, ya podías pegarle a un deployment protegido usando tu auth. Con --trace, además generas la historia del request.

Eso sirve para ver si el problema vive en:

• routing;
• middleware;
• función;
• backend externo;
• o caché.

2. Handoff más limpio entre agente y humano

Un agente puede dejarte el request ID concreto en vez de un “falló algo en producción”. Ese cambió de calidad importa muchísimo. El humano ya no entra a ciegas; entra con una referencia trazable.

3. Checklist de debugging automatizable

Este es el ángulo más fuerte para tráfico cualificado:

• vercel curl trace
• vercel traces get request id
• debug vercel 500 from cli
• trace middleware vercel

La gente que busca eso casi siempre ya tiene una falla reproducible y quiere bajar tiempo de diagnóstico, no aprender qué es observabilidad desde cero.

Lo que cambia en el flujo de trabajo

La lectura superficial es “Vercel agregó tracing a la CLI”. La útil es otra: la observabilidad deja de ser una superficie separada del acto de reproducir.

Ese detalle importa porque muchos equipos trabajan así:

1. reproducen el bug por CLI;
2. luego saltan a logs;
3. luego abren tracing;
4. luego intentan unir todo.

Vercel acorta ese camino. No resuelve todo, pero reduce el cambió de contexto entre reproducir, identificar y compartir evidencia.

La documentación de Session tracing sigue importando porque recuerda el lado más visual del producto: toolbar, spans y navegación en dashboard. Pero ahora la CLI se vuelve una entrada natural para workflows más automáticos o más cercanos al trabajo de un agente.

Lo que todavía no conviene sobreprometer

No, esto no reemplaza tu estrategia de logs. Tampoco reemplaza instrumentación de aplicación cuando necesitas spans más semánticos. Y menos aún reemplaza criterio al momento de decidir qué request vale la pena trazar.

Lo que sí hace es darte una base mucho mejor para una disciplina sencilla:

• reproduce;
• genera trace;
• guarda request ID;
• comparte evidencia;
• decide.

Eso parece obvio, pero en incidentes reales esa cadena se rompe mucho más de lo que debería.

Cómo lo usaría mañana

Si ya operas previews, APIs o verificaciones automatizadas sobre Vercel, lo probaría así:

1. construir un comando de smoke test con vercel curl --trace;
2. guardar el request ID cuando un check falle;
3. adjuntar ese ID al ticket o al reporte del agente;
4. y revisar el trace antes de tocar código “por intuición”.

Esa disciplina conversa muy bien con Sentry y sus conversaciones de observabilidad para agentes, porque ambas piezas empujan a lo mismo: menos debugging narrado de memoria y más evidencia enlazada al request real. Si todavía te falta la base para estructurar un agente antes de meterle observabilidad sería, empieza por Instala tu propio agente.

La conclusión corta es directa: Vercel no inventó el tracing, pero sí lo acercó al punto donde de verdad empieza el debugging de un builder: la terminal. Para agentes y humanos que verifican, despliegan y corrigen desde CLI, eso sí mueve el flujo.