Un agente de código puede pasar más tiempo preparando su entorno que modificando un archivo. Si cada intento instala las mismas dependencias, una copia de estado reutilizable evita repetir ese trabajo. El 9 de noviembre de 2026, Vercel anunció que crear snapshots de Sandbox tarda menos: la mediana interna pasó de 4,4 segundos a menos de 0,4 segundos; restaurarlos pasó de 500 a 250 milisegundos en p50. Es una medición del proveedor, no una mejora que hayamos comprobado en un proyecto propio.
Qué cambia para quien construye agentes
Un snapshot conserva el sistema de archivos y los paquetes instalados de un Sandbox. En un entorno persistente —la opción predeterminada—, Vercel crea uno automáticamente al detenerse la sesión y lo usa al reanudarla. Los snapshots nuevos aprovechan el formato optimizado; los antiguos conservan el formato anterior. No hay que activar una opción para recibir esta mejora en los snapshots nuevos, según el changelog.
Esto importa cuando un agente hace muchos ciclos cortos: recibe una incidencia, abre el repositorio, ejecuta una prueba, propone un cambio y vuelve más tarde. También permite crear un punto de partida común para varios intentos sin reinstalar dependencias cada vez. El tiempo de snapshot es solo una parte del ciclo: arranque, instalación inicial, pruebas y llamadas al modelo pueden dominar la duración real.
Una prueba de 15 minutos en tu flujo
- Elige una tarea repetida y pequeña, por ejemplo corregir una validación en una app de prueba. Anota el commit, la región, el plan, el tamaño del entorno y las versiones de dependencias.
- Con un Sandbox persistente, prepara el repositorio e instala paquetes una vez. Ejecuta la misma prueba que usaría el agente. Detén la sesión para que se cree el snapshot automático.
- Reanuda el Sandbox tres veces y mide por separado: tiempo hasta que está listo, duración de la prueba y tiempo total hasta obtener un resultado revisable. Si antes medías el mismo flujo, compara medianas con la misma tarea y configuración.
- Comprueba que la versión del código y los paquetes restaurados son los esperados. Si una dependencia cambió, crea un nuevo punto de partida; un snapshot rápido de un entorno obsoleto solo reproduce el error más deprisa.
Registra una tabla sencilla con intento, commit, snapshot_id, arranque_s, prueba_s, total_s, resultado. No atribuyas toda diferencia en total_s al formato de snapshots: la red, el modelo y la carga de la prueba varían.
El detalle que puede salir caro
Los snapshots sobreviven al Sandbox que los creó. Borrar el Sandbox no borra automáticamente esas copias, y el almacenamiento puede seguir generando cargos. La documentación indica caducidad predeterminada de 30 días tras el último uso, ajustes de retención y la posibilidad de conservar solo los últimos N snapshots. Antes de convertir cada paso del agente en un checkpoint, define cuándo se elimina y revisa el consumo.
En la tabla de precios consultada el 10 de noviembre, Hobby incluye 15 GB de almacenamiento de snapshots de por vida; Pro marca 0,08 USD por GB y mes, además de otras dimensiones de Sandbox. Los límites y precios pueden cambiar. No confundas la mejora de latencia con una reducción automática de la factura: guardar más copias puede hacer lo contrario.
Cuándo merece la pena
Si tu agente trabaja en sesiones repetidas con dependencias pesadas, mide arranque y tiempo total antes de rediseñar el flujo. Si ejecuta un único trabajo largo, la diferencia de unas décimas en guardar el estado probablemente no cambie la experiencia. Y si usas Sandboxes no persistentes, no tendrás el snapshot automático al detenerse la sesión. La decisión práctica es conservar un entorno preparado y limpio, limitar copias y medir el resultado que espera el usuario: un cambio correcto y revisable.
Fuentes: anuncio del 9 de noviembre, ciclo y retención de snapshots y precios y cuotas de Vercel. Prueba propia en un proyecto real: pendiente.