Omnigent: Agent-CLIs in einem Harness bündeln

Was Omnigent ist

Omnigent ist ein Open-Source-Meta-Harness: eine Orchestrierungsebene, die die bereits installierten Agent-Befehlszeilentools (CLIs) steuert. Es ersetzt Claude Code, Codex, Cursor, OpenCode, Hermes oder Pi nicht. Omnigent startet diese Tools, weist jedem eine Aufgabe zu und überwacht das Ergebnis innerhalb einer einzigen Sitzung mit einem einheitlichen Richtliniensatz. Databricks veröffentlichte das Repository im Juni 2026 unter der Apache-2.0-Lizenz. Auf der Startseite steht weiterhin Status: alpha.

Die praktische Aussage ist begrenzt und sollte klar formuliert werden. Sie beschreiben einen Agent einmal in YAML und geben an, welches Harness ihn ausführt. Wenn Sie diese eine Zeile ändern, läuft derselbe Agent über die CLI eines anderen Anbieters. An Ihrer übrigen Konfiguration ändert sich nichts, weil Omnigent die Schleife über den Agents steuert und nicht die Schleife innerhalb der Agents.

Was ist ein Meta-Harness, und wie unterscheidet es sich von einem Framework?

Ein Harness ist das Programm, das ein Modell in einer Schleife ausführt. Es liest Ihren Prompt, ruft Tools auf, bearbeitet Dateien und gibt das Ergebnis zurück. Claude Code ist ein Harness. Codex ist ein Harness. Sie installieren es, melden sich an und es arbeitet selbstständig.

Ein Framework ist eine Bibliothek, gegen die Sie Code schreiben. Sie importieren sie, definieren die Schritte in Python, und Ihr Programm wird zum Agenten. Wenn Sie dort den Anbieter wechseln, müssen Sie Ihren Code ändern, weil der Client des Anbieters in Ihr Programm eingebunden ist.

Ein Meta-Harness steht eine Ebene über beiden. Es ist ein Supervisor, der Harnesses als untergeordnete Prozesse ausführt. Omnigent startet die CLI des Anbieters, übergibt ihr Aufgaben und liest die Rückgabewerte. Sie behalten die bereits installierte CLI und das vorhandene Abonnement oder den API-Schlüssel (application programming interface), mit dem Sie dafür bezahlen. Das ist der gesamte Unterschied. Er bestimmt, für wen das Tool gedacht ist: für Personen, bei denen bereits mehrere Agent-CLIs funktionieren und die es leid sind, sie einzeln in Terminals zu bedienen.

Welches Problem löst eine Orchestrierungsebene?

• Ein Anbieterwechsel kostet eine Zeile. Die Agentendefinition enthält harness und model als Daten. Daher ändern Sie beim Verschieben einer Rolle von einem Anbieter zu einem anderen die YAML-Datei, statt die Definition neu zu schreiben.
• Reviews können anbieterübergreifend erfolgen. Ein von einem Modell erstellter Diff wird von einem Modell eines anderen Unternehmens gelesen. Zwei Modelle aus derselben Modellfamilie teilen tendenziell dieselben blinden Flecken. Eine zweite Meinung vom selben Anbieter ist daher weniger wert.
• Richtlinien haben einen zentralen Ort. Ausgabenlimits und Genehmigungsabfragen werden in der Agentendatei deklariert. Sie gelten für jeden untergeordneten Sub-Agenten.
• Die Sitzung ist unabhängig von einzelnen Tools. Ein Transkript erfasst die Arbeit mehrerer CLIs. Dadurch können Sie nachvollziehen, was passiert ist, ohne vier Scrollbacks zusammenzufügen.

Der Nachteil ist die zusätzliche Ebene selbst. Jeder Fehler in Omnigent ist nun ein Fehler zwischen Ihnen und einem Agenten, der zuvor eigenständig funktioniert hat. In der Alpha-Phase sind das reale Kosten und keine theoretischen.

Wo ein Multi-Agent-Harness neben Tools für einzelne Agents einzuordnen ist

Wenn Sie noch keinen Agent auf einem Server ausgeführt haben, beginnen Sie stattdessen dort. Unser Leitfaden zum Ausführen eines Coding-Agents auf einem VPS behandelt den Einsatz eines einzelnen Agents vollständig. Omnigent setzt voraus, dass diese Einrichtung bereits vorhanden ist. Im größeren Bereich der Self-Hosted-AI-Agents wählen Sie die Agents selbst aus. Wenn die Begriffe hier neu für Sie sind, ist Wie Agents tatsächlich funktionieren der bessere Einstieg.

Omnigent arbeitet außerdem auf einer anderen Ebene als eine Connector-Schicht. Bei Themen wie Agents Zugriff auf Ihre eigenen Datenquellen geben geht es darum, welche Daten ein Agent erreichen kann. Bei Omnigent geht es darum, welcher Agent in welcher Reihenfolge und unter welchen Einschränkungen ausgeführt wird. Beides kann gleichzeitig erforderlich sein. Die Bereiche überschneiden sich nicht.

Voraussetzungen für die Installation

• Python 3.12 oder neuer. Das veröffentlichte Paket setzt requires-python >= 3.12 voraus.
• tmux, weil die Terminal-Harnesses darin ausgeführt werden.
• Mindestens eine CLI des Anbieters, die bereits installiert ist und für die Sie bereits angemeldet sind.
• Node.js 22 nur, wenn Sie aus einem Git-Checkout erstellen. Das Wheel auf PyPI enthält die erstellten Web-Assets. Für die normale Installation ist Node nicht erforderlich.

Installieren Sie eine festgelegte Version, nicht main

curl -fsSL https://raw.githubusercontent.com/omnigent-ai/omnigent/main/scripts/install_oss.sh | sh -s -- --version 0.7.0

Der Teil sh -s -- ist keine Dekoration. Ohne ihn interpretiert sh --version als eigene Option. Der Installer erkennt das Flag dann nicht, und Sie erhalten die an diesem Tag neueste Version. Bei einem Repository, das alle paar Wochen inkompatible Änderungen veröffentlicht, entscheidet das darüber, ob das System reproduzierbar bleibt oder unerwartete Änderungen enthält.

Der Installer verwendet uv, den Python-Paketmanager von Astral. Wenn uv fehlt, bietet der Installer zunächst dessen Installation an. Wenn uv bereits installiert ist, überspringen Sie das Skript:

uv tool install --force --python 3.12 "omnigent==0.7.0"

Zusatzpakete folgen demselben Muster, und das Flag wird erneut angegeben: --extra e2b --extra kubernetes im Skript oder "omnigent[e2b,kubernetes]" mit uv. Beachten Sie, dass der Git-Tag v0.7.0 lautet, während die Paketversion auf PyPI 0.7.0 ist.

uv legt die Binärdatei in dem Verzeichnis ab, das uv tool dir --bin ausgibt, normalerweise ~/.local/bin. Der Installer bietet an, dieses Verzeichnis an Ihr Shell-Profil anzuhängen. Wenn der Befehl direkt nach einer sauberen Installation nicht gefunden wird, liegt das daran. Prüfen Sie das installierte Ergebnis:

omni upgrade --check

Damit wird die installierte Version mit der zuletzt veröffentlichten Version verglichen. Der Befehl zeigt an, ob ein Upgrade verfügbar ist, führt es aber nicht aus. omni und omnigent sind dasselbe Programm unter zwei Namen.

Auf einen Model-Provider verweisen

omni setup

Der Assistent sucht nach bereits in Ihrer Umgebung vorhandenen Zugangsdaten und fordert Sie zur Eingabe der fehlenden Daten auf. Er unterstützt API-Keys, Anbieterabonnements, Gateways wie OpenRouter oder Ollama sowie Databricks-Workspaces. Wenn Sie auf demselben Rechner bereits einen lokalen Model-Server mit Ollama betreiben, verweisen Sie ein Gateway darauf. Der Netzwerkverkehr verlässt dann niemals den Rechner.

Ein minimaler Lauf mit mehreren Agents

Die Beispiel-Agents befinden sich im Repository. Klonen Sie daher denselben Tag, den Sie installiert haben, statt main.

git clone --depth 1 --branch v0.7.0 https://github.com/omnigent-ai/omnigent.git
cd omnigent
omnigent run examples/polly/

Polly ist der im Repository enthaltene Orchestrator für die Arbeit mit mehreren Agents. Die Konfiguration definiert die Sub-Agents claude_code, codex, opencode, cursor, hermes und pi sowie eine Regel, die den gesamten Lauf sinnvoll macht: Die Prüfung erfolgt immer durch einen anderen Anbieter als die Implementierung. Polly schreibt selbst keinen Code. Es plant die Arbeit, teilt das Ziel in Arbeitselemente auf, delegiert diese einzeln und leitet jedes Diff an einen Reviewer eines anderen Anbieters weiter.

Bevor Polly Aufgaben delegiert, führt es eine Vorabprüfung durch. Dabei wird ermittelt, welche Sub-Agent-CLIs auf dem Rechner tatsächlich vorhanden sind. Wenn nur die CLI eines Anbieters installiert ist, kann das Diff niemandem übergeben werden. Installieren Sie daher mindestens zwei CLIs, bevor Sie die Ausgabe bewerten. Debby, das andere enthaltene Beispiel, ist ein Debate-Agent mit zwei Köpfen: einem von Claude und einem von GPT:

omni debby

Damit lässt sich kurz bestätigen, dass zwei Provider konfiguriert sind. Debby benötigt beide, um überhaupt eine Ausgabe zu erzeugen.

Sub-Agents werden als Tools definiert

Die Agent-Datei liegt im YAML-Format vor. executor bezeichnet Harness, Modell und Authentifizierung. tools enthält MCP-Server (Model Context Protocol), Python-Funktionen und Sub-Agents. Ein Sub-Agent ist ein Tool mit type: agent und einem eigenen Executor. Darauf basiert die gesamte darüber beschriebene Funktionalität.

name: orchestrator
prompt: |
  You coordinate coding and review tasks.

executor:
  harness: claude-sdk
  model: databricks-claude-sonnet-4-6

tools:
  coder:
    type: agent
    prompt: Write and test code.
    executor:
      harness: claude-sdk
      model: databricks-claude-opus-4-7
  reviewer:
    type: agent
    prompt: Review proposed changes.
    executor:
      harness: claude-sdk
      model: databricks-claude-sonnet-4-6

omnigent run path/to/my_agent.yaml

Diese Modell-IDs stammen aus dem docs/AGENT_YAML_SPEC.md-Beispiel des Projekts und bezeichnen von Databricks gehostete Modelle. Ersetzen Sie harness und model durch die Werte, die omni setup auf Ihrem System konfiguriert. Weitere Harness-Werte in der Spezifikation sind antigravity, copilot, kimi, qwen und acp:<slug> für Komponenten, die das generische Protokoll verwenden. Die Spezifikation unterstützt außerdem pass_history: true für einen Sub-Agent. Dadurch wird die übergeordnete Konversation an ihn übergeben. Das verbraucht bei jeder Delegation zusätzliche Tokens. Lassen Sie die Option daher bei Sub-Agents deaktiviert, die nur die aktuelle Aufgabe benötigen. Wenn prompt eines Coders ihn anweist, die kleinste funktionierende Änderung vorzunehmen, übergibt er seinem Reviewer einen ausreichend kurzen Diff, der tatsächlich lesbar ist. Das ist hier wichtiger als die Wahl des Modells für eine der beiden Rollen.

Warum lang laufende Orchestrierung auf einen VPS gehört

Ein Multi-Agent-Lauf ist kein zweiminütiger Befehl. Sie planen, delegieren, warten auf parallele Git-Worktrees, prüfen Ergebnisse und überarbeiten sie. Das Schließen eines Laptopdeckels beendet den gesamten Vorgang. Ein VPS (Virtual Private Server) bleibt aktiv und behält seine Netzwerkverbindung bei. Dadurch läuft die Sitzung weiter, während Sie sie nicht überwachen.

omnigent server --background
omnigent server status

Der Server stellt eine Weboberfläche auf Port 6767 bereit. omnigent server status zeigt an, ob eine Instanz läuft, und omnigent stop beendet sie. In Releases vor v0.7.0 war dies omni server start. Dieser Befehl wurde entfernt. Ältere Anleitungen und Screenshots stimmen daher nicht mit der Ausgabe Ihres Terminals überein.

Veröffentlichen Sie Port 6767 nicht auf einer öffentlichen Adresse. Zwei Varianten sind sicher. Lassen Sie den Port in der Firewall geschlossen und leiten Sie ihn mit ssh -N -L 6767:localhost:6767 you@your-server über SSH weiter. Öffnen Sie die Weboberfläche anschließend unter http://localhost:6767 auf Ihrem eigenen Rechner. Alternativ können Sie TLS (Transport Layer Security) davor terminieren und die Authentifizierung aktivieren:

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

Der Firewall-Teil ist eine gewöhnliche Aufgabe und wird in den Grundlagen der ufw-Firewall für einen VPS behandelt. Wenn auf dem Server bereits Container hinter Traefik vor mehreren Docker-Compose-Anwendungen laufen, ist Omnigent ein weiterer Dienst nach demselben Muster.

Für eine Bereitstellung mit Containern enthält das Verzeichnis deploy/ des Repositorys eine Compose-Konfiguration. ./bootstrap.sh erzeugt Geheimnisse in .env. Anschließend startet docker compose up -d Omnigent und Postgres auf Port 6767. DATABASE_URL wählt Postgres oder SQLite aus. Innerhalb der Container ist OMNIGENT_AUTH_ENABLED standardmäßig auf 1 gesetzt. Das ist die richtige Voreinstellung für alles, was von außen erreichbar ist.

Für die Dimensionierung nennen die Bereitstellungshinweise eine Arbeitsspeichermenge von ungefähr 512 MB bis 1 GB für den Server. Die Fly.io-Konfiguration legt 1 GB fest. Dieser Wert gilt nur für den Supervisor. Jeder Sub-Agent ist ein eigener Prozess mit einem eigenen Checkout und einem eigenen Modell-Client. Dimensionieren Sie den Server daher nach der Anzahl der Agents. Sobald der Server läuft, registriert omnigent login https://your-host gefolgt von omnigent host https://your-host Ihren Laptop beim Server. Mit omnigent attach <session_id> können Sie eine laufende Sitzung von einem anderen Gerät aus fortsetzen.

Sub-Agenten in einer Sandbox ausführen, bevor Sie sie unbeaufsichtigt lassen

Omnigent liefert eine Sandbox auf Betriebssystemebene namens Omnibox. Unter Linux verwendet sie bubblewrap-Namespaces und seccomp. Dadurch erzwingt der Kernel die Grenze und nicht der Prompt des Agenten. Ein durch Prompt-Injection manipulierter Agent kann eine Kernel-Regel nicht durch entsprechende Formulierungen umgehen. Installieren Sie zuerst die Abhängigkeit:

sudo apt install bubblewrap

Die Konfiguration liegt unter os_env in der Agentendatei:

os_env:
  type: caller_process
  cwd: .
  sandbox:
    type: linux_bwrap
    write_paths: [.]
    write_files: []
    read_paths: []
    allow_network: true
    cwd_allow_hidden: [.venv]
    env_passthrough: []
    egress_rules: []
    credential_proxy: []

Das Arbeitsverzeichnis ist schreibgeschützt, bis Sie es in write_paths aufführen. Dadurch kann ein fehlerhaft arbeitender Agent außerhalb des Arbeitsbereichs nichts schreiben. Dotfiles bleiben verborgen, sofern sie nicht in cwd_allow_hidden genannt werden. Eine weit gefasste Leseberechtigung gibt dadurch nicht unbemerkt .ssh oder .aws frei. Setzen Sie egress_rules. Dann läuft der gesamte HTTP- und HTTPS-Verkehr über einen Proxy mit standardmäßiger Ablehnung. Jede Regel wird als "METHODS host/path-glob" geschrieben. credential_proxy geht noch einen Schritt weiter: Der Agent hält zu keinem Zeitpunkt das eigentliche Secret, sondern nur einen Platzhalter. Der Proxy ersetzt diesen Platzhalter beim Verlassen der Anfrage durch das echte Secret. Ein offengelegtes Transkript enthält dadurch kein nutzbares Secret. In einer Umgebung mit mehreren Harnesses enthält jeder Sub-Agent seinen eigenen Sandbox-Block in seiner eigenen Konfigurationsdatei unter agents/. So kann der Netzwerkzugriff für einen Reviewer gesperrt werden, während der Implementierer ihn behält.

Die Dokumentation nennt die Einschränkung ausdrücklich, und sie ist wichtig. Die OS-Sandbox gilt für sys_os_*-Toolaufrufe und für Terminals. Sie gilt nicht für MCP-Server und nicht für den Omnigent-Supervisor-Prozess selbst. Ein von Ihnen gestarteter MCP-Server läuft außerhalb der Sandbox mit Ihren Berechtigungen. Aus diesem Grund bleibt ein stärkeres Sicherheitsmuster sinnvoll: eine separate Wegwerfmaschine pro Agent. Dieses Thema behandelt Coding-Agenten in einer Wegwerf-VM ausführen. Der andere Teil der Aufgabe sind Zugangsdaten. Secrets außerhalb der Reichweite eines Agenten halten wird schwieriger und nicht einfacher, wenn sechs Sub-Agenten denselben Host verwenden.

Ausgabenlimits sind Richtlinien, die in derselben Datei festgelegt werden:

policies:
  budget:
    type: function
    handler: omnigent.policies.builtins.cost.cost_budget
    factory_params:
      max_cost_usd: 5.00
      ask_thresholds_usd: [1.00, 3.00]

Ein Lauf, der mit einem Anbieter plant, mit einem zweiten implementiert und mit einem dritten prüft, verursacht gleichzeitig an drei Stellen Kosten. Legen Sie das Limit daher vor dem ersten unbeaufsichtigten Lauf fest und nicht erst nach der ersten Rechnung. Zu den integrierten Funktionen gehören außerdem max_tool_calls_per_session und ask_on_os_tools. Diese Funktion fordert vor Datei- und Shell-Operationen eine Genehmigung an. Unsere Hinweise zum Kontrollieren der Kosten von KI-Agenten auf einem VPS gelten hier unmittelbar und sogar noch stärker, weil parallele Sub-Agenten die Verbrauchsrate vervielfachen.

Wie schnell entwickelt sich dieses Repository weiter?

[
  {
    "version": "v0.2.0",
    "released": "2026-06-19",
    "interval": 3
  },
  {
    "version": "v0.3.0",
    "released": "2026-06-27",
    "interval": 8
  },
  {
    "version": "v0.4.0",
    "released": "2026-07-03",
    "interval": 6
  },
  {
    "version": "v0.5.0",
    "released": "2026-07-10",
    "interval": 7
  },
  {
    "version": "v0.5.1",
    "released": "2026-07-10",
    "interval": 0
  },
  {
    "version": "v0.6.0",
    "released": "2026-07-21",
    "interval": 11
  },
  {
    "version": "v0.7.0",
    "released": "2026-07-27",
    "interval": 6
  }
]

Dies sind die veröffentlichten Release-Daten von der Releases-Seite des Projekts, abgerufen am 3. August 2026. 7 getaggte Releases wurden zwischen 2026-06-19 und 2026-07-27 veröffentlicht. Die längste Lücke zwischen zwei Releases betrug 11 Tage. v0.5.1 wurde am selben Tag wie das vorherige Release veröffentlicht. Das erste Release, 0.1.1 vom 16. Juni 2026, ist im Diagramm nicht enthalten, weil es keinen vorherigen Tag als Referenz gibt.

Zwei dieser Releases haben Befehle geändert, die in Anleitungen bereits dokumentiert waren. v0.7.0 entfernte omni server start zugunsten von omni server --background. v0.6.0 benannte das Extra omnigent[memory] in omnigent[hindsight] um. Deshalb schlägt eine aus einer Anleitung vom Juni kopierte Installationszeile bei einem Build vom Juli fehl. Das spricht dafür, in Ihrem Installationsbefehl --version und in Ihrem git clone einen Tag anzugeben. Das ist keine Frage des persönlichen Stils.

Womit ich es derzeit noch nicht betrauen würde

Im August 2026 kommt das Repository auf etwa 8.1k Stars, 1.2k Forks und rund 350 offene Issues. Der erste öffentliche Release liegt sieben Wochen zurück. Stars messen das Interesse, nicht den Reifegrad. Das Projekt bezeichnet sich als Alpha. Die oben aufgeführte Release-Historie bestätigt, dass dies wörtlich zu verstehen ist.

• Ich würde es nicht auf einem Host ausführen, auf dem sich Zugangsdaten aus der Produktion befinden, weil die Sandbox weder MCP-Server noch den Supervisor abdeckt.
• Ich würde einen Lauf nicht ohne cost_budget-Richtlinie unbeaufsichtigt lassen, weil drei Anbieter parallel Kosten verursachen können und nichts anderes sie daran hindert.
• Ich würde den Server nicht ohne gesetztes OMNIGENT_AUTH_ENABLED und vorgeschaltetes TLS an einer öffentlichen IP-Adresse bereitstellen.
• Ich würde die Agent-YAML-Datei bei Minor-Versionen noch nicht als stabil betrachten. Fixieren Sie daher die Version und lesen Sie vor einem Upgrade die Release Notes.

Noch ein Punkt, der Sie nicht unvorbereitet treffen sollte: v0.6.0 hat anonymisierte Nutzungs-Telemetrie eingeführt. Das Projekt dokumentiert sie auf einer eigenen Telemetrie-Seite. Lesen Sie diese Seite und entscheiden Sie bewusst, ob Sie sie aktivieren, wenn der Rechner für Kundenaufträge verwendet wird.

Die eigentliche Stärke von Omnigent liegt derzeit genau in dem Anwendungsfall, für den es entwickelt wurde. Sie haben drei oder vier Agent-CLIs, bezahlen bereits dafür und möchten eine davon schreiben lassen, während eine andere den Code prüft. Das funktioniert bereits jetzt auf einem Rechner mit echter Sandbox unter Linux. Alles darüber hinaus sollten Sie als vielversprechend, aber noch nicht fertig betrachten.

FAQ

Ist Omnigent ein Agent oder eine Anwendung, die Agenten ausführt?

Omnigent führt Agenten aus. Omnigent ist ein Meta-Harness: Es startet die bereits installierten Vendor-CLIs wie Claude Code, Codex oder OpenCode, weist jeder CLI Arbeit zu und überwacht die Ergebnisse in einer Sitzung. Es bringt kein eigenes Modell mit. Darin unterscheidet es sich von einem Framework, bei dem Sie Python gegen eine Bibliothek schreiben und Ihr eigenes Programm zum Agenten wird.

Muss ich Claude Code und Codex installieren, bevor Omnigent nützlich ist?

Sie benötigen mindestens eine installierte und angemeldete Vendor-CLI, weil Omnigent diese Programme steuert, statt sie zu ersetzen. Für das mitgelieferte Polly-Beispiel benötigen Sie zwei oder mehr CLIs verschiedener Anbieter. Polly verlangt, dass die Prüfung immer von einem anderen Anbieter als die Implementierung durchgeführt wird. Wenn nur eine CLI vorhanden ist, gibt es daher keinen zweiten Anbieter, an den der Diff gesendet werden kann.

Wie installiere ich eine bestimmte Omnigent-Version statt der neuesten Version?

Übergeben Sie --version mit sh -s -- an das Installationsskript, wie in sh -s -- --version 0.7.0. Ohne -s -- wird das Flag von sh selbst verarbeitet, und das Skript installiert das neueste Release. Wenn uv bereits vorhanden ist, übernimmt uv tool install --force --python 3.12 "omnigent==0.7.0" dieselbe Aufgabe. Der Git-Tag lautet v0.7.0, während die PyPI-Versionszeichenfolge 0.7.0 lautet.

Reicht die Omnibox-Sandbox aus, um Agenten unbeaufsichtigt auszuführen?

Für den abgedeckten Bereich ist sie wirksam und grenzt ihre Einschränkungen klar ab. Unter Linux verwendet sie bubblewrap zusammen mit seccomp. Dadurch erzwingt der Kernel die Datei- und Netzwerkbegrenzungen, und der Agent kann sie nicht umgehen. Die Dokumentation gibt an, dass sie für sys_os_*-Toolaufrufe und Terminals gilt, nicht jedoch für MCP-Server oder den Omnigent-Supervisor-Prozess. Ein MCP-Server läuft daher mit Ihren normalen Berechtigungen. Für unbeaufsichtigte Arbeit bietet eine separate, nicht dauerhafte virtuelle Maschine pro Agent deshalb weiterhin die stärkere Isolation.

Wie viel Arbeitsspeicher benötigt ein Omnigent-Server auf einem VPS?

Die Deploy-Hinweise des Projekts veranschlagen für den Server eine Arbeitssatzgröße von ungefähr 512 MB bis 1 GB. Die Fly.io-Konfiguration reserviert 1 GB. Das deckt nur den Supervisor und die Weboberfläche auf Port 6767 ab. Jeder Sub-Agent ist ein eigener Prozess mit einer eigenen Arbeitskopie und einem eigenen Modell-Client. Läufe nach dem Polly-Muster verwenden außerdem parallele Git-Worktrees. Dimensionieren Sie RAM und Speicherplatz daher nach der Anzahl der Agenten, die Sie gleichzeitig ausführen möchten, und nicht nach dem Server allein.