Vercel Sandbox suma observabilidad de memoria en 2026

Vercel Sandbox ya mide la memoria de tus agentes de IA

Vercel incorporó soporte de observabilidad de memoria a Vercel Sandbox, su entorno de ejecución basado en microVMs Firecracker diseñado para correr código no confiable de agentes de IA. A partir del changelog oficial publicado este lunes, los equipos ya pueden consultar el consumo promedio, P75 y P95 desde el dashboard, desde la CLI con vercel metrics y desde el query builder de Observability.

El anuncio llega dos semanas después de que la propia Vercel cerrara un programa de bug bounty con un fondo de US$1 millón para "romper" su Sandbox. SecurityWeek reportó que el programa —activo entre el 18 de agosto y el 1 de septiembre— recibió 1.285 reportes en dos semanas, con aproximadamente US$325.000 en pagos comprometidos y sin que ningún informe demostrara acceso a datos de clientes. Esa misma cobertura explica que los hallazgos más relevantes fueron dos defectos en la pila de red del kernel de Linux que filtran memoria del host y permiten tirarlo abajo de forma determinista.

Qué cambia técnicamente con esta versión

El cambio está centrado en tres superficies: panel web, terminal y observabilidad programable.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

En el dashboard, la nueva Memory Usage card muestra promedio, P75 y P95 de uso de memoria, junto a las métricas de CPU y transferencia de datos que ya existían en las páginas de overview del Sandbox, de proyecto y de equipo. En la vista de detalle de cada sandbox, las gráficas autoescalan el eje Y hasta el límite de memoria del entorno y dibujan una línea discontinua de referencia al 85% del techo —un umbral útil para anticipar OOMs antes de que se conviertan en caídas de workloads en producción.

En la CLI, los datos están disponibles bajo vercel.sandbox.memory_used_bytes al correr vercel metrics. El comando devuelve la métrica, el periodo de reporte, el intervalo de medición, el proyecto asociado y una gráfica con min, max y promedio. Puede ejecutarse dentro de un proyecto enlazado o con --all para ver el agregado del equipo, según la documentación oficial.

En el query builder, memoryUsedBytes aparece como medida disponible sobre el evento de uso del sandbox. Esto permite construir consultas personalizadas y, sobre todo, crear alertas automáticas a partir del gráfico —algo clave si dependes de agentes que ejecutan tareas largas o modelos que cargan prompts extensos en memoria.

Por qué importa para quien despliega agentes de IA

Un sandbox para agentes de IA no es lo mismo que un contenedor tradicional. Aísla cargas de trabajo no confiables —código que el propio modelo genera o que el usuario sube— usando virtualización ligera, lo que añade una capa real de seguridad pero también nuevas formas de fallar: picos de memoria durante inferencias largas, prompts con contexto enorme, herramientas MCP con fugas o, simplemente, agentes que se quedan en bucle.

Sin telemetría de memoria, las únicas señales de que algo va mal suelen ser logs crípticos, timeouts o tickets de soporte. Con P75 y P95 visibles, el equipo puede pasar de "se cayó el sandbox" a "el P95 de memoria subió al 83% en eu-west después del último cambio en el prompt del agente". Esa granularidad es la que diferencia operar un feature de mantenerlo.

Hay además un ángulo de costes. Vercel Sandbox se factura por uso; un sandbox que duplica su consumo de memoria sin razón aparente está quemando dinero sin entregar valor. Medir el P95 antes y después de un cambio de prompt o de modelo es, en la práctica, una auditoría gratuita de eficiencia.

El contexto de seguridad detrás del lanzamiento

El lanzamiento de observabilidad no llega en el vacío. La propia Vercel publicó los resultados de su reto de seguridad pocas semanas antes, según SecurityWeek: además de los defectos del kernel de Linux, el white box testing de Trail of Bits produjo 20 hallazgos y recomendaciones arquitectónicas, entre ellas "deja de confiar en el guest". La compañía también anunció que abrirá el código del agente de triaje que construyó internamente sobre su framework Vercel Eve y el modelo Kimi K3, capaz de leer cada reporte, deduplicarlo entre miles de filings y ejecutar el proof-of-concept del investigador dentro de un Sandbox real.

Para un founder, el mensaje implícito es claro: Vercel está invirtiendo en que Sandbox sea una pieza seria de infraestructura para agentes, no un demo. Y cuando inviertes en infraestructura seria, lo razonable es que el cliente también la opere con datos.

Qué significa esto para tu startup

Si hoy ejecutas código no confiable (agentes, herramientas que llaman a LLMs, automatizaciones que tocan repos o navegadores), una capa de observabilidad por sandbox puede ser la diferencia entre detectar un agente desbocado en minutos y enterarte por un cliente insatisfecho.

Tres acciones concretas para aplicar esta semana:

Audita tu consumo de memoria en CI/CD. Activa vercel metrics en tu pipeline y mide P75 y P95 antes y después de cada release que cambie prompts, herramientas o modelos. Si el P95 se acerca al 85%, tienes una alerta antes del OOM.
Crea alertas desde el query builder. Define un umbral (por ejemplo, P95 > 70% sostenido durante 5 minutos) y conéctalo al canal de tu equipo. La regla del 85% ya la puso Vercel; tú decides dónde actúas.
Distingue CPU de memoria al investigar incidentes. Muchas caídas se diagnostican mal porque solo se miran las métricas de CPU. Empieza siempre por el panel de memoria y compara contra el techo del sandbox.

La conclusión es incómoda pero útil: los agentes de IA ya están en producción para muchos equipos, y operarlos sin telemetría por sandbox es como correr un microservicio sin logs. Vercel acaba de poner parte de la instrumentación al alcance de un comando.