Die geheime Infrastruktur hinter Claude Code – und warum sie niemand beachtet

Wer Claude Code nutzt, dem fällt sofort etwas auf: Die Umgebung ist verdammt schnell. Sessions starten ohne spürbare Verzögerung, das Dateisystem ist makellos, und alles läuft über ein browserbasiertes Terminal. Aber hast du dich je gefragt, was dort eigentlich im Hintergrund passiert, wenn du dich verbindest?

Die meisten nämlich nicht – zumindest bis jetzt.

Ein faszinierender Reverse-Engineering-Artikel hat enthüllt, wie Claude Code tatsächlich funktioniert. Und was Forscher dabei entdeckt haben, deutet darauf hin, dass Anthropic nicht nur KI-Modelle entwickelt. Sie bauen still und leise eine Infrastrukturschicht auf, die etablierte Plattformen wie Vercel, Railway und Render angreifen könnte.

Firecracker ist überall

Die Kerntechnologie hinter Claude Code ist Firecracker – dieselbe Open-Source-microVM-Technologie, die auch AWS Lambda und Fargate antreibt. Wer sich mit Cloud-Infrastruktur auskennt, sollte hier aufhorchen.

So sieht die Hardware in jeder Claude-Code-Session aus:

• 4 vCPUs (Intel Xeon Cascade Lake @ 2,80 GHz)
• 16 GB RAM
• 252 GB Festplatte
• Linux-Kernel 6.18.5

Keine verschachtelte Virtualisierung übrigens. Firecracker entfernt bewusst die VMX/SVM-Flags, die es einem Gast-System erlauben würden, eigene VMs zu starten. Das ist eine sicherheitsbewusste Entscheidung, die Workloads konsequent voneinander isoliert.

Aber jetzt wird es richtig interessant: Es gibt kein systemd. Keinen SSH-Daemon. Keinen cron. Keine Logging-Infrastruktur. Die gesamte Prozesslandschaft sieht so aus:

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 (die CLI selbst)

Drei Prozesse. Mehr nicht. Der erste Prozess ist eine eigens entwickelte Binärdatei, die gleichzeitig als Init-System und WebSocket-API-Gateway fungiert. Er lauscht auf Port 2024 auf WebSocket-Verbindungen und auf Port 2025 für sekundäre Endpunkte.

Das ist durchdachte Infrastruktur-Architektur – alles Unnötige entfernt, um Angriffsfläche zu minimieren und Performance zu maximieren.

Die Snapshot-Architektur: Wo die Magie passiert

Die spannendste Entdeckung ist nicht die microVM selbst – sondern wie Sessions initialisiert werden.

Sessions booten nicht von Grund auf. Sie werden aus eingefrorenen Snapshots wiederhergestellt.

Als Forscher die Boot-Logs untersuchten, fanden sie eine Lücke von 48,5 Stunden zwischen dem Zeitpunkt, als die Template-VM erstellt wurde, und dem Zeitpunkt, als eine Session wiederhergestellt wurde:

[  30.731516] Run /process_api as init process
    ~~~ 48,5 STUNDEN LÜCKE — VM WURDE ALS SNAPSHOT EINGEFROREN ~~~
[174695.927758] virtio_blk: [vdc] new size: ...

Das ist im Grunde dasselbe Konzept wie SnapStart, das AWS Lambda populär gemacht hat. Das Template bootet einmal, initialisiert sich bis zu einem bereiten Zustand und wird dann als Snapshot eingefroren. Wenn du eine neue Session startest, stellt das System diesen Snapshot in Millisekunden wieder her – anstatt auf einen vollständigen Boot-Vorgang zu warten.

Das Hot-Swapping der Geräte während der Wiederherstellung ist besonders clever:

| Gerät | Template | Nach Wiederherstellung | Inhalt | |--------|----------|------------------------|--------| | vda | Platzhalter | 256 GiB ext4 | Session-Rootfs (Ubuntu 24.04) | | vdb | Platzhalter | 63,7 MB squashfs | /opt/claude-code | | vdc | Platzhalter | 12,1 MB squashfs | /opt/env-runner |

Das Root-Dateisystem ist ein dynamisch injiziertes Block-Gerät. Die Ubuntu-Umgebung sitzt auf einem ext4-Volume, das bei der Wiederherstellung ausgetauscht wird, während die Claude-Code-Tools und der Environment-Runner als squashfs-Overlays gemountet werden.

Dieser geschichtete Ansatz bedeutet, dass jede Session eine saubere, isolierte Umgebung bekommt – ohne den Overhead, das gesamte Dateisystem neu aufzubauen.

Was "Antspace" für den KI-Infrastruktur-Wettbewerb bedeutet

Hier wird die Sache richtig spannend: Beim Reverse Engineering stießen Forscher auf Hinweise, dass Anthropic intern offenbar eine Plattform namens "Antspace" aufbaut.

Wenn das stimmt, positioniert sich Anthropic als potenzieller PaaS-Konkurrent – ein Vercel für KI-native Anwendungen.

Denk mal darüber nach, was dort entsteht:

• Eine Runtime-Umgebung, die Authentifizierung, Prozessmanagement und WebSocket-Kommunikation übernimmt
• Isolierte microVM-basierte Ausführung mit starken Sicherheitsgrenzen
• Snapshot-basiertes sofortiges Deployment und Skalierung
• Eine API-first-Architektur für programmatische Steuerung

Das ist genau die Infrastruktur, die man braucht, um nicht nur Claude Code zu betreiben, sondern eine ganze Suite von KI-gestützten Entwicklungstools, Deployment-Pipelines und Hosting-Plattformen.

Die Sicherheitsarchitektur verdient Beachtung

Das Team hat sich offenbar gründlich Gedanken über Sicherheit gemacht. Bemerkenswerte Maßnahmen:

init_on_free=1 – Speicherseiten werden beim Freigeben genullt, was Datenlecks zwischen Sessions verhindert.

CRNG-Reseeding – Der kryptografische Zufallszahlengenerator wird nach der VM-Wiederherstellung neu gesät. Das ist entscheidend, weil Snapshots theoretisch dieselbe Entropie teilen könnten – was ein kryptografisches Problem wäre.

Capability-Dropping – Nach der Initialisierung gibt PID 1 die CAP_SYS_RESOURCE-Rechte ab. Selbst bei einer Kompromittierung sind die Möglichkeiten des Prozesses begrenzt.

--block-local-connections – Lokaler WebSocket-Zugriff auf localhost wird blockiert. Die Session kann sich nicht direkt mit Management-Interfaces verbinden.

JWT-Authentifizierung – WebSocket-Verbindungen erfordern verifizierte Tokens, und Secrets werden nach Gebrauch aus den Konfigurationen entfernt.

Das ist kein Sicherheits-Theater – das sind echte Härtungsmaßnahmen, die darauf hindeuten, dass diese Infrastruktur für Produktionsworkloads ausgelegt wurde.

Warum das für Entwickler relevant ist

Ob du KI-Tools, Coding-Agents oder Cloud-native Anwendungen baust – die Muster, die aus Claude Codes Infrastruktur hervorgehen, sind einen Blick wert:

1. Firecracker wird zum Standard für isolations-intensive Workloads. Wenn du zwischen Containern und microVMs abwägst, bietet Firecracker VM-Level-Sicherheit mit Container-Geschwindigkeit.

2. Snapshot-basierte Initialisierung ist die Zukunft für alles, was Sub-Sekunden-Startzeiten braucht. Dieses Muster verbreitet sich von Lambda auf Entwicklungsumgebungen.

3. Custom-Init-Systeme feiern ein Comeback. Wenn du den vollen systemd-Stack nicht brauchst, kann ein minimaler Custom-Supervisor schneller, sicherer und zielgerichteter sein.

4. KI-Unternehmen bauen Infrastruktur, die langfristig mit traditionellen Cloud-Providern konkurrieren könnte. Anthropics interne Plattform – falls real – repräsentiert eine massive Investition im Hosting-Bereich.

Das nächste Mal, wenn du Claude Code startest, nutzt du nicht einfach nur ein CLI-Tool. Du bekommst einen Blick auf KI-native Cloud-Infrastruktur, die definieren könnte, wie intelligente Anwendungen in den kommenden Jahren gebaut und deployed werden.

Das große Ganze

Das Beeindruckendste an dieser Entdeckung ist nicht die eine technische Einzelheit. Es ist der Beweis, dass KI-Unternehmen ernsthaft über den Full Stack nachdenken – nicht nur über Modelle, sondern über die Infrastruktur, um alles zu betreiben, was diese Modelle ermöglichen.

Anthropic baut nicht nur Claude. Sie bauen die Plattform-Schicht, die eine neue Generation von KI-nativen Anwendungen tragen könnte.

Und wenn "Antspace" real ist? Dann wird der Wettbewerb im KI-Hosting-Bereich verdammt spannend.

• Hast du Gedanken zu KI-Infrastruktur oder eigene Reverse-Engineering-Entdeckungen? Die Entwickler-Community lebt von solchen Gesprächen. Manchmal kommen die wertvollsten Erkenntnisse, wenn man unter die Haube schaut.*