Agentlas OS 1.2.0 auf einem Linux-VPS selbst hosten

Was Agentlas OS tatsächlich ist

Agentlas OS ist eine Open-Source-Agentenlaufzeitumgebung. Sie speichert spezialisierte Agenten als Pakete auf dem Datenträger und stellt für jede Aufgabe einen temporären Orchestrator zusammen. Sie hosten die Software selbst, indem Sie sie in Ihrem eigenen Benutzerkonto auf einem Linux-VPS installieren. Sie ist kein Dienst. Es gibt keinen Daemon, keinen lauschenden Port, keine Weboberfläche und kein Container-Image im Repository.

Dieser letzte Satz bestimmt alles Weitere auf dieser Seite. Die meisten Multi-Agent-Systeme führen einen Supervisor-Prozess aus, der dauerhaft aktiv bleibt und die Agenten enthält. Agentlas kehrt dieses Modell um: Die spezialisierten Agenten liegen als Dateien auf dem Datenträger, und der Orchestrator existiert nur während der Ausführung einer Aufgabe. Das bedeutet in der Praxis, dass ein inaktiver Hub Speicherplatz auf dem Datenträger, aber keinen Arbeitsspeicher benötigt.

Das Projekt bezeichnet seinen offenen Kern als Hephaestus. Dieser Name erscheint in Befehlen, Pfaden und Umgebungsvariablen. Das Repository ist agentlas-ai/Agentlas-OS, steht unter der Lizenz Apache-2.0 und ist größtenteils in Python geschrieben.

Wie früh ist dieses Projekt wirklich

Das Repository wurde am 4. Juni 2026 erstellt. Am 12. August 2026 ist es etwa zehn Wochen alt und hat ungefähr 1,150 Stars sowie 112 Forks. Das ist jung für ein Projekt, das Sie auf reale Aufgaben ansetzen.

Die Veröffentlichungsfrequenz ist wichtiger als das Alter. Version v1.1.103 wurde am 8. August 2026 veröffentlicht, und v1.2.0 folgte am 12. August 2026. In der 1.1-Serie gibt es damit mehr als hundert getaggte Releases, an manchen Tagen mehrere, die automatisiert veröffentlicht wurden. Ein Projekt, das sich so schnell weiterentwickelt, kann sein Verhalten zwischen Dienstag und Donnerstag ändern.

Pinnen Sie daher das Release. Der Installer liest dafür eine Umgebungsvariable, und die gesamte folgende Anleitung verwendet diese Variable. Bei einer nicht gepinnten Installation eines Projekts, das mehrmals täglich veröffentlicht, erhalten Sie genau den Stand, der in dieser Stunde auf main vorhanden war.

Was Sie auf dem VPS benötigen

Die Anforderungen sind gering, weil im Hintergrund nichts läuft.

• Ein Linux-VPS. Ubuntu 24.04 ist eine geeignete Ausgangsbasis. Das Installationsprogramm ermittelt das Betriebssystem mit uname -s und verwendet unter Linux einen Nicht-macOS-Zweig. Daher wird auch ein Rechner ohne grafische Oberfläche unterstützt.
• curl, tar und git auf dem Rechner sowie ein funktionsfähiger Python-Interpreter.
• Ausgehendes HTTPS zu raw.githubusercontent.com und github.com. Das Installationsprogramm lädt ein Release-Archiv herunter und prüft dessen SHA-256-Hash. Ein Rechner ohne ausgehende Netzwerkverbindung kann die Installation daher nicht durchführen.
• Ein Host-Harness. Dabei handelt es sich um den Coding-Agent, der tatsächlich mit einem Modell kommuniziert. Claude Code, Codex, opencode, goose und Hermes werden als Adapter unterstützt.

Sie benötigen keine root-Berechtigungen. Das Installationsprogramm schreibt nur in Ihr Home-Verzeichnis und nach ~/.local/bin. Wenn ein Pfad nicht beschreibbar ist, gibt es eine Warnung aus, statt abzubrechen. Wenn Sie den Rechner selbst noch auswählen, beschreibt einen Coding-Agent auf einem VPS ausführen die zugrunde liegende Image- und Zugriffskonfiguration.

Installieren Sie die festgelegte Release-Version

Die Upstream-README dokumentiert eine einzelne Zeile, die ein Skript aus main direkt an bash weiterleitet. Laden Sie das Skript herunter und lesen Sie es zuerst. Es schreibt in Ihre Shell-Konfiguration und in jedes Agent-Harness, das es findet. Dafür sollten Sie sich zehn Sekunden Zeit nehmen.

curl -fsSL -o install-all-runtimes.sh \
  https://raw.githubusercontent.com/agentlas-ai/Agentlas-OS/main/scripts/install-all-runtimes.sh
less install-all-runtimes.sh
HEPHAESTUS_REF=v1.2.0 bash install-all-runtimes.sh

HEPHAESTUS_REF ist die festgelegte Version. Im Skript lautet die Zeile version="${HEPHAESTUS_REF:-v1.2.0}". Wenn die Variable nicht gesetzt ist, erhalten Sie heute zufällig v1.2.0 und nächste Woche möglicherweise eine andere Version. Setzen Sie sie explizit. Dann installiert Ihr Rebuild im Oktober genau die Version, die Sie im August getestet haben.

Eine Einschränkung bleibt: Die Skript-URL oben folgt main, während HEPHAESTUS_REF die Runtime-Nutzdaten festlegt, die das Skript herunterlädt. Das sind zwei verschiedene Dinge. Um beides festzulegen, laden Sie das Skript vom Tag statt von main. Ersetzen Sie dazu main in dieser URL durch v1.2.0.

Bei einem erfolgreichen Lauf werden die geschriebenen Pfade ausgegeben, darunter diese beiden Zeilen:

Installed runner: /home/you/.agentlas/runtime/current/bin/hephaestus
Installed shell commands in /home/you/.local/bin (add ~/.local/bin to PATH to use them)

Die zweite Zeile wird häufig übersehen. Auf einem frischen Ubuntu-System fehlt ~/.local/bin häufig in PATH. Dann schlägt jeder hep-*-Befehl mit command not found fehl, obwohl die Installation erfolgreich war. Beheben Sie das und prüfen Sie die Konfiguration:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
hep-global status

hep-global status zeigt an, was der globale Router installiert hat und welche Harnesses er erkannt hat. Wenn der Befehl überhaupt ausgeführt wird, ist PATH korrekt.

Wo der Zustand gespeichert wird

Alles liegt als Datei in Ihrem Home-Verzeichnis. Dadurch werden Sicherung und Migration einfach.

• ~/.agentlas/runtime/v1.2.0/ enthält die Laufzeitumgebung selbst. ~/.agentlas/runtime/current/ ist ein Symlink auf die aktive Version. Zwei festgelegte Versionen können parallel vorhanden sein.
• ~/.local/bin/ enthält die Shell-Wrapper: hephaestus, hep-build, hep-network, hep-search, hep-storm, hep-cloud und hep-upload.
• ~/.agentlas/networking/memory/ enthält den dauerhaft gespeicherten Zustand: playbook-registry.json, playbook-candidates.jsonl und memory-events.jsonl.
• ~/.agentlas/networking/hub-agents/<slug>/memory/experience.sqlite enthält die agentenspezifischen Erfahrungen, nach Besitzer abgegrenzt.
• <project>/.agentlas/ontology-runtime.sqlite enthält den projektspezifischen Zustand. Dadurch wird er zusammen mit dem Repository übertragen und bleibt nicht an den Server gebunden.
• ~/.cache/agentlas/python enthält den Python-Cache unter Linux. macOS verwendet einen anderen Pfad. Der Installer wählt diesen Pfad über uname.

Die Dokumentation zum Speicher legt ausdrücklich fest, dass Secrets, unverschlüsselte Zugangsdaten und vollständige Transkripte in keinem Speicherbereich abgelegt werden dürfen. Zugangsdaten bleiben in lokalen, von gitignore ausgeschlossenen Dateien. Die Speicherprotokolle enthalten nur Namen und Pfade. Sichern Sie ~/.agentlas und die .agentlas-Verzeichnisse Ihrer Projekte. Dann können Sie die Umgebung auf einem neuen VPS wiederherstellen.

Auf welche Modell-Backends es verweisen kann

Hier liegt das entscheidende Detail, das die gesamte Einrichtung in einen anderen Zusammenhang stellt: Agentlas ruft keine Modell-API auf. Das übernimmt der Host-Harness.

Das Architekturdokument beschreibt Laufzeitadapter, die einen Kern für jeden Harness übersetzen, und stellt klar, dass der Host-Laufzeitprozess die Modellzugangsdaten verwaltet. Agentlas stellt zwei Schnittstellen bereit, die ein Harness übernimmt: eine AgentSkills-Datei und einen MCP-Server (model context protocol), der über stdio kommuniziert. Die Frage „Welche Modelle unterstützt Agentlas?“ lautet daher eigentlich: „Welche Modelle unterstützt Ihr Harness?“ Die Antwort ist: alle Modelle, die Claude Code, Codex, opencode, goose oder Hermes erreichen können.

So wird der MCP-Server in einer Codex-ähnlichen TOML-Konfiguration registriert:

[mcp_servers.hephaestus-network]
command = "~/.agentlas/runtime/current/bin/hephaestus"
args = ["mcp", "serve"]

Während der Installation wird derselbe Server automatisch in ~/.cursor/mcp.json, ~/.config/goose/config.yaml und die anderen Harness-Konfigurationen eingetragen. Wenn Sie mehrere solcher Server auf einem Host einrichten, beschreibt MCP-Server auf einem VPS ausführen das stdio- und Prozessmodell ausführlicher.

Auf einen selbst gehosteten Ollama-Endpunkt verweisen

Da der Harness die Modellverbindung verwaltet, bedeutet die Verwendung lokaler Modelle mit Agentlas, dass Sie Ihren Harness auf Ollama verweisen. Ollama hat in v0.15 dafür den Unterbefehl launch eingeführt. In v0.32.9 ist er am 11 August 2026 weiterhin enthalten. Damit konfigurieren Sie einen vorhandenen Harness für lokale Modelle, ohne Umgebungsvariablen festzulegen:

ollama pull qwen3-coder:30b
ollama launch opencode

Ersetzen Sie opencode je nach installiertem Harness durch claude, codex oder droid. Leiten Sie anschließend eine Anfrage über die lokale Laufzeitumgebung:

~/.agentlas/runtime/current/bin/hephaestus route "summarise the failing tests" --runtime ollama

Bei erfolgreicher Weiterleitung wird eine JSON-Entscheidung zurückgegeben. Sie nennt den ausgewählten Agenten oder das ausgewählte Team und enthält einen receipt_id. Wenn keine verwertbare Antwort zurückgegeben wird, ist die Kontextlänge meist die Ursache. Die Agentlas-Dokumentation fordert für routing-intensive Sitzungen ein Modell mit mindestens 64k Kontext und nennt qwen3-coder, gemma3 und deepseek-r1 als Beispiele. Ollamas eigene Empfehlungen für Coding-Tools nennen ebenfalls eine Untergrenze von 64k. Routing-Entscheidungen enthalten das Agentenverzeichnis im Prompt. Ein Modell mit 8k oder 32k Kontext schneidet dieses Verzeichnis daher ab und trifft eine schlechte Auswahl.

Ein Hinweis, den die Kurzbeschreibung nicht nennt: Ollama, Gemma und DeepSeek verfügen über kein eigenes Plugin- oder Befehlssystem. Die /agentlas-Slash-Befehle sind dort daher nicht vorhanden. In einer Konfiguration mit lokalen Modellen steuern Sie das System stattdessen über den MCP-Server und den Befehl hephaestus route. Das ist eine echte Einschränkung des Funktionsumfangs. Sie ist der sachliche Preis dafür, die Modelle auf Ihrem eigenen Rechner zu betreiben.

Was ein Hub mit inaktiven Spezialisten an RAM kostet

Nichts. Das ist die vollständige Antwort. Sie können das überprüfen, statt es einfach anzunehmen.

Aus einem Hub ausgeliehene Spezialisten werden als Paketdateien eingebunden, nicht als Prozesse gestartet. Ein Spezialist besteht aus einem agent.md und einem .agentlas/-Verzeichnis mit JSON-Dateien: routing-card.json für Trigger und Fähigkeiten, memory-map.json für Schreibgrenzen und mode-map.json dafür, ob er allein oder als Team ausgeführt wird. Das Hephaestus Network wird als In-Process-Scheduler ohne Hintergrunddienst beschrieben. Zwischen Aufgaben können Sie selbst prüfen:

pgrep -af hephaestus
systemctl --user list-units --type=service | grep -i agentlas
du -sh ~/.agentlas

Die ersten beiden Befehle geben auf einem inaktiven System nichts aus, weil nichts im Speicher resident ist. Der dritte Befehl zeigt die einzigen Kosten, die ein geparkter Hub verursacht: Speicherplatz auf der Festplatte. Dieser wächst mit der Anzahl der Spezialisten, die Sie vorhalten, sowie mit dem gebündelten Embedding-Modell, das die Laufzeitumgebung ausliefert.

Die Speicherfrage betrifft daher vollständig die Lastspitze. Diese besteht aus Ihrem Harness und Ihrem Modell-Backend. Wenn das Harness mit einer gehosteten API kommuniziert, besteht der residente Speicherbedarf aus einem Prozess mit einigen hundert Megabyte. Wenn Sie die Gewichte selbst hosten, verursachen die Gewichte den Speicherbedarf:

[
  {
    "label": "Hosted API model",
    "weights_gb": 0
  },
  {
    "label": "gemma3:4b",
    "weights_gb": 3.3
  },
  {
    "label": "gemma3:12b",
    "weights_gb": 8.1
  },
  {
    "label": "gemma3:27b",
    "weights_gb": 17
  },
  {
    "label": "qwen3-coder:30b",
    "weights_gb": 19
  }
]

Dies sind die veröffentlichten Downloadgrößen aus der Modellbibliothek von Ollama, keine Messwerte aus einem Benchmark-Lauf. Der KV-Cache für einen Kontext von 64k kommt zu jedem Wert größer als null hinzu. Das Modell, das die Agentlas-Dokumentation zuerst nennt, qwen3-coder:30b, benötigt vor dem Kontext bereits 19 GB für die Gewichte. Selbst die 27B-Variante von Gemma benötigt 17 GB. Im Vergleich zu diesen Werten fällt die Agentlas-Schicht im Speicherbudget nicht ins Gewicht.

Wie sich das im Vergleich zur Ausführung eines einzelnen Harness verhält

Führen Sie ein Harness gegen eine gehostete API aus, läuft auf Ihrem VPS ein Prozess. Fügen Sie Agentlas hinzu, läuft dort derselbe eine Prozess sowie die Dateien. Der Orchestrator ist kein zusätzliches dauerhaft laufendes Programm. Er ist ein größerer Prompt, der aus den Paketen auf dem Datenträger zusammengestellt und anschließend verworfen wird.

Die veränderlichen Kosten betreffen den Kontext, nicht den Arbeitsspeicher. Ein Orchestrator, der mehrere Spezialistenkarten und deren Routing-Metadaten einbindet, benötigt pro Aufgabe mehr Tokens als ein einfaches Harness. Bei einer gehosteten API kostet das Geld und nicht RAM. Bei lokal ausgeführten Gewichten kostet es Zeit, weil ein längerer Prompt ein längeres Prefill auf der CPU oder eine stärker ausgelastete GPU bedeutet.

Deshalb richtet sich die Dimensionierung eines Systems wie dieses nach der Modellentscheidung und nicht nach dem Agent-Framework. RAM und CPU für einen Coding-Agent-VPS dimensionieren behandelt das ausführlich. Die Schlussfolgerung gilt auch hier: Wählen Sie den Plan für das Backend, das Sie ausführen möchten, und kalkulieren Sie anschließend ein paar Gigabyte Reserve für das Harness ein. Wenn Sie stattdessen zum Vergleich das Design mit einem dauerhaft aktiven Supervisor verwenden möchten, hält das Omnigent-Multi-Agent-Harness seinen Koordinator dauerhaft aktiv. Das ist der entgegengesetzte Kompromiss und zeigt sich direkt im Leerlaufverbrauch des Arbeitsspeichers.

Fehlerbilder und angezeigte Meldungen

hep-build: command not found direkt nach einer sauberen Installation. Das Installationsprogramm hat nach ~/.local/bin geschrieben. Dieses Verzeichnis liegt in einem standardmäßigen Ubuntu-Image nicht in PATH. Die letzte Zeile des Installationsprogramms wies darauf hin, ist aber aus der Anzeige gelaufen. Fügen Sie den oben gezeigten export-Befehl hinzu.

Das Verhalten ändert sich, nachdem Sie den Server neu aufbauen. Sie haben HEPHAESTUS_REF nicht gesetzt. Deshalb hat das Installationsprogramm den an diesem Tag aktuellen Tag verwendet. Fixieren Sie den Tag und notieren Sie ihn neben den anderen Versionsnummern.

Das Routing wählt bei einem lokalen Modell den falschen Spezialisten. Das Kontextfenster des Modells ist für das Agentenverzeichnis zu klein. Wechseln Sie zu einem Modell mit mindestens 64k und setzen Sie die Kontextlänge von Ollama entsprechend. Der Standardwert ist kleiner als für die Coding-Tools erforderlich.

ollama launch wird nicht erkannt. Das Subkommando wurde mit Ollama v0.15 eingeführt. Ältere Pakete aus einem Distributions-Repository enthalten es noch nicht. Installieren Sie eine aktuelle Ollama-Version.

Die Installation schreibt in Harnesses, die Sie nicht erwartet haben. Das Skript erkennt und konfiguriert jedes gefundene Harness. Dabei schreibt es nach ~/.claude/, ~/.codex/, ~/.gemini/, ~/.cursor/ und in weitere Verzeichnisse. Lesen Sie das Skript auf einem gemeinsam genutzten Build-Server vor der Ausführung und prüfen Sie, welche dieser Verzeichnisse für Sie relevant sind.

Ob Sie es bereits einsetzen sollten

Ein zehn Wochen altes Projekt mit mehrmals täglich automatisierten Releases ist nicht für den produktiven Betrieb geeignet. Die Architektur ist tatsächlich interessant, die Lizenz ist Apache-2.0, und aufgrund des dateibasierten Designs genügt zur Deinstallation das Löschen von zwei Verzeichnissen. Dadurch lässt es sich kostengünstig testen, aber nur mit hohem Risiko als Abhängigkeit einsetzen.

Eine vernünftige Vorgehensweise ist derzeit: Fixieren Sie v1.2.0, betreiben Sie es auf einem System, das Sie neu aufsetzen können, nehmen Sie ~/.agentlas in Ihre Backups auf und lesen Sie das Changelog erneut, bevor Sie die Version aktualisieren. Einen breiteren Überblick über andere Lösungen in diesem Bereich und deren jeweiligen Reifegrad bietet der Überblick zu Self-Hosted-KI-Agenten. Das Self-Hosting eines Hermes-Agenten auf einem VPS beschreibt außerdem eines der Agent-Harnesses, an die Agentlas angepasst ist.

FAQ

Läuft Agentlas OS auf meinem VPS als Server?

Nein. Im Repository gibt es keinen Daemon, keinen offenen Port und kein Container-Image. Das Installationsprogramm schreibt eine Laufzeitumgebung nach ~/.agentlas/runtime/ und Befehls-Wrapper nach ~/.local/bin. Das Hephaestus Network ist ein Scheduler innerhalb des Prozesses und kein Hintergrunddienst. Sie können dies auf einem unbeschäftigten System prüfen: pgrep -af hephaestus gibt nichts aus, und es gibt keine systemd-Unit, die aktiviert werden könnte. Self-Hosting bedeutet hier, dass sich der Code und der Zustand auf Ihrem Rechner befinden. Es bedeutet nicht, dass ein Dienst auf Verbindungen wartet.

Wie viel RAM verwendet ein Hub mit inaktiven Spezialisten?

Keines, weil inaktive Spezialisten keine Prozesse sind. Ein Spezialist besteht aus einer agent.md-Datei und einem .agentlas/-Verzeichnis mit routing-card.json, memory-map.json und ähnlichen Metadaten. Ein angehaltener Hub belegt daher nur Speicherplatz. Messen Sie ihn mit du -sh ~/.agentlas. Arbeitsspeicher wird nur während der Ausführung einer Aufgabe verwendet. Verantwortlich dafür sind Ihr Harness-Prozess und Ihr Modell-Backend, nicht die Agentlas-Schicht.

Welche Modelle kann ich verwenden, und kann ich auf mein eigenes Ollama verweisen?

Agentlas ruft selbst keine Modell-APIs auf. Das Host-Harness verwaltet die Zugangsdaten und die Verbindung. Unterstützt werden daher alle Modelle, die Ihr Harness unterstützt. Für lokale Gewichte führen Sie ollama launch opencode aus und ersetzen dabei claude, codex oder droid. Dadurch wird das Harness ohne Umgebungsvariablen für Ihren Ollama-Server konfiguriert. Verwenden Sie ein Modell mit mindestens 64k Kontext, beispielsweise qwen3-coder oder gemma3. Routing-Prompts enthalten das Agentenverzeichnis und werden bei kleineren Kontextfenstern stark gekürzt.

Welche Version sollte ich installieren, und warum ist das Pinning hier wichtig?

Installieren Sie v1.2.0. Dies ist die am 12 August 2026 aktuelle getaggte Version. Setzen Sie dazu HEPHAESTUS_REF=v1.2.0, bevor Sie das Installationsprogramm ausführen. Der Standardwert im Skript selbst ist version="${HEPHAESTUS_REF:-v1.2.0}". Er folgt dem nächsten Tag der Maintainer. Pinning ist hier besonders wichtig, weil das Projekt in der 1.1-Serie mehr als hundert Releases veröffentlicht hat, an manchen Tagen mehrere. Ein Wochen später ohne feste Version erstelltes System entspricht daher nicht dem System, das Sie getestet haben.