Den hemliga infrastrukturen bakom Claude Code som ingen pratar om

Varje utvecklare som testat Claude Code har märkt att något känns annorlunda. Miljön är snabb — misstänkt snabb. Sessioner startar direkt, filsystemet är orört, och allt körs i en webbaserad terminal. Men har du någonsin undrat vad som faktiskt körs när du ansluter?

Visar sig att de flesta inte har funderat på det — förrän nu.

En fascinerande reverse-engineering-analys har nyligen avslöjat hur Claude Code:s runtime faktiskt fungerar under huven. Och vad forskarna hittade antyder att Anthropic inte bara bygger AI-modeller. De håller tyst på att konstruera det infrastrukturlager som så småningom kan utmana plattformar som Vercel, Railway och Render.

Det är Firecracker hela vägen ner

Kärnteknologin som driver Claude Code:s exekveringsmiljö är Firecracker — samma open source-mikroVM-teknik som driver AWS Lambda och Fargate. Om du bygger molninfrastruktur bör detta få dig att reagera.

Här är vad som körs i varje Claude Code-session:

• 4 vCPUs (Intel Xeon Cascade Lake @ 2.80GHz)
• 16 GB RAM
• 252 GB disk
• Linux 6.18.5-kärna

Ingen nestad virtualisering heller. Firecracker avlägsnar medvetet VMX/SVM-flaggorna som skulle tillåta gästen att starta egna VM:ar — ett säkerhetsmedvetet designval som isolerar arbetsbelastningar.

Men här blir det intressant: det finns ingen systemd. Ingen SSH-daemon. Ingen cron. Ingen loggningsinfrastruktur. Hela processträdet ser ut så här:

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 (CLI-verktyget)

Tre processer. Bara det. Den första processen är en egen binär som fungerar både som init-system och WebSocket API-gateway. Den lyssnar på port 2024 för WebSocket-anslutningar och port 2025 för sekundära endpoints.

Det här är elegant infrastrukturoptimering — att skala bort allt onödigt för att minimera attackytan och maximera prestanda.

Snapshot-arkitekturen: Där magin händer

Det mest remarkabla fyndet är inte själva microVM:en — det är hur sessioner initieras.

Sessioner startar inte från grunden. De återställs från frysta snapshots.

När forskarna granskade boot-loggarna hittade de en 48,5-timmars lucka mellan när template-VM:en skapades och när en session återställdes:

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

Det här är i princip samma SnapStart-koncept som AWS Lambda pioneered. Template-VM:n bootar en gång, initierar till ett klart tillstånd, och frysas sedan som ett snapshot. När du startar en ny session återställer systemet det snapshotet på millisekunder istället för att vänta på en fullständig boot-sekvens.

Enhets-hotswappingen under återställning är särskilt smart:

| Enhet | Template | Efter återställning | Innehåll | |--------|----------|---------------|---------| | vda | placeholder | 256 GiB ext4 | Sessions rootfs (Ubuntu 24.04) | | vdb | placeholder | 63.7 MB squashfs | /opt/claude-code | | vdc | placeholder | 12.1 MB squashfs | /opt/env-runner |

Root-filsystemet är en dynamiskt injicerad blockenhet. Ubuntu-miljön ligger på en ext4-volym som byts ut vid återställningstillfället, medan Claude Code-verktygen och environment runner monteras som squashfs-overlays.

Det här lagerbaserade tillvägagångssättet innebär att varje session får en ren, isolerad miljö utan omkostnaderna för att återskapa hela filsystemet.

Vad "Antspace" betyder för AI-infrastrukturracet

Här är spekulationen som gör historien intressant: reverse engineering-avslöjade referenser som antyder att Anthropic kan bygga en intern plattform som kallas "Antspace."

Om det stämmer positionerar det Anthropic som en potentiell PaaS-konkurrent — en Vercel för AI-native applikationer.

Tänk på vad de bygger:

• En runtime-miljö som hanterar autentisering, processhantering och WebSocket-kommunikation
• Isolerad microVM-baserad exekvering med starka säkerhetsgränser
• Snapshot-baserad instant deployment och skalning
• En API-first-arkitektur designad för programmerbar kontroll

Det här är exakt den infrastruktur som behövs för att stödja inte bara Claude Code, utan en komplett svit av AI-drivna utvecklingsverktyg, deployment-pipelines och hosting-plattformar.

Säkerhetsarkitekturen är värd att notera

Teamet har tydligen tänkt noggrant kring säkerhet. Anmärkningsvärda åtgärder inkluderar:

init_on_free=1 — Minnessidor nollställs när de frigörs, vilket förhindrar dataläckage mellan sessioner.

CRNG-ombesåddning — Den kryptografiska slumptalsgeneratorn ombesås efter VM-återställning. Detta är kritiskt eftersom snapshots teoretiskt sett kunde dela samma entropitillstånd, vilket skulle vara en kryptografisk sårbarhet.

Capability dropping — Efter initiering släpper PID 1 CAP_SYS_RESOURCE, vilket begränsar vad processen kan göra även om den komprometteras.

--block-local-connections — Lokal WebSocket-åtkomst blockeras, vilket förhindrar sessionen från att ansluta direkt till management-gränssnitt.

JWT-autentisering — WebSocket-anslutningar kräver verifierade tokens, och hemligheter rensas bort från konfigurationer efter användning.

Det här är inte bara säkerhetsteater — det är meningsfulla härdningsval som antyder att denna infrastruktur designades med produktionsarbetsbelastningar i åtanke.

Varför detta spelar roll för utvecklare

Oavsett om du bygger AI-verktyg, coding agents eller molnnära applikationer är mönstren som framträder från Claude Code:s infrastruktur värda att studera:

1. Firecracker blir standardvalet för isoleringsintensiva arbetsbelastningar. Om du utvärderar containers kontra microVMs erbjuder Firecracker VM-nivåsäkerhet med container-nivå hastighet.

2. Snapshot-baserad initiering är framtiden för allt som behöver subsekunds uppstartstider. Detta mönster sprids från Lambda till utvecklingsmiljöer.

3. Egna init-system gör comeback. När du inte behöver hela systemd-stacken kan en minimalistisk custom supervisor vara snabbare, säkrare och mer ändamålsbyggd.

4. AI-företag bygger infrastruktur som så småningom kan konkurrera med traditionella molnleverantörer. Anthropics interna plattform, om den är verklig, representerar en betydande investering i hosting-utrymmet.

Nästa gång du startar Claude Code använder du inte bara ett CLI-verktyg — du får en glimt av AI-nativ molninfrastruktur som kan komma att definiera hur intelligenta applikationer byggs och deployas de kommande åren.

Den större bilden

Det mest slående med detta upptäckt är inte någon enskild teknisk detalj. Det är beviset på att AI-företag tänker seriöst på hela stacken — inte bara modeller, utan infrastrukturen för att köra allt som dessa modeller möjliggör.

Anthropic bygger inte bara Claude. De bygger plattformlagret som kan stödja en ny generation av AI-native applikationer.

Och om "Antspace" är verkligt? Konkurrensen inom AI-hosting kommer att bli mycket intressant.

Har du tankar om AI-infrastruktur eller vill dela dina egna reverse-engineering-upptäckter? Utvecklargemenskapen frodas av dessa samtal. Ibland kommer de mest värdefulla insikterna från att titta under huven.