La Infraestructura Oculta de Claude Code Que Nadie Está Explicando

Si has usado Claude Code, sabes de qué hablo. Hay algo distinto en cómo se siente. Todo es increíblemente rápido: las sesiones inician al instante, el sistema de archivos está impecable, y corres todo desde un terminal en el navegador. Pero ¿alguna vez te preguntaste qué demonios está corriendo realmente ahí detrás?

Resulta que la mayoría no se lo pregunta. Hasta ahora.

Un análisis de ingeniería inversa reciente reveló cómo funciona el runtime de Claude Code bajo elhood. Y lo que encontraron los investigadores sugiere que Anthropic no solo está construyendo modelos de IA. Están construyendo, casi en silencio, la capa de infraestructura que podría plantar cara a plataformas como Vercel, Railway y Render.

Firecracker: El Motor de Todo

La tecnología central que impulsa el entorno de ejecución de Claude Code es Firecracker — sí, el mismo proyecto open source de microVMs que alimenta AWS Lambda y Fargate. Si trabajas con infraestructura en la nube, esto debería hacerte prestar atención.

Esto es lo que corre dentro de cada sesión de Claude Code:

• 4 vCPUs (Intel Xeon Cascade Lake @ 2.80GHz)
• 16GB de RAM
• 252GB de disco
• Kernel Linux 6.18.5

Sin virtualización anidada, ojo. Firecracker stripping deliberadamente los flags VMX/SVM que permitirían al guest levantar sus propias VMs. Esto es una decisión de seguridad que aísla las workloads.

Pero aquí es donde se pone interesante: no hay systemd. Ni daemon SSH. Ni cron. Ni infraestructura de logging. El árbol de procesos entero se ve así:

PID 1: /process_api --firecracker-init --addr 0.0.0.0:2024
  └─ PID 517: /usr/local/bin/environment-manager task-run --session cse_...
       └─ PID 532: claude (el CLI en sí)

Tres procesos. Solo tres. El primero es un binario custom que actúa simultáneamente como sistema init y como gateway de API WebSocket. Escucha en el puerto 2024 para conexiones WebSocket y en el 2025 para endpoints secundarios.

Esto es diseño de infraestructura elegante: quitar todo lo innecesario para minimizar la superficie de ataque y maximizar el rendimiento.

La Arquitectura de Snapshots: Ahí Ocurre la Magia

El descubrimiento más remarkable no es la microVM en sí — es cómo se inicializan las sesiones.

Las sesiones no bootear desde cero. Se restauran desde snapshots congelados.

Cuando los investigadores examinaron los logs de arranque, encontraron un gap de 48.5 horas entre cuándo se creó la VM template y cuándo se restauró una sesión:

[  30.731516] Run /process_api as init process
    ~~~ 48.5 HOUR GAP — VM WAS FROZEN AS SNAPSHOT ~~~
[174695.927758] virtio_blk: [vdc] new size: ...

Básicamente estamos hablando del mismo concepto de SnapStart que AWS Lambda popularizó. El template bootea una vez, inicializa hasta un estado listo, y luego se freezea como snapshot. Cuando inicias una nueva sesión, el sistema restaura ese snapshot en milisegundos en lugar de esperar una secuencia de boot completa.

El hot-swap de dispositivos durante la restauración es particularmente ingenioso:

| Dispositivo | Template | Post-Restauración | Contenido | |-------------|----------|-------------------|-----------| | vda | placeholder | 256 GiB ext4 | rootfs de sesión (Ubuntu 24.04) | | vdb | placeholder | 63.7 MB squashfs | /opt/claude-code | | vdc | placeholder | 12.1 MB squashfs | /opt/env-runner |

El filesystem root es un block device inyectado dinámicamente. El entorno Ubuntu vive en un volumen ext4 que se swapping al momento de la restauración, mientras que las herramientas de Claude Code y el environment runner se montan como overlays de squashfs.

Este enfoque en capas significa que cada sesión obtiene un entorno limpio e aislado sin el overhead de recrear el filesystem entero.

Qué Significa "Antspace" Para la Carrera de Infraestructura de IA

Aquí está la especulación que hace que esta historia sea jugosa: la ingeniería inversa descubrió referencias que sugieren que Anthropic podría estar construyendo una plataforma interna llamada "Antspace."

Si es cierto, esto posiciona a Anthropic como un potencial competidor de PaaS — un Vercel para aplicaciones nativas de IA.

Piénsalo: lo que están construyendo incluye:

• Un entorno de ejecución que maneja autenticación, gestión de procesos y comunicación WebSocket
• Ejecución basada en microVMs aisladas con fuertes fronteras de seguridad
• Deployment y scaling instantáneo basado en snapshots
• Una arquitectura API-first diseñada para control programático

Esto es exactamente la infraestructura que necesitarías para soportar no solo Claude Code, sino una suite completa de herramientas de desarrollo potenciadas por IA, pipelines de deployment y plataformas de hosting.

La Arquitectura de Seguridad Merece Mención

El equipo claramente pensó cuidadosamente en seguridad. Las medidas notables incluyen:

init_on_free=1 — Las páginas de memoria se zeroan cuando se liberan, previniendo data leakage entre sesiones.

CRNG reseeding — El generador de números aleatorios criptográficos se re-seedea después de la restauración de la VM. Esto es crítico porque los snapshots podrían teóricamente compartir el mismo estado de entropía, lo cual sería una vulnerabilidad criptográfica.

Capability dropping — Después de la inicialización, PID 1 droppea CAP_SYS_RESOURCE, limitando lo que el proceso puede hacer incluso si está comprometido.

--block-local-connections — El acceso WebSocket a localhost está bloqueado, previniendo que la sesión se conecte directamente a interfaces de management.

Autenticación JWT — Las conexiones WebSocket requieren tokens verificados, y los secrets se scrubbean de los configs después de uso.

Estos no son solo theater de seguridad — son decisiones de hardening significativas que sugieren que esta infraestructura fue diseñada pensando en workloads de producción.

Por Qué Esto Importa Para Desarrolladores

Ya sea que estés construyendo herramientas de IA, coding agents, o aplicaciones cloud-native, los patrones que emergen de la infraestructura de Claude Code valen la pena estudiar:

1. Firecracker se está convirtiendo en el default para workloads que requieren aislamiento pesado. Si estás evaluando containers vs. microVMs, Firecracker ofrece seguridad a nivel de VM con velocidad a nivel de container.

2. La inicialización basada en snapshots es el futuro para cualquier cosa que necesite tiempos de startup bajo el segundo. Este patrón se está expandiendo desde Lambda hasta entornos de desarrollo.

3. Los sistemas init custom están haciendo comeback. Cuando no necesitas el stack completo de systemd, un supervisor minimal custom puede ser más rápido, más seguro y más especializado.

4. Las companies de IA están construyendo infraestructura que eventualmente podría competir con proveedores cloud tradicionales. La plataforma interna de Anthropic, si es real, representa una inversión significativa en el espacio de hosting.

La próxima vez que inicies Claude Code, no estás solo usando una herramienta de CLI — estás accediendo a un vistazo de infraestructura cloud nativa de IA que podría definir cómo se construyen y deployean aplicaciones inteligentes en los años que vienen.

El Panorama Completo

Lo más llamativo de este descubrimiento no es ningún detalle técnico individual. Es la evidencia de que las companies de IA están pensando seriamente en el stack completo — no solo los modelos, sino la infraestructura para correr todo lo que esos modelos habilitan.

Anthropic no solo está construyendo Claude. Están construyendo la capa de plataforma que podría soportar una nueva generación de aplicaciones nativas de IA.

¿Antspace es real? Entonces la competencia en el espacio de hosting de IA está a punto de ponerse muy interesante.

¿Tienes pensamientos sobre infraestructura de IA o quieres compartir tus propios descubrimientos de ingeniería inversa? La comunidad de desarrolladores florece con estas conversaciones. A veces los insights más valiosos vienen de mirar bajo elhood.