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 befindet sich dieses Projekt, realistisch betrachtet

Das Repository wurde am 4. Juni 2026 erstellt. Am 13. Oktober 2026 ist es etwa vier Monate alt und hat ungefähr 1.580 Stars und 110 Forks. Für eine Software, die Sie in echten Arbeitsabläufen einsetzen, ist das sehr jung.

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-Reihe gab es über hundert getaggte Releases, an manchen Tagen mehrere, die durch Automatisierung veröffentlicht wurden. Die 1.2-Reihe setzte dieses Tempo fort: Am 10. Oktober 2026 war sie bereits bei v1.2.62. 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 der gesamte folgende Leitfaden verwendet diese Variable. Bei einer ungepinnten Installation eines Projekts, das so häufig Releases veröffentlicht, erhalten Sie möglicherweise genau die Version, die beim letzten Bearbeiten des Scripts zuletzt getaggt wurde.

Was Sie auf dem VPS benötigen

Die Anforderungen sind gering, weil nichts im Hintergrund ausgeführt wird.

• Einen Linux-VPS. Ubuntu 24.04 ist eine geeignete Grundlage. Der Installer erkennt das Betriebssystem mit uname -s und verwendet unter Linux einen Nicht-macOS-Zweig. Daher wird auch ein Headless-System unterstützt.
• curl, tar und git auf dem System sowie Python 3.9 oder neuer. Der aktuelle Installer verwendet Python, um das Release-Archiv zu verifizieren.
• Ausgehendes HTTPS zu raw.githubusercontent.com und github.com für eine normale Installation. Der Installer lädt ein Release-Archiv herunter und prüft dessen SHA-256-Hash. Ein System ohne ausgehende Netzwerkverbindung kann trotzdem aus einem Quellbaum installiert werden, den Sie selbst übertragen: Setzen Sie HEPHAESTUS_SOURCE_DIR darauf. Das Skript überspringt dann den Download, weil die Anforderung curl nur für Installationen aus einem entfernten Release gilt.
• 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 keinen root-Zugriff. Der Installer schreibt nur in Ihr Home-Verzeichnis, einschließlich ~/.local/bin. Wenn ein Schritt fehlschlägt, beispielsweise weil ein Pfad nicht beschreibbar ist, gibt er eine Warnung aus und setzt die übrigen Schritte fort. Am Ende wird ein Exit-Code ungleich null zurückgegeben, wenn ein Fehler aufgetreten ist. Wenn Sie den Server selbst noch auswählen, beschreibt einen Coding-Agent auf einem VPS ausführen das Basis-Image und die Zugriffskonfiguration, auf denen dieser Aufbau aufsetzt.

Die festgelegte Version installieren

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 gefundene Agent-Harness. Daher sollten Sie sich dafür 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 unter main lautet die Zeile jetzt version="${HEPHAESTUS_REF:-v1.2.62}", und v1.2.62 wurde am 10. Oktober 2026 veröffentlicht. Wenn die Variable nicht gesetzt ist, erhalten Sie nicht mehr v1.2.0. Der Standardwert folgt stattdessen jedem neuen Tag. Setzen Sie die Variable explizit. Dann installiert ein erneuter Build Monate später genau die Version, die Sie getestet haben.

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

Die Festlegung gilt für die Installation, nicht für das Verhalten danach. Bis einschließlich v1.2.0 und auf main starten hephaestus-Befehle eine Prüfung auf Updates im Hintergrund. Wenn eine neuere Version vorhanden ist, wird sie installiert und ~/.agentlas/runtime/current ohne Nachfrage neu zugewiesen. Das Installationsprogramm deaktiviert dieses Verhalten während des eigenen Laufs mit HEPHAESTUS_AUTO_UPDATE=0. Mit derselben Variable halten Sie die festgelegte Version dauerhaft ein. Im nächsten Schritt wird sie zu Ihrem Shell-Profil hinzugefügt.

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

Installed runner: /home/you/.agentlas/runtime/current/bin/hephaestus
Installed shell commands in /home/you/.local/bin
  /home/you/.local/bin is not on your PATH yet. To use them by name:

Diese PATH-Warnung wird häufig übergangen. 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. Der Hinweis des Installationsprogramms fügt den Pfad an ~/.zshrc an. Die Standard-Shell von Ubuntu ist jedoch bash. Beheben Sie dies dort, deaktivieren Sie gleichzeitig den Updater im Hintergrund und prüfen Sie das Ergebnis:

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

hep-global ist die ursprüngliche Schreibweise von hephaestus global. status zeigt, ob die Anweisungsdatei jedes Harness den verwalteten Router-Block enthält. Dieser Router ist standardmäßig deaktiviert. Daher sollte none ausgegeben werden. Wenn der Befehl überhaupt ausgeführt wird, ist Ihr PATH korrekt.

Wo der Zustand gespeichert wird

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

• ~/.agentlas/runtime/1.2.0/ enthält die Laufzeitumgebung selbst. Der Installer entfernt das führende v aus dem Tag. ~/.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, einschließlich 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 Daten, nach Besitzer getrennt.
• <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 aus.

Die Dokumentation zum Speicher in v1.2.0 weist ausdrücklich darauf hin, dass Geheimnisse, vollständige Zugangsdaten und vollständige Transkripte in keinen Speicherbereich gelangen dürfen. Zugangsdaten bleiben in lokalen, von gitignore ausgeschlossenen Dateien. In den Speichereinträgen werden nur Namen und Pfade abgelegt. Sichern Sie ~/.agentlas und die .agentlas-Verzeichnisse Ihrer Projekte. Dann können Sie die Umgebung auf einem neuen VPS wiederherstellen.

Ein Teil verlässt den Server: Laut aktueller README sendet hep-build standardmäßig anonyme Build-Zähler. Dabei werden keine Eingabeaufforderungen, Pfade oder Agenteninhalte übertragen. Setzen Sie AGENTLAS_TELEMETRY=0 oder DO_NOT_TRACK=1. Alternativ können Sie "telemetry": false in ~/.agentlas/networking/config.json eintragen, um dies zu deaktivieren.

Auf welche Modell-Backends es verweisen kann

Hier liegt das entscheidende Detail, das die gesamte Einrichtung in einem anderen Licht erscheinen lässt: Agentlas ruft keine Modell-API auf. Das übernimmt das Host-Harness.

Das Architekturdokument beschreibt Laufzeitadapter, die einen Kern für jedes Harness umsetzen. Die README erklärt außerdem, dass der Adapter die Authentifizierung beim Provider übernimmt und der Aufrufer sein eigenes Modell sowie den API-Zugriff bereitstellt. Agentlas stellt zwei Schnittstellen bereit, die ein Harness einbindet: eine AgentSkills-Datei und einen MCP-Server (Model Context Protocol), der über stdio kommuniziert. Die Frage „Welche Modelle unterstützt Agentlas?“ bedeutet daher eigentlich: „Welche Modelle unterstützt Ihr Harness?“ Die Antwort lautet: alle Modelle, die Claude Code, Codex, opencode, goose oder Hermes erreichen kann.

Die Registrierung des MCP-Servers sieht in einer Codex-ähnlichen TOML-Konfiguration so aus:

[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 dieser 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, müssen Sie für lokale Modelle den Harness auf Ollama verweisen. Ollama hat dafür in v0.15 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 zu setzen:

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 Laufzeit:

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

Eine erfolgreiche Weiterleitung gibt eine JSON-Entscheidung zurück. Sie nennt den ausgewählten Agenten oder das ausgewählte Team und enthält einen receipt_id. Wenn keine verwertbare Antwort zurückkommt, liegt die Ursache meist bei der Kontextlänge. Die Dokumentation zu lokalen Modellen in v1.2.0 fordert für routingintensive Sitzungen ein Modell mit mindestens 64k Kontext und nennt qwen3-coder, gemma3 und deepseek-r1 als Beispiele. Auch Ollamas eigene Empfehlungen für Coding-Tools nennen 64k als Untergrenze. Routing-Entscheidungen enthalten das Agentenverzeichnis im Prompt. Ein Modell mit 8k oder 32k Kontext schneidet dieses Verzeichnis ab und wählt dadurch ungeeignete Ziele.

Ein wichtiger Punkt wird im Slogan nicht erwähnt. Ollama, Gemma und DeepSeek verfügen über kein eigenes Plugin- oder Befehlssystem. Daher existieren dort die /agentlas-Slash-Befehle nicht. Bei einer Einrichtung mit lokalen Modellen steuern Sie das System stattdessen über den MCP-Server und den Befehl hephaestus route. Das ist eine tatsächliche Einschränkung des Funktionsumfangs. Sie ist der sachliche Preis dafür, die Modellgewichte auf Ihrem eigenen System zu behalten.

Was ein Hub inaktiver Spezialisten an RAM kostet

Nichts. Das ist die vollständige Antwort, und Sie können sie überprüfen, statt sie einfach zu glauben.

Ausgeliehene Hub-Spezialisten werden als Paketartefakte eingebunden, nicht als Prozesse. 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 Teil eines Teams ausgeführt wird. Die Dokumentation des Hephaestus Network beschreibt einen Runner, der für eine Aufgabe Worker startet. Sie enthält keine Anweisung, einen Listening-Port zu öffnen oder einen Dienst zu aktivieren. Prüfen Sie den Zustand zwischen zwei Aufgaben selbst:

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 kein Prozess resident ist. Die einzige Ausnahme ist der Hintergrund-Updater: Wenn HEPHAESTUS_AUTO_UPDATE=0 nicht gesetzt ist, kann ein Befehl nach seiner Rückkehr einen kurzlebigen, losgelösten Update-Worker weiterlaufen lassen. Der dritte Befehl zeigt die einzigen Kosten, die ein geparkter Hub verursacht: Speicherplatz. Dieser wächst mit der Anzahl der von Ihnen vorgehaltenen Spezialisten und mit dem vom Runtime-Paket mitgelieferten Embedding-Modell.

Die Speicherfrage hängt daher vollständig vom kurzzeitigen Spitzenbedarf ab. Dieser besteht aus Ihrem Harness und Ihrem Modell-Backend. Wenn das Harness eine gehostete API verwendet, besteht der residente Speicherbedarf aus einem Prozess mit einigen hundert Megabytes. 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
  }
]

Das sind die veröffentlichten Downloadgrößen aus der Ollama-Modellbibliothek, keine Messwerte aus einem Benchmark-Lauf. Der KV-Cache für einen 64k-Kontext kommt zu jedem Wert über null hinaus hinzu. Das Modell, das die Agentlas-Dokumentation zuerst nennt, qwen3-coder:30b, benötigt 19 GB für die Gewichte, bevor der Kontext berücksichtigt wird. Selbst die 27B-Gemma-Variante benötigt 17 GB. Im Vergleich zu diesen Werten fällt die Agentlas-Schicht im Budget 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 die angezeigten Meldungen

hep-build: command not found direkt nach einer sauberen Installation. Das Installationsprogramm hat in ~/.local/bin geschrieben. Dieses Verzeichnis liegt bei einem Ubuntu-Standard-Image nicht in PATH. Darauf wurde gegen Ende der Ausgabe hingewiesen. Die Warnung ist jedoch weiter nach oben gerollt. Die vorgeschlagene Korrektur bezieht sich auf ~/.zshrc und nicht auf bash. Fügen Sie den oben gezeigten Export zu ~/.bashrc hinzu.

Das Verhalten ändert sich nach einer erneuten Bereitstellung des Servers. Sie haben HEPHAESTUS_REF nicht gesetzt. Daher hat das Installationsprogramm standardmäßig den Tag verwendet, den sein Skript an diesem Tag festgelegt hatte. Legen Sie den Tag fest und dokumentieren Sie ihn neben Ihren anderen Versionsnummern.

Das Verhalten ändert sich ohne erneute Bereitstellung. Der Hintergrund-Updater hat eine neuere Version installiert und ~/.agentlas/runtime/current auf diese Version umgestellt. Prüfen Sie, worauf current zeigt, und setzen Sie HEPHAESTUS_AUTO_UPDATE=0 in der Umgebung, in der Ihr Harness ausgeführt wird, nicht nur in einer interaktiven Shell.

Das Routing wählt bei einem lokalen Modell den falschen Spezialisten aus. Das Kontextfenster des Modells ist für das Agenteninventar zu klein. Verwenden Sie ein 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 sind älter und enthalten es nicht. Installieren Sie daher eine aktuelle Ollama-Version.

Die Installation schreibt in Harnesses, die Sie nicht erwartet haben. Das Skript erkennt und konfiguriert jedes gefundene Harness. Es schreibt in ~/.claude/, ~/.codex/, ~/.gemini/, ~/.cursor/ und weitere Verzeichnisse. Außerdem bearbeitet es bereits vorhandene Konfigurationsdateien wie ~/.codex/config.toml und legt neben der Originaldatei eine Sicherungskopie an. Lesen Sie das Skript auf einem gemeinsam genutzten Build-Server vor der Ausführung durch. Klären Sie außerdem, welche dieser Verzeichnisse für Sie relevant sind.

Sollten Sie das bereits einsetzen?

Ein vier Monate altes Projekt mit automatisierten Releases, teilweise mehreren pro Tag, sollte nicht in einer Produktionsumgebung eingesetzt werden. Die Architektur ist tatsächlich interessant, die Lizenz ist Apache-2.0, und der gesamte Zustand wird in Dateien gespeichert, die Sie sichern können. Die Entfernung ist jedoch weniger sauber, als diese Eigenschaften vermuten lassen: Die README dokumentiert keine Deinstallation, der Installer schreibt in etwa zehn Verzeichnisse in Ihrem Home-Verzeichnis und ändert vorhandene Harness-Konfigurationen. Der einzige dort angegebene Entfernungsbefehl, hephaestus global remove, entfernt nur den optionalen Router-Block. Dadurch ist das Projekt auf einem Wegwerf-System kostengünstig auszuprobieren, aber teuer als Abhängigkeit einzusetzen.

Eine derzeit sinnvolle Vorgehensweise ist: Fixieren Sie v1.2.0, setzen Sie HEPHAESTUS_AUTO_UPDATE=0, damit diese Version beibehalten wird, führen Sie das Projekt auf einem System aus, das Sie neu aufsetzen können, nehmen Sie ~/.agentlas in Ihre Backups auf und lesen Sie das Changelog erneut, bevor Sie die Versionsfixierung ändern. Einen breiteren Überblick über weitere Projekte in diesem Bereich und den Reifegrad der einzelnen Optionen bietet der Überblick über selbst gehostete KI-Agenten. Einen Hermes-Agenten auf einem VPS selbst hosten behandelt außerdem eines der Harnesses, an die Agentlas angepasst ist.

FAQ

Läuft Agentlas OS auf meinem VPS als Server?

Nein. Im Repository gibt es keinen Daemon, keinen lauschenden Port und kein Container-Image. Das Installationsprogramm schreibt eine Laufzeitumgebung nach ~/.agentlas/runtime/ und Befehls-Wrapper nach ~/.local/bin. Das Hephaestus Network wird gestartet, wenn eine Aufgabe es benötigt, und läuft nicht als Hintergrunddienst. Sie können dies auf einem inaktiven System überprüfen: pgrep -af hephaestus gibt nichts aus. Außerdem gibt es keine systemd-Unit, die aktiviert werden könnte. Die einzige Hintergrundaktivität ist ein kurzlebiger Update-Worker, den Befehle starten können. HEPHAESTUS_AUTO_UPDATE=0 schaltet ihn aus. Self-Hosting bedeutet hier, dass sich Code und Zustand auf Ihrem Rechner befinden. Es bedeutet nicht, dass ein Dienst auf einem Port lauscht.

Wie viel RAM benötigt 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 nicht verwendeter Hub benötigt 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 Model-Backend, nicht die Agentlas-Schicht.

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

Agentlas ruft selbst keine Model-APIs auf. Ihr 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 für Ihren Ollama-Server konfiguriert, ohne Umgebungsvariablen zu verwenden. Verwenden Sie ein Modell mit mindestens 64k Kontext, beispielsweise qwen3-coder oder gemma3. Routing-Prompts enthalten das Agent-Inventar und werden bei kleineren Kontextfenstern stark gekürzt.

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

Installieren Sie v1.2.0, die am 12 August 2026 aktuelle getaggte Version, indem Sie HEPHAESTUS_REF=v1.2.0 setzen, bevor Sie das Installationsprogramm ausführen. Der Standardwert des Skripts unter main ist jetzt version="${HEPHAESTUS_REF:-v1.2.62}". v1.2.62 ist die neueste Version und wurde am 10 October 2026 veröffentlicht. Dieser Standardwert ändert sich mit jedem neuen Tag. Das Fixieren der Version ist hier besonders wichtig, weil das Projekt in der 1.1-Serie über hundert Versionen veröffentlicht hat, an manchen Tagen mehrere. Ein erneuter Build ohne feste Version liefert daher Wochen später nicht das System, das Sie getestet haben. Setzen Sie außerdem HEPHAESTUS_AUTO_UPDATE=0. Andernfalls installiert die Laufzeit im Hintergrund neuere Versionen, sodass die Versionsbindung unbemerkt nicht mehr gilt.