Es gibt ein Muster, das ich bei fast jedem Team beobachte, das zum ersten Mal KI-Agenten baut. Die ersten Wochen verbringen sie damit, Token-Kosten zu optimieren. Sie A/B-testen System-Prompts. Sie implementieren Caching. Sie wechseln von GPT-4 zu GPT-4o-mini für einfache Anfragen. Sie bauen Dashboards, die Kosten pro Nachricht auf vier Dezimalstellen verfolgen.
Dann kommt die Cloud-Rechnung.
Sie ist höher als erwartet. Manchmal deutlich höher. Und wenn sie nachforschen, sind die Token-Kosten genau dort, wo sie sie vorhergesagt haben. Die Überraschung ist alles andere.
Die fünf Schichten der KI-Agenten-Kosten
Einen KI-Agenten in der Produktion zu betreiben ist keine einzelne Kostenstelle – es ist ein Stack aus fünf verschiedenen Kostenschichten.
Die erste Schicht sind Token-Kosten: was man dem KI-Anbieter pro Anfrage zahlt. Das ist die, über die alle reden, die zuerst optimiert wird und in vielen Fällen der kleinste Teil der Gesamtrechnung ist.
Die zweite Schicht sind Compute-Kosten: RAM, CPU und Server-Infrastruktur, die die Agent-Runtime hostet. Hier trifft die erste Überraschung. Eine Runtime, die im Leerlauf 1,2 GB RAM verbraucht, kostet nicht nur mehr im Hosting – sie schränkt jede nachgelagerte Architekturentscheidung ein.
Die dritte Schicht sind Cold-Start-Kosten, und diese sind heimtückisch, weil sie auf keiner Rechnung erscheinen. Cold-Start-Zeit ist die Verzögerung zwischen dem Empfang einer Nachricht und der Bereitschaft des Agenten, sie zu verarbeiten. Wenn diese Verzögerung 8 Sekunden beträgt, werden manche Nutzer annehmen, der Bot sei kaputt, und gehen. Das ist Churn, und Churn hat Kosten.
Die vierte Schicht sind Betriebskosten: die Engineering-Stunden für Monitoring, Debugging, Dependency-Updates und Incident-Response. Eine Runtime mit 1.200 npm-Abhängigkeiten hat nicht nur eine größere Angriffsfläche – sie hat eine größere Wartungsfläche.
Die fünfte Schicht sind Opportunitätskosten: die Dinge, die man nicht bauen kann, weil die Infrastruktur bereits ausgelastet ist. Wenn die Agent-Runtime im Leerlauf 60 % des Server-RAMs verbraucht, experimentiert man nicht mit Multi-Agent-Architekturen.
Die RAM-Steuer: Was 1,2 GB wirklich kostet
OpenClaw verbraucht im Leerlauf etwa 1,2 GB RAM. Das ist keine Bug oder Fehlkonfiguration – es ist die natürliche Konsequenz des Betriebs einer Node.js-Anwendung mit einem großen Dependency-Tree.
Auf Cloud-Infrastruktur sieht das so aus: Ein 1-GB-RAM-VPS – die günstigste Stufe bei den meisten Anbietern, typischerweise 5–6 €/Monat – kann OpenClaw überhaupt nicht ausführen. Ein 2-GB-RAM-VPS (10–12 €/Monat) kann OpenClaw technisch ausführen, aber man verwendet 60 % des verfügbaren Speichers im Leerlauf. Ein 4-GB-RAM-VPS (20–24 €/Monat) ist, wo OpenClaw wirklich komfortabel läuft.
ZeroClaw, in Rust gebaut, verbraucht im Leerlauf etwa 4 MB RAM. Derselbe 5-Euro-VPS läuft ZeroClaw mit 99,6 % RAM noch verfügbar. Die jährliche Ersparnis beim Hosting allein: 84 bis 228 €.
Für Teams, die mehrere Agenten betreiben, wird die Rechnung dramatisch. Zehn OpenClaw-Instanzen brauchen einen dedizierten Server für 100 €+/Monat. Zehn ZeroClaw-Instanzen passen komfortabel auf einen 5-Euro-VPS.
Cold Starts: Die Kosten, die nicht auf Rechnungen erscheinen
Cold-Start-Zeit ist in zwei Szenarien wichtig.
Das erste ist Serverless- und Edge-Deployment. Wenn der Agent auf null skaliert, wenn er im Leerlauf ist, zahlt jede erste Anfrage nach einer Leerlaufperiode die Cold-Start-Strafe. Für OpenClaw beträgt diese Strafe etwa 8 Sekunden. In UX-Forschung verursachen Antwortzeiten über 3 Sekunden einen messbaren Anstieg der Abbruchrate.
Das zweite Szenario sind Neustarts. Abstürze passieren. Updates erfordern Neustarts. Ein Agent, der in 10 Millisekunden neu startet, ist effektiv immer verfügbar. Ein Agent, der 8 Sekunden zum Neustart braucht, schafft ein Verfügbarkeitsfenster, das sich über ein Jahr zu Stunden an Ausfall summiert.
Zur Referenz: OpenClaw braucht ~8 s zum Starten, PicoClaw ~3 s, ZeroClaw unter 10 ms.
Die Abhängigkeits-Steuer: 1.200 Pakete und was sie wirklich kosten
OpenClaws node_modules-Verzeichnis enthält über 1.200 Pakete. Jedes davon ist eine echte, laufende Kostenstelle.
Aus Sicherheitsperspektive ist jedes Paket eine potenzielle Schwachstelle. Die ClawHub-Supply-Chain-Angriffe von Anfang 2026 nutzten genau das aus. Aus Wartungsperspektive ist es ein Teilzeitjob, 1.200 Pakete kompatibel zu halten. Jedes `npm update` ist eine potenzielle Debugging-Session.
ZeroClaw wird als einzelnes statisch gelinktes Binary ausgeliefert. Kein Paketmanager. Kein Lockfile. Kein Dependency-Resolution. Deployment bedeutet, eine 12-MB-Datei auf den Server zu kopieren und auszuführen.
Die Zahlen
Für einen einzelnen Always-On-KI-Agenten mit etwa 1.000 Nachrichten pro Tag:
| Kostenkategorie | OpenClaw | ZeroClaw | |----------------|----------|----------| | Hosting (VPS) | 288 €/Jahr (4 GB nötig) | 60 €/Jahr (1 GB ausreichend) | | Token-Kosten | 180 €/Jahr | 180 €/Jahr | | Engineering-Wartung | ~1.200 €/Jahr (2 h/Monat) | ~150 €/Jahr (15 min/Monat) | | Cold-Start-Auswirkung | ~200 €/Jahr (gesch. Churn) | Vernachlässigbar | | Gesamt | ~1.868 €/Jahr | ~390 €/Jahr |
Die Token-Kosten sind identisch. Die jährliche Lücke von 1.478 € ist vollständig Infrastruktur- und Betriebsaufwand.
Die Architektur-Implikationen
Die Ressourceneigenschaften der Agent-Runtime sind nicht nur operative Details – sie prägen, was man bauen kann.
Eine Runtime, die 4 GB RAM braucht, kann nicht auf einem Raspberry Pi laufen. Sie kann nicht auf einem 5-Euro-VPS laufen. Sie kann nicht auf Edge-Nodes nahe bei Nutzern deployed werden. Jede dieser Einschränkungen ist eine Produktentscheidung, die die Runtime für einen trifft, bevor man eine einzige Zeile Anwendungscode geschrieben hat.
Eine Runtime, die 4 MB RAM verwendet und in 10 Millisekunden startet, kann überall laufen. Die Architektur wird zur Wahl statt zur Einschränkung.