Vercel Sandbox añade métricas por sesión: cómo saber cuánto cuesta realmente un agente aislado

Vercel añadió el 7 de julio de 2026 métricas más detalladas para sus Sandboxes: CPU activa, memoria provisionada, transferencia de datos y cantidad de Sandboxes y sesiones en ejecución. Cada dato se puede agrupar por nombre del Sandbox y por identificador de sesión, y también se puede consultar desde la CLI de Vercel.

Para un agente que clona un repositorio, instala dependencias y ejecuta pruebas en un entorno aislado, esto resuelve una pregunta que suele llegar demasiado tarde: ¿qué parte de la ejecución está consumiendo el presupuesto? Sin esa atribución, un equipo puede culpar al modelo cuando el problema real es una sesión que no terminó o una configuración de memoria sobredimensionada.

Qué mide cada señal

Vercel separa el uso activo de CPU del tiempo esperando I/O, como una descarga o una llamada a un modelo. La CPU activa se expresa en core-hours. La memoria se mide como GB-hours provisionados durante la vida del Sandbox, no como el promedio de bytes que el proceso usó en cada instante.

La transferencia incluye datos que entran y salen del Sandbox, como descargas de paquetes y llamadas a APIs. El panel también muestra cuántos Sandboxes y sesiones están vivos y cuándo se iniciaron o detuvieron. Ese último dato es operativo: una sesión que sigue abierta después de entregar el diff puede ser un costo silencioso.

La CLI permite consultar el esquema y pedir métricas, por ejemplo:

vercel metrics schema vercel.sandbox
vercel metrics vercel.sandbox.cpu_usage --all

La documentación indica que la observabilidad está incluida en todos los planes, mientras que las consultas manuales están disponibles en Pro y Enterprise. El dato no debe confundirse con una tarifa única: sigue siendo necesario leer los límites y precios vigentes del Sandbox antes de calcular un costo unitario.

El agente necesita un presupuesto por ejecución

Una métrica agregada por proyecto sirve para contabilidad, pero no basta para gobernar agentes. Etiqueta cada sesión con un identificador de tarea y registra al menos:

1. repositorio, commit y tamaño de entrada;
2. modelo y cantidad de llamadas externas;
3. CPU activa, memoria y transferencia;
4. duración, reintentos y motivo de cierre;
5. artefactos producidos y estado de la revisión humana.

Así puedes comparar dos trayectorias que entregaron el mismo parche. Una quizá gastó CPU compilando repetidamente; la otra quizá consumió memoria por conservar procesos que no necesitaba. La métrica ayuda a decidir, no explica por sí sola la calidad del resultado.

La telemetría no es aislamiento

Ver que una sesión usa poco CPU no demuestra que el entorno sea seguro. Un coding agent puede descargar un paquete malicioso, leer un secreto montado o enviar datos por una conexión de salida aunque su consumo sea pequeño. La configuración de red, el alcance de los secretos y la limpieza de snapshots siguen siendo controles separados.

Para un piloto, crea una tarea reproducible con un repositorio de prueba, fija el commit y usa un timeout. Compara una ejecución exitosa con una que fuerce un reintento. Después define un presupuesto y una alerta operativa para sesiones que superen la duración esperada o no produzcan un artefacto final. La observabilidad vale más cuando activa una decisión concreta.

Las búsquedas Vercel Sandbox observability, costo de agentes en sandbox, Vercel Sandbox metrics y coding agent resource usage tienen una intención operativa clara. La demanda se infiere del changelog, la documentación de Sandbox y el problema práctico de medir ejecuciones aisladas; no se está inventando volumen SEO.

Si estás diseñando un agente que ejecuta herramientas, el curso gratis ayuda a separar permisos, entorno y validación. La actualización de Vercel hace visible la factura técnica por sesión; todavía debes decidir qué límites impiden que una ejecución se convierta en una tarea sin fin.