Vercel Sandbox 64 GB: más espacio para tareas de agentes

La novedad de Vercel Sandbox 64 GB no se reduce a la cifra. Lo importante es que una tarea sobre un repositorio que antes chocaba con el límite de 32 GB ahora puede terminar en una sola máquina, sin recortes, divisiones ni traslados a otro entorno.

El 11 de septiembre de 2026, Vercel duplicó el almacenamiento de trabajo predeterminado de cada Sandbox: pasó de 32 GB a 64 GB.

Qué cambia con Vercel Sandbox 64 GB

Vercel Sandbox es una microVM Linux aislada: una máquina virtual pequeña con kernel, sistema de archivos y red propios. Se le puede entregar un repositorio para que un agente edite código, instale paquetes, ejecute pruebas, genere una compilación y, al final, extraiga el resultado.

Todas esas etapas comparten el mismo disco local. El checkout puede seguir ocupando espacio cuando llega el árbol de dependencias. Las cachés de compilación y los archivos compilados pueden convivir con datos temporales. El artefacto final quizá sea pequeño, aunque durante unos minutos el proceso necesite mucho más espacio para producirlo.

Ese pico es lo que cambia con esta actualización. Vercel ahora asigna 64 GB de almacenamiento de trabajo al sandbox en lugar de 32 GB: son 32 GB adicionales y el doble de la capacidad anterior. La mejora se aplica a los sandboxes creados desde una Vercel Managed Image, una imagen personalizada y la propiedad obsoleta runtime.

Se trata de capacidad dentro del sandbox, no de una nueva cuota para bases de datos o almacenamiento de objetos. Vercel la describe como almacenamiento NVMe efímero. Si los archivos deben sobrevivir a la tarea, la decisión sobre persistencia sigue siendo independiente.

La decisión de negocio: saber si toda la tarea cabe

La pregunta que perdura no es «¿cuál es el límite de disco de Vercel?», sino «¿puede ejecutarse toda esta tarea en un solo sandbox sin recortes especiales ni traspasos?».

Conviene partir de un presupuesto sencillo para el espacio de trabajo:

Pico del espacio de trabajo = repositorio y checkout + dependencias instaladas + artefactos de compilación + pico de datos temporales

Hay que medir el máximo mientras se ejecuta la tarea, no deducirlo a partir del archivo zip final. La extracción de paquetes, la compilación, los datos de prueba, los binarios del navegador, las cachés y un volcado de datos pueden coincidir apenas unos minutos, pero esos minutos determinan si la ejecución termina o no.

Los precios y cuotas actuales de Vercel separan las capas de almacenamiento en partidas distintas:

Esta distinción cambia el cálculo de costos. Duplicar el disco de trabajo no duplica la tarifa de cómputo. En el ejemplo actual de Vercel para iad1, una ejecución de compilación y pruebas de 30 minutos con 4 vCPUs y 8 GB de memoria cuesta alrededor de $0.34 usando toda la CPU.

Una tarea mayor sí puede costar más si tarda más o exige más CPU y memoria. Las descargas de paquetes, repositorios, artefactos y conjuntos de datos son gratuitas; los datos enviados fuera del sandbox son facturables.

La persistencia es el punto en el que los archivos adicionales pueden abrir una nueva partida de almacenamiento. Si una ejecución utilizara y conservara los 32 GB recién añadidos durante un mes completo, el cálculo según la tarifa sería 32 × $0.08 = $2.56 por cada mes de instantánea. Es solo un ejemplo, no un cargo automático. Una ejecución no persistente que exporta el resultado y descarta el espacio de trabajo evita esa partida de instantáneas.

Quién puede aprovechar el espacio adicional

Un staff engineer con un monorepo grande

Es posible que un staff engineer tenga que podar paquetes, eliminar datos de prueba o dividir una compilación porque el repositorio, el grafo de dependencias y el resultado compilado no podían coexistir bajo el límite anterior.

Si el pico medido ahora cabe en el sistema de archivos de 64 GB disponible, el equipo puede volver a reunir el checkout, la instalación, las pruebas y la compilación en una sola tarea. El beneficio es operativo: menos traspasos, menos artefactos parciales y un único punto de reintento cuando falla la compilación.

Esto no convierte automáticamente a Vercel en el proveedor de sandbox adecuado. Si todavía se está eligiendo la capa de ejecución, la comparativa de sandboxes de código para agentes de IA analiza las diferencias de aislamiento y facturación. Esta actualización solo desplaza el límite de disco de Vercel.

Un ingeniero de plataformas de agentes que repara repositorios

Un agente de programación suele acumular archivos a medida que trabaja. Clona el repositorio, instala herramientas, modifica archivos, ejecuta el conjunto de pruebas y empaqueta el resultado. Si explora varios enfoques, también puede dejar cachés y resultados intermedios.

Los 32 GB adicionales dan más margen para completar todo ese ciclo dentro de un único sandbox. Eso puede eliminar un reintento por falta de disco o una herramienta de limpieza personalizada del flujo del agente. La mejora importa sobre todo cuando el disco era la causa real del fallo. Una tarea limitada por memoria, CPU, políticas de red o duración de la sesión no obtiene ningún beneficio de un sistema de archivos mayor.

Un ingeniero de datos cuya transformación se desborda al disco

Un ingeniero de datos puede emplear el sistema de archivos local como espacio temporal mientras una transformación ordena, combina o expande datos descargados. El disco más grande puede mantener ese trabajo temporal en local, sin obligar a dividirlo antes de tiempo ni a montar almacenamiento remoto.

El resultado sigue necesitando una ruta de salida. Hay que copiarlo fuera, escribirlo en el almacenamiento de objetos adecuado o montar un Drive si otras ejecuciones necesitan el mismo directorio. Un disco temporal de 64 GB resulta útil precisamente porque se puede descartar. Tratarlo como almacenamiento permanente mezcla dos funciones y dos facturas distintas.

Un equipo que aún utiliza runtime

La actualización del 11 de septiembre incluye expresamente los sandboxes configurados con la propiedad obsoleta runtime. El código existente debería recibir el disco ampliado sin migrar de imagen.

La dirección actual de la plataforma sigue siendo el uso de imágenes. Desde la versión 3 del Sandbox SDK, un sandbox que no especifica runtime ni image utiliza vercel/sandbox/universal:latest. Las imágenes gestionadas se actualizan cada noche, y fijar un digest proporciona un entorno inmutable cuando la reproducibilidad de las compilaciones es importante.

Mide una tarea representativa antes de cambiar el flujo

La actualización elimina un límite, pero no indica cuánto espacio tienen realmente la imagen y la tarea propias. Antes de borrar pasos de limpieza o volver a unir compilaciones divididas, hay que medir una ejecución real.

1. 1

   Elige la tarea que permitirá tomar la decisión

   Selecciona una tarea que se haya quedado sin disco hace poco o que hoy se divida únicamente para no superar el límite anterior. Utiliza el mismo repositorio, lockfile, comando de compilación y datos de entrada que en producción. Un repositorio de juguete no responde la pregunta de negocio.

2. 2

   Inicia un sandbox nuevo basado en una imagen

   La CLI actual y la ruta basada en imágenes facilitan la reproducción del resultado. Esta secuencia sigue el flujo documentado de la CLI de Vercel Sandbox y desactiva la persistencia para que la medición no cree una instantánea automática.

   npm i -g sandbox
   sandbox login
   sandbox create --name workspace-check --image vercel/sandbox/node:24 --timeout 30m --non-persistent
   
   tar -czf app.tgz -C ./my-app .
   sandbox copy ./app.tgz workspace-check:/tmp/app.tgz
   sandbox exec workspace-check -- sh -c "mkdir -p /app && tar -xzf /tmp/app.tgz -C /app"

3. 3

   Registra cada fase de consumo de almacenamiento

   Ejecuta la comprobación del disco después del checkout, tras instalar las dependencias, durante la parte más exigente de la compilación si es posible y cuando el artefacto esté completo. Sustituye .next y dist por las rutas de salida que utilice realmente el proyecto.

   sandbox exec --workdir /app workspace-check -- sh -lc 'df -h /; du -sh .git node_modules .next dist /tmp 2>/dev/null || true'
   
   sandbox exec --workdir /app workspace-check -- npm install
   sandbox exec --workdir /app workspace-check -- sh -lc 'df -h /; du -sh .git node_modules .next dist /tmp 2>/dev/null || true'
   
   sandbox exec --workdir /app workspace-check -- npm run build
   sandbox exec --workdir /app workspace-check -- sh -lc 'df -h /; du -sh .git node_modules .next dist /tmp 2>/dev/null || true'

   df -h / muestra cuánto espacio le queda al sandbox. Las líneas de du revelan qué parte del espacio de trabajo lo consume. Revisar únicamente el estado posterior a la compilación final puede ocultar el pico.

4. 4

   Reintenta una vez sin la solución alternativa anterior

   Si el máximo medido queda dentro del espacio libre informado, vuelve a ejecutar la misma tarea sin podar dependencias ni transferir una compilación dividida. Registra el resultado, el tiempo total, la CPU activa, la memoria aprovisionada, la transferencia y si se creó alguna instantánea o almacenamiento en Drive. Después, detén el sandbox.

   sandbox stop workspace-check

Los límites que no cambian

Más disco no aporta más memoria, CPU ni tiempo. Una sesión de Sandbox sigue teniendo una duración predeterminada de 5 minutos. Las sesiones Hobby pueden durar hasta 45 minutos; las de Pro y Enterprise, hasta 24 horas.

La actualización tampoco garantiza que cualquier carga inferior a 64 GB vaya a caber sin problemas. La imagen inicial ocupa parte del sistema de archivos, y las etiquetas de imagen móviles pueden cambiar con las actualizaciones nocturnas de Vercel. Comprueba el espacio libre real después del arranque. Fija el digest de la imagen si la misma compilación debe comenzar siempre desde el mismo entorno.

Si una tarea necesita datos compartidos duraderos, utiliza un Drive u otro almacén persistente. Si necesita más espacio de trabajo del que informa el sandbox, mantén la división, traslada el gran conjunto temporal al almacenamiento montado o ejecuta la tarea en otro lugar. El nuevo límite mueve el punto de corte, pero no cambia esas opciones.

Qué conviene hacer el lunes

Actúa esta semana si un repositorio, un agente o una tarea de datos reales falló en el límite anterior de disco, o si conserva código de limpieza solo para evitarlo. Conviene esperar si todavía no se midió el pico: eliminar a ciegas una división que funciona solo pospone el próximo fallo. El cambio no afecta a las tareas que ya permanecen holgadamente por debajo de la capacidad anterior ni a aquellas cuyo cuello de botella real es la CPU, la memoria, el acceso a la red, la duración de la sesión o el almacenamiento duradero.

El lunes, toma una tarea representativa, realiza la medición anterior en un Sandbox nuevo de 64 GB basado en una imagen y vuelve a ejecutarla una vez sin la antigua solución de almacenamiento. Conserva la ruta más sencilla de una sola tarea únicamente si la ejecución medida termina y la suma de cómputo y persistencia sigue teniendo sentido económico.

Para recibir más explicaciones claras sobre cambios que modifican los costos operativos, suscríbete al boletín.