KI-Agenten selbst hosten oder hosten lassen: die ehrliche Rechnung

Einen KI-Agenten selbst zu hosten ist technisch kein Hexenwerk: ein Linux-Server, ein Python-Prozess, ein API-Schlüssel oder ein lokales Modell über Ollama, fertig. Die Rechnung geht trotzdem oft nicht auf, und zwar nicht wegen der Hardware. Ein Coding-Agent, der Dateien schreibt, Git bedient und ein Terminal hat, ist ein Prozess, der beliebigen Code auf deinem Server ausführt. Alles, was danach kommt (Sandbox, Speichergrenzen, Schlüsselverwaltung, Schleifenschutz, Sicherungen), musst du selbst bauen oder betreiben. Genau diese Posten zählt dieser Beitrag durch, mit den Zahlen aus unserem eigenen Betrieb bei Hetzner in Nürnberg. Am Ende steht keine Kaufempfehlung, sondern eine Entscheidungstabelle.

Was „Agent" hier heißt

Der Begriff wird für vieles benutzt. Hier geht es um die anspruchsvolle Sorte: einen Coding-Agenten, der in einer Schleife arbeitet.

• Werkzeuge: Der Agent liest und schreibt Dateien, ruft Git auf, startet Befehle im Terminal, öffnet einen Browser. Bei UltraNOS sind das je nach Betriebsart 7 bis 38 Werkzeuge pro Sitzung.
• Schleifen: Denken, handeln, prüfen, wieder von vorn. Ein Zug kann dutzende Werkzeugrunden dauern; im Langlauf-Modus ist die Rundenzahl gar nicht mehr gedeckelt.
• Sub-Agenten: Der Chat-Agent kann weitere Agenten starten, die parallel arbeiten. Bei uns gilt: Tiefe höchstens 2, höchstens 16 gleichzeitige Aufträge, Rückruf-Tiefe 8.

Ein Chatbot, der nur Text zurückgibt, braucht nichts davon. Ein Agent mit Terminal braucht alles davon, und jeder dieser Punkte ist eine Stelle, an der ein Server umkippen kann.

Die Hardware-Rechnung

Die erste Frage beim Self-Hosting ist nicht „welcher Server", sondern „wo rechnet das Modell".

Variante A: lokales Modell

Mit Ollama läuft das Modell auf deiner Hardware. Vorteil: Prompts verlassen den Rechner nicht, keine Kosten je Anfrage. Nachteil: Die Modellgewichte plus Kontextfenster müssen in RAM oder VRAM passen, und ein Coding-Agent füllt sein Kontextfenster schnell mit Dateiinhalten und Terminalausgaben. Die konkreten Speicherangaben je Modell stehen in der Modellbibliothek auf ollama.com; sie liegen für brauchbare Coding-Modelle deutlich über dem, was ein kleiner VPS mitbringt.

Variante B: API-Modell

Das Modell läuft beim Anbieter, dein Server orchestriert nur. So fahren wir: Die Produktion von UltraNOS hat 8 GB RAM und rechnet kein einziges Modell selbst. Der Speicher geht stattdessen für das drauf, was der Agent auslöst: Git-Klone, npm run build, Test-Läufe, Playwright-Browser.

Ein Beispiel aus unserer Entwicklungs-VM: Zwei Playwright-Browser gleichzeitig für einen Mobil-Test, und der OOM-Killer des Kernels räumt ab. Wir messen Firefox und Chromium deshalb nacheinander. Das ist die Sorte Erfahrung, die in keiner Anleitung zum „KI-Agent VPS" steht.

Posten	Lokales Modell	API-Modell
RAM für das Modell	Gewichte + Kontext, je Modell laut ollama.com	0
RAM für Agenten-Arbeit (Builds, Klone, Browser)	zusätzlich nötig	bei uns: die ganzen 8 GB
Kosten je Anfrage	0	je Anbieter
Prompts verlassen den Server	nein	ja, zum gewählten Anbieter
Grafikkarte sinnvoll	ja	nein

Platte: das unterschätzte Thema

Ein Coding-Agent klont Repositories. Unser Zielwert ist, dass ein einzelnes Repo mit 50 GB mühelos passt. Deshalb ist bei UltraNOS der Teilklon die Vorgabe (umfang teil, flach oder voll, plus Sparse-Pfade), und Git-LFS wird beim Klonen übersprungen. Die Arbeitsbereiche liegen auf einem eigenen Volume von 145 GB, das rund 10 € im Monat kostet und mit Löschschutz versehen ist. Wer selbst hostet, muss diese Entscheidung ebenfalls treffen, bevor der erste Agent git clone auf ein Monorepo loslässt.

Sicherheits-Pflichten, die dir niemand abnimmt

Hier liegt der eigentliche Aufwand. Ein Agent mit Terminal ist ein Nutzer mit Shell-Zugang, der nicht müde wird und Anweisungen aus Dateien für Befehle halten kann. Was wir dafür gebaut haben, steht in der Dokumentation, und jeder Punkt war eine Lektion.

Sandbox

Terminal, Builds und Skript-Ausführung laufen bei uns in bubblewrap (bwrap), mit einer eigens aufgebauten Umgebung statt der Umgebung des Dienstes. Der Auslöser war ein Fund: Der Bau-Reiter lief als letzter Weg ohne Sandbox und reichte mit {**os.environ} sämtliche Anbieter-Schlüssel an npm run build durch. Ein einziges bösartiges Build-Skript hätte gereicht.

Ehrlicherweise ist auch das nicht fertig: Umgebungswerte für die Sandbox landen heute noch per --setenv in der Argumentliste des bwrap-Prozesses, wo unsandboxte Host-Prozesse sie lesen könnten. Der Weg über einen Dateideskriptor ist bekannt und steht auf der Liste.

Lastgrenzen für jeden Kindprozess

Vor jedem exec setzt engine/lastgrenzen.py harte Grenzen in vier Profilen (interaktiv, Dienst, Bau, kurz): Rechenzeit, Dateigröße, Prozesszahl, Deskriptoren. Drei Details, die man beim Selbstbau erst nach dem Ausfall lernt:

1. Speicher über cgroup, nicht über RLIMIT_AS. Die Adressraumgrenze tötet Node und die JVM, die große virtuelle Bereiche reservieren, ohne sie zu nutzen.
2. RLIMIT_NPROC misst im Benutzer-Namensraum, /proc zeigt aber nur den PID-Namensraum. Auf einer VM sahen wir 1001 Prozesse gegen etwa 2500 echte. Eine feste Formel „sichtbar plus 64" war dort keine Grenze, sondern eine Startsperre.
3. PID-Wiederverwendung: Vor jedem Gruppen-Kill prüft die Lastwache die Startzeit aus /proc/<pid>/stat. Sonst trifft der Abschuss irgendwann den falschen Prozess.

Lastwache

Grenzen je Prozess reichen nicht, weil die Summe trotzdem den Host füllt. Die Lastwache prüft alle 15 Sekunden freien Plattenplatz und MemAvailable, sperrt neue Starts unter der Reserve und schießt bei Speichernot den größten selbst gestarteten Prozessbaum ab, bevor der OOM-Killer des Kernels wahllos zuschlägt. Alle 10 Minuten werden die Arbeitsbereiche nachgemessen. Das Terminal ist auf 512 KB/s Ausgabe gedrosselt, pro Mandant gibt es höchstens 8 Terminals.

Schleifenschutz

Agenten drehen sich im Kreis. Die Schleifenwache vergleicht Paare aus Werkzeugaufruf und Ergebnis: Beim dritten gleichen Aufruf gibt es einen Hinweis, ab dem fünften wird nicht mehr ausgeführt; Oszillation zwischen zwei Zuständen wird eigens erkannt. Jeder Zug hat ein Zeitbudget, Vorgabe 45 Minuten. Dazu kommen vier eingebaute Guards (no-rm-rf, no-force-push, no-drop-table, no-curl-pipe-bash) plus eigene Regex-Regeln. Wer selbst hostet, hat nichts davon, bis er es schreibt.

Was auch wir nicht gelöst haben

Prompt Injection steht bei uns offen in der Liste: Das Modell unterscheidet Daten nicht von Aufträgen, und Inhalte aus geklonten Fremd-Repos, E-Mails oder Webseiten können Anweisungen enthalten. Eine Erkennung funktioniert nicht zuverlässig; der erreichbare Schritt ist, Werkzeuge mit Außenwirkung hinter eine Bestätigung zu stellen. Diese Pflicht hast du auf dem eigenen Server genauso.

Schlüssel: Tresor und Schwärzung

Ein Agent arbeitet mit Geheimnissen: API-Schlüssel, Git-Tokens, SSH-Schlüssel, Passwörter für Server. Zwei Fragen musst du beim Self-Hosting beantworten.

Wo liegen die Schlüssel? Bei UltraNOS in einem verschlüsselten Tresor; zwölf Dienste hängen daran. Ein Wächter (engine/kek_wache.py) bricht den Start ab, wenn der Schlüssel zum Entschlüsseln fehlt, aber Chiffrate vorhanden sind. Vorher gab es an dieser Stelle einen stillen Neuanfang, also einen leeren Tresor ohne Fehlermeldung. Beim Selbstbau ist eine .env-Datei der übliche Weg, und die landet erfahrungsgemäß irgendwann in einem Chat oder einem Commit.

Was sieht das Modell? Alles, was im Prompt steht. Bei UltraNOS greift vor dem Senden die Schwärzung cloak: 27 Präfixregeln für bekannte Anbieter (sk-ant-…, ghp_…, glpat-…), 13 strukturelle Regeln für Zuweisungen, Header und Verbindungsstrings, dazu E-Mail-Adressen und Tresorwerte. Aus dem Schlüssel wird ein Platzhalter der Form CLOAK_SECRET_…, das Modell arbeitet damit, die Rückübersetzung passiert erst bei der Werkzeugausführung. Das Profil enforce ist Vorgabe; fehlt das Paket, scheitert der Zug lesbar statt Klartext zu senden.

Die Grenzen stehen dazu: Auf dem CLI-Weg über Claude Code werden nur Prompt und System-Prompt verhüllt, weil die CLI ihre Werkzeuge selbst ausführt. Unbekannte Formate ohne Präfix und ohne Kontext gehen durch. Ob der Schutz läuft, zeigt GET /api/health im Feld cloak. Mehr dazu in API-Keys im Prompt schützen.

Kostenvergleich: VPS gegen gehostet

Die Modellkosten fallen in beiden Fällen an und hängen vom Anbieter ab. Der Unterschied liegt bei Server und Zeit.

Posten	Eigener VPS	UltraNOS gehostet
Server	Preis laut hetzner.com, für Agenten-Arbeit mit Builds mindestens die Klasse mit 8 GB RAM	im Tarif enthalten
Volume für Repos	Beispiel: 145 GB rund 10 €/Monat	Starter 200 MB, Pro 5 GB, Team unbegrenzt
Firewall, Updates, Sandbox, Lastgrenzen	deine Zeit, jeden Monat	im Betrieb
Schlüsseltresor, Schwärzung	selbst bauen oder auf .env vertrauen	cloak im Profil enforce
Sicherungen	selbst einrichten	Systemplatte gesichert; das Volume der Arbeitsbereiche steht bei uns noch offen (borg ist der nächste Schritt)
Modellkosten	je Anbieter	je Anbieter
Preis	Server + Volume + Stunden	Starter 0 €, Pro 19 €/Monat, Team 49 €/Monat

Die Stunden sind der Posten, den jeder unterschätzt. Setz einen ehrlichen Wert für deine Arbeitszeit ein und rechne, wie viele Stunden im Monat ein Server mit ausführendem Agenten braucht: Kernel-Updates, ein kaputter Build, der die Platte füllt, ein Agent in der Schleife, der nachts die CPU auf 100 % hält. Wenn diese Zahl über der Differenz zu 19 € liegt, ist die Entscheidung gefallen.

Was „gehostet" hier konkret heißt: Serverstandort Nürnberg, der Webhost hinter einer Cloud-Firewall, die aus dem Internet nur Port 80 und 443 durchlässt, AV-Vertrag verfügbar. Die Prompts gehen weiterhin an den Modellanbieter, den du wählst.

Entscheidungshilfe

Wenn du …	dann …
ein lokales Modell willst, weil Prompts den Rechner nicht verlassen dürfen	Self-Hosting mit Ollama, auf Hardware mit genug RAM oder VRAM
Linux-Server ohnehin betreibst und Spaß an cgroups hast	Self-Hosting, mit der Pflichtenliste oben als Vorlage
einen Coding-Agenten mit Editor, Git und Terminal willst, aber keinen zweiten Job als Admin	gehostet
mit einem Team an denselben Repos arbeitest	gehostet (Team) oder ein ernsthaft betreuter eigener Server
erst mal sehen willst, ob Agenten für dich taugen	Starter für 0 € bei ultranos.de, 14 Tage die vollen Funktionen testen

Wer Open WebUI und ähnliche Oberflächen für ein reines Chat-Frontend sucht, findet den Vergleich in Open-WebUI-Alternativen 2026. Das ist eine andere Aufgabe als ein Agent mit Terminal.

FAQ

Wie kann ich KI-Agenten selbst erstellen?

Im Kern brauchst du ein Modell mit Werkzeugaufrufen, eine Schleife (denken, handeln, prüfen) und die Werkzeuge selbst: Datei lesen und schreiben, Befehl ausführen, Git. Das ist an einem Wochenende gebaut. Die Arbeit beginnt danach: Sandbox, Speicher- und Prozessgrenzen, Schleifenerkennung, Schlüsselverwaltung. Rechne diese Punkte von Anfang an mit ein, sonst hast du einen Agenten, der an Tag drei den Server füllt.

Welche Plattform eignet sich für KI-Agenten?

Das hängt davon ab, ob du eine Bibliothek zum Selbstbauen oder einen fertigen Arbeitsplatz willst. Für den Selbstbau sind Ollama plus ein Framework deiner Wahl der übliche Weg. UltraNOS ist der fertige Arbeitsplatz im Browser: Chat, Monaco-Editor, Git, Terminal und Agenten in einer Oberfläche, mit frei wählbarem Modellanbieter (Claude über API oder CLI, OpenAI-kompatibel, Ollama, eigener Endpunkt). Self-Hosting ist optional und auf Anfrage möglich.

Kann ich einen KI-Agenten kostenlos erstellen?

Der Starter-Tarif von UltraNOS kostet 0 €. Ob Modellkosten anfallen, hängt vom gewählten Anbieter ab: Ein lokales Modell über Ollama kostet nichts je Anfrage, braucht aber eigene Hardware. Ein Agent, der wirklich Code schreibt und testet, verbraucht deutlich mehr Tokens als ein Chat, weil Dateiinhalte und Terminalausgaben in jedem Zug mitlaufen.

Wie viel RAM braucht ein selbst gehosteter KI-Agent?

Mit API-Modell fährt unsere Produktion mit 8 GB, und die gehen komplett für Builds, Klone und Browser drauf, nicht für das Modell. Mit lokalem Modell kommen die Modellgewichte plus Kontextfenster obendrauf; die Werte je Modell stehen bei ollama.com. Wichtiger als die Zahl ist die Grenze: Ohne cgroup-Deckel je Kindprozess entscheidet der OOM-Killer, was überlebt.

Läuft ein Coding-Agent mit einem lokalen Modell über Ollama?

Ja, Ollama ist bei UltraNOS als Anbieter wählbar, auch die Schwärzung cloak greift auf diesem Weg. Ob die Ergebnisse taugen, hängt vom Modell ab: Ein Agent braucht zuverlässige Werkzeugaufrufe, und ein Modell ohne diese Fähigkeit kann über eine Aufgabe nur reden, statt sie auszuführen. In der Modellliste wird das deshalb als Warnung angezeigt.

Für wen Self-Hosting richtig bleibt

Self-Hosting ist die richtige Wahl, wenn Prompts den eigenen Rechner nicht verlassen dürfen, wenn du eine Grafikkarte hast, die sich langweilt, oder wenn Serverbetrieb für dich kein Aufwand, sondern Hobby ist. Dann ist die Pflichtenliste oben keine Abschreckung, sondern eine Vorlage, und du bekommst ein System, das du bis in den Kernel hinein verstehst.

Für alle anderen ist die ehrliche Rechnung: Der Server ist der kleinste Posten. Die Zeit für das, was ein ausführender Agent an Schutz braucht, ist der größte. Und wer das nicht glaubt, kann bei uns nachlesen, wie viele der Punkte oben wir erst nach einem Ausfall gebaut haben.

Schlüssel bleiben bei dir — der Rest im Browser.

UltraNOS ist die Agentic Web IDE: mehrere KI-Agenten parallel, Editor, Git und Terminal. cloak ersetzt API-Schlüssel und Passwörter, bevor ein Prompt den Anbieter erreicht. Gehostet in Nürnberg, 14 Tage kostenlos.

14 Tage testen →