Ein Coding-Agent auf deinem Laptop stoppt in dem Moment, in dem du den Deckel schließt. Was für eine schnelle Bearbeitung in Ordnung ist — und still frustrierend in dem Moment, in dem du willst, dass er sich durch ein langes Refactoring mahlt, eine Test-Suite durchackert oder weitermacht, während du etwas anderes tust. Verschieb ihn auf einen Server und diese Einschränkung verschwindet einfach: er arbeitet, während du schläfst, übersteht das Wegfallen deines WLANs und übergibt dir das Ergebnis, wenn du zurück bist. Das deckt ab, welcher VPS tatsächlich zu einem Coding-Agenten passt — Claude Code, Cursors CLI, Cline, OpenCode oder aider — was zu zahlen ist und wie du ihn am Laufen hältst, ohne KYC und mit Krypto-Zahlung.
Was „auf einem Server“ dir tatsächlich bringt
- Er stoppt nicht. Eine lange Aufgabe läuft bis zum Abschluss, unabhängig von deinem Laptop.
- Reinraum. Der Agent bekommt eine reproduzierbare Umgebung; deine Maschine bleibt frei von Build-Müll und halb installierten Abhängigkeiten.
- Isolation. Ein Agent mit Shell-Zugriff ist mächtig. Weit besser, er hat diese Macht auf einer Wegwerf-Maschine als neben deinen Fotos und SSH-Schlüsseln.
Der letzte Punkt ist unterschätzt: ein VPS ist das sicherere Zuhause für einen autonomen Agenten, gerade weil er separat ist.
Richtig dimensionieren
Der Agent selbst ist leicht — er ruft ein Modell über eine API auf, also passiert das Denken woanders (derselbe Grund, warum die meisten KI-Agenten wenig RAM brauchen). Was tatsächlich Ressourcen verbraucht, ist die Toolchain deines Projekts: ein großer Build, ein schwerer Testlauf, eine lokale Datenbank. Dimensioniere also für das Projekt, nicht für den Agenten:
- 2 GB / 2 Kerne — bequem für den Agenten + einen git-Checkout + leichte Builds.
- 4 GB — ein sicherer Standard für echte Projekte mit ordentlichen Test-Suites.
- Mehr nur, wenn dein Build wirklich hungrig ist oder du mehrere Agenten gleichzeitig betreibst.
Welcher Plan passt — und wie du zahlst
Für einen einzelnen Coding-Agenten an einem echten Projekt ist der Sweetspot 4 vCPU / 4 GB — Platz für den Agenten plus deine Build- und Test-Suite. Bei EQVPS ist das der KI-Agent-Plan (10 $/Mon.); eine 2-GB-Maschine ist für leichte Repos in Ordnung, skaliere nur hoch, wenn deine Tests schwer sind oder du mehrere Agenten gleichzeitig betreibst.
Zwei praktische Entscheidungen:
- NAT, nicht dedizierte IP. Ein Coding-Agent macht nur ausgehende Aufrufe — Modell-API, git, Paket-Registries — also ist ein NAT-Plan mit portweitergeleitetem SSH alles, was er braucht, und er ist günstiger. Greif zu einem Plan mit dedizierter IP nur, wenn du auch etwas hostest, mit dem sich andere verbinden (einen Webhook-Empfänger, einen Preview-Server).
- Ohne KYC, in Krypto bezahlt. Registriere dich mit einer E-Mail und zahle in USDC oder USDT auf Base oder Ethereum — keine Karte, kein Ausweis. Nützlich, wenn du Wegwerf-Maschinen pro Agent hochfährst und nicht willst, dass jede an deine Identität gebunden ist. Eine Karte funktioniert auch, aber die Auffahrt hat ein ~27-$-Minimum, also ist es für günstige Pläne reibungsloser, einmal ein kleines Guthaben aufzuladen.
Es ist reine CPU und läuft aus einem einzelnen Rechenzentrum in Deutschland — gut für einen Coding-Agenten (das schwere Denken ist auf der Seite des Modellanbieters), gut zu wissen, wenn du speziell eine GPU oder eine andere Region brauchst.
In Betrieb nehmen
Per SSH einloggen, deine Toolchain und den Agenten einrichten (Claude Code, Clines CLI, aider — was auch immer du nutzt), dein Repo klonen und deinen API-Schlüssel exportieren:
export ANTHROPIC_API_KEY=... # oder der Schlüssel deines Anbieters
cd ~/myproject
Jetzt der Schlüsseltrick — führe ihn nicht in einer nackten SSH-Sitzung aus, sonst stirbt er, wenn du dich trennst. Führe ihn innerhalb von tmux aus:
sudo apt install -y tmux
tmux new -s agent
# innerhalb von tmux: starte deinen Coding-Agenten, richte ihn auf die Aufgabe
# dann abhängen mit: Ctrl-b, dann d
Abhängen, Laptop schließen, zum Mittagessen gehen. Der Agent arbeitet auf dem Server weiter. Komm zurück und tmux attach -t agent, um zu sehen, was er getan hat. Für geplante, unbeaufsichtigte Läufe (z. B. einen nächtlichen Wartungsdurchlauf) verpack ihn stattdessen in einen systemd-Dienst — dasselbe Muster wie jeden Prozess am Leben halten.
Die ehrlichen Vorbehalte
- Gib ihm eine Sandbox, nicht die Schlüssel zum Königreich. Nutze einen Nicht-root-Benutzer, halte ihn in einem git-Repo (jede Änderung überprüfbar und rückgängig machbar), und lege keine Produktions-Zugangsdaten auf die Maschine. Autonomie plus Shell-Zugriff plus Unachtsamkeit ist, wie Unfälle passieren.
- Behalte deinen Token-Verbrauch im Auge. Ein langlaufender Agent, der ein Modell in einer Schleife aufruft, kostet echtes API-Geld — setze Limits und schau vorbei. Der Server ist günstig; die Inferenz ist, was sich summiert.
- Es ist keine Magie. Ein Hintergrund-Agent ist großartig für gut abgegrenzte, verifizierbare Aufgaben. Richte ihn auf etwas Vages und Unbeaufsichtigtes und du kommst zu selbstbewusstem Unsinn zurück. Grenze eng ab.
Innerhalb dieser Leitplanken ist ein Coding-Agent auf seinem eigenen Server ein wirklich nützliches Muster — deine Arbeit läuft weiter, ob du es tust oder nicht. Fahr eine 4-GB-Maschine hoch, wirf tmux und deinen Agenten hinein und lass ihn kochen. Der Agent kann den Server sogar selbst über MCP mieten, wenn du die ganze Schleife autonom willst.
Kommentare
Noch keine Kommentare. Sei der Erste.