omp (Oh My Pi) + JoinGonka Gateway: Agent mit Modellrollen

Schritt 1: omp installieren. Die offiziellen Wege aus der README des Projekts:

# macOS and Linux
curl -fsSL https://omp.sh/install | sh

# Homebrew
brew install can1357/tap/omp

# via Bun (requires Bun 1.3.14 or newer)
bun install -g @oh-my-pi/pi-coding-agent

# Windows (PowerShell)
irm https://omp.sh/install.ps1 | iex

Schritt 2: Schlüssel erhalten. Registrieren Sie sich auf gate.joingonka.ai/register, bestätigen Sie Ihre Adresse und erstellen Sie im Bereich „API-Schlüssel" einen Schlüssel mit dem Präfix jg-. Ein Schlüssel und ein Guthaben gelten für alle Modelle des Netzwerks.

Schritt 3: Installer ausführen.

npx @joingonka/setup --tool omp

Der Installer fragt nach dem Schlüssel — er wird nicht über Kommandozeilenargumente übergeben, damit er nicht in der Shell-Historie landet — und erledigt vier Dinge:

• Er trägt den Anbieter joingonka in ~/.omp/agent/models.yml ein: Gateway-Adresse, Protokoll openai-completions, den Schlüssel als Literal und drei Modelle des Netzwerks mit den tatsächlichen Kontextfenstern und Antwort-Obergrenzen; die Datei erhält die Rechte 600;
• Er setzt das Standardmodell — modelRoles.default in ~/.omp/agent/config.yml — auf DeepSeek V4 Flash, aber nur, wenn die Rolle leer ist oder auf ein Modell verweist, das aus dem Netzwerk verschwunden ist: Eine fremde Wahl übernimmt er nicht, sondern zeigt, wie man wechselt;
• Vor dem Schreiben legt er eine Sicherungskopie der bisherigen Datei an, und alle anderen Anbieter, Rollen und Kommentare bleiben unverändert;
• Zum Schluss sendet er eine Live-Anfrage an das Gateway und sagt klar, ob Schlüssel, Adresse und Modell akzeptiert wurden.

Ein anderes Standardmodell legt das Flag --model mit der Kurzform deepseek, glm oder minimax fest — ein ausdrücklich angegebenes Modell wird immer geschrieben. Für Dotfiles und Server gibt es einen Modus ohne Rückfragen, in dem der Schlüssel aus einer Umgebungsvariable stammt:

JOINGONKA_API_KEY=jg-your-key npx @joingonka/setup --tool omp --model glm --non-interactive

Nicht standardmäßige Konfigurationsorte berücksichtigt der Installer von selbst: ein benanntes Profil (OMP_PROFILE) und ein verschobenes Agent-Verzeichnis (PI_CODING_AGENT_DIR). Eine geerbte models.json überführt er in models.yml, genau wie omp es selbst tun würde — die bisherigen Anbieter gehen nicht verloren. Und wenn daneben eine alte settings.json ohne config.yml liegt, legt der Installer keine config.yml an, damit omp seine eigene Einstellungsmigration nicht überspringt: Er bittet darum, omp einmal zu starten und den Befehl zu wiederholen.

Alles, was das Installationsprogramm macht, lässt sich auch von Hand schreiben. Es sind zwei Dateien, und jede hat ihre eigene Aufgabe: models.yml beschreibt die Anbieter und Modelle, config.yml speichert die Einstellungen — darunter, welches Modell welche Rolle übernimmt.

# ~/.omp/agent/models.yml
providers:
  joingonka:
    baseUrl: https://gate.joingonka.ai/v1
    api: openai-completions
    apiKey: jg-your-key
    models:
      - id: deepseek-ai/DeepSeek-V4-Flash-0731
        name: DeepSeek V4 Flash (Gonka)
        input: [text]
        contextWindow: 380000
        maxTokens: 32768
        reasoning: true
      - id: zai-org/GLM-5.3-Flash
        name: GLM-5.3 Flash (Gonka)
        input: [text]
        contextWindow: 390000
        maxTokens: 8192
        reasoning: true
      - id: MiniMaxAI/MiniMax-M2.7
        name: MiniMax M2.7 (Gonka)
        input: [text]
        contextWindow: 200000
        maxTokens: 8192

# ~/.omp/agent/config.yml
modelRoles:
  default: joingonka/deepseek-ai/DeepSeek-V4-Flash-0731

Der Schlüssel als Literal ist die reibungsloseste Variante: omp startet aus jeder Umgebung, und die Datei lässt sich einfach mit chmod 600 ~/.omp/agent/models.yml absichern. Wollen Sie den Schlüssel außerhalb der Datei halten, tragen Sie in apiKey den Namen einer Variable ein, etwa JOINGONKA_API_KEY, und exportieren Sie diese in der Shell, aus der Sie omp starten: genau diese Reihenfolge bei der Schlüsselauflösung ist in der Projektdokumentation beschrieben.

Das optionale Feld cost (Preis pro Million Token) ist nur für die Kostenschätzung einer Sitzung in der omp-Oberfläche nötig. Das Installationsprogramm trägt dort den aktuellen Preis des Gateways zum Zeitpunkt der Installation ein; im manuellen Konfigfile kann das Feld entfallen — diese Schätzung hat keinen Einfluss auf Ihre Rechnung, der tatsächliche Verbrauch wird im Konto angezeigt.

Der Modellselektor wird als provider/model-id geschrieben. Der Anbietername wird am ersten Schrägstrich abgetrennt, deshalb werden Netzwerk-IDs mit eigenem Schrägstrich unverändert geschrieben: joingonka/deepseek-ai/DeepSeek-V4-Flash-0731. Statt config.yml zu bearbeiten, lässt sich die Rolle auch aus der Oberfläche heraus zuweisen — mit dem Befehl /model innerhalb einer Sitzung oder im Assistenten omp setup.

In omp wird nicht ein einziges Modell für alles ausgewählt, sondern nach Rollen – das ist der wichtigste Hebel für die Konfiguration. Integrierte Rollen für Dialoge: default, smol, slow, plan, commit, task, tiny, memory, advisor und vision. Es ist nicht notwendig, alle zuzuweisen: Nicht festgelegte smol und slow übernehmen zunächst das Modell der Rolle default, Subagenten ohne task-Rolle arbeiten mit dem Modell der aktuellen Sitzung, commit und tiny folgen auf smol. Eine einzeilige Konfiguration für default ist voll funktionsfähig.

Die Aufteilung der Rollen zwischen den Netzwerkmodellen erfolgt nicht aus Sparsamkeitsgründen – DeepSeek V4 Flash, GLM-5.3 Flash und MiniMax M2.7 kosten gleich viel –, sondern wegen des Verhaltens und der Kapazität: Ein schlussfolgerndes Modell plant besser, ein Modell mit langen Antworten schreibt besser, und Hintergrund-Kleinigkeiten müssen nicht in derselben Warteschlange wie die Hauptaufgabe stehen.

# ~/.omp/agent/config.yml
modelRoles:
  default: joingonka/deepseek-ai/DeepSeek-V4-Flash-0731
  slow: joingonka/zai-org/GLM-5.3-Flash
  plan: joingonka/zai-org/GLM-5.3-Flash
  tiny: joingonka/MiniMaxAI/MiniMax-M2.7

retry:
  fallbackChains:
    default:
      - joingonka/zai-org/GLM-5.3-Flash

Der Block retry.fallbackChains ist eine Absicherung für Spitzenzeiten: Wenn das Hauptmodell hartnäckig 429 antwortet, überträgt omp den Rest des Zuges an den nächsten Eintrag in der Kette und kehrt nach einer Pause zum Hauptmodell zurück. Der Schlüssel der Kette kann eine Rolle, ein konkretes Modell oder der gesamte Provider (joingonka/*) sein.

Für einen einzelnen Start kann die Rolle mit einem Flag überschrieben werden: omp --model slow startet eine Sitzung mit dem Modell der Rolle slow, und --smol, --slow sowie --plan ersetzen das Modell der Rolle selbst. Innerhalb der Sitzung blättert Ctrl+P durch die Rollenmodelle, und /model öffnet die Auswahl; im Tab Roles dort können Rollen und deren Ersatzmodelle zugewiesen werden.

An den Wert der Rolle kann eine Ebene des Nachdenkens angehängt werden – :low, :medium, :high. Dies ist omp-Syntax, wie das Niveau von einem spezifischen Modell verstanden wird, hängt vom Modell selbst ab: GLM-5.3 Flash hat zum Beispiel einen binären Schalter – Details im Modellüberblick. Und noch ein nützliches Detail: Rollen können für ein einzelnes Repository mit der Datei <repo>/.omp/config.yml mit demselben Block modelRoles überschrieben werden. Provider und Schlüssel bleiben dabei im Home-Verzeichnis, sodass der Schlüssel nicht in das Repository gelangt.

Stelle zunächst sicher, dass omp den Anbieter sieht:

omp models joingonka

Als Antwort kommt eine Tabelle mit drei Zeilen mit Kontextfenstern und Antwort-Obergrenzen aus models.yml, auf Tausender gerundet (Ausgabe gekürzt: omp hat noch die Spalten thinking und images):

joingonka (3)
model                                context  max-out
deepseek-ai/DeepSeek-V4-Flash-0731      380K      33K
MiniMaxAI/MiniMax-M2.7                  200K     8.2K
zai-org/GLM-5.3-Flash                   390K     8.2K

Dann ein einzelner Durchlauf ohne Oberfläche. Lege in ein leeres Verzeichnis eine Datei mit einem offensichtlichen Fehler und bitte darum, ihn zu finden:

omp -p "Read calc.py and tell me in one sentence whether it has a bug."

Der Agent soll selbst das Lesewerkzeug aufrufen und inhaltlich antworten – mit Angabe des Ausdrucks, in dem der Fehler steckt. In unserem Durchlauf vom 21. September 2026 liefen DeepSeek V4 Flash und GLM-5.3 Flash sauber durch diesen Zyklus – Anfrage, Werkzeugaufruf, Ergebnis, Antwort; zu MiniMax M2.7 siehe die letzte Zeile der Tabelle unten.

Die dritte Prüfung erfolgt seitens des Gateways: Im Konto erscheint die Anfrage im Abschnitt „Nutzung“ in der Aufschlüsselung „Nach Modellen“, und im Block „Nach Schlüsseln“ wird der Zeitpunkt der letzten Anfrage aktualisiert. Ist dort nichts zu sehen, geht omp zu einem anderen Anbieter: Prüfe mit dem Befehl omp config get modelRoles, was auf den Rollen steht.

Wenn etwas schiefgelaufen ist, lässt sich die Diagnose meist direkt aus der Meldung ablesen:

Ein Agenten-Tool verbraucht Token anders als ein Chat: omp fügt jedem Ihrer Sätze einen System-Prompt und Tool-Beschreibungen hinzu, und eine Aufgabe erfordert normalerweise mehrere Schritte. In unserem Testlauf trug selbst bei nur einem aktivierten Lese-Tool jeder Schritt etwa 3,5 Tausend Eingabe-Token; mit einem vollständigen Satz sind es mehr. Daher ist der Token-Preis hier entscheidend.

Über das JoinGonka Gateway kosten Token $0.0069 pro Million bei der Eingabe und $0.021 pro Million bei der Ausgabe – der Preis ist für alle Netzwerkmodelle gleich und wird auf dieser Seite aus einer Live-Quelle übernommen.

Die Schätzungen in der rechten Spalte basieren auf den Preisen vom September 2026. Zum Vergleich – wie man grundsätzlich für Modelle in omp bezahlen kann:

Die Statuszeile von omp zeigt eine Kostenschätzung für die Sitzung an. Sie wird anhand des cost-Feldes in models.yml berechnet: Der Installer trägt dort den Gateway-Preis zum Zeitpunkt der Installation ein, während der Dollarpreis im Netzwerk zusammen mit dem GNK-Kurs schwankt, daher ist die Schätzung ein Richtwert. Den genauen Verbrauch und Restbetrag finden Sie im Dashboard in den Bereichen „Nutzung“ und „Abrechnung“. Warum die Standardwahl auf DeepSeek V4 Flash fiel, wird im Modell-Überblick ausführlich analysiert.

Bestätigungsmodus. Standardmäßig läuft omp im Modus yolo: Es genehmigt Lesen, Schreiben und Ausführen von Befehlen selbst. Im eigenen Projekt ist das praktisch, bei fremdem Code ein Grund, den Modus zu verschärfen oder in einen Container zu wechseln:

omp config set tools.approvalMode write

Im Modus write fragt der Agent nur bei der Ausführung von Befehlen um Erlaubnis, im Modus always-ask zusätzlich beim Schreiben. Für einen einzelnen Lauf legt das auch das Flag --approval-mode fest. Das ist eine Eigenschaft von omp selbst und hängt nicht vom Modellanbieter ab.

Pi und omp — Verwandte mit unterschiedlichen Konfigs. Die Konfiguration des einen Tools wird nicht auf das andere übertragen: Verzeichnisse, Formate und Feldnamen sind jeweils eigene.

Mehrere Umgebungen. Ein benanntes Profil (omp --profile work oder die Variable OMP_PROFILE) verschiebt alle Einstellungen nach ~/.omp/profiles/<name>/agent — praktisch, um berufliche und private Schlüssel zu trennen. Das aktuelle Agent-Verzeichnis gibt omp config path aus.

Wenn der Agent im Editor gebraucht wird. omp kann innerhalb von Zed über das Protokoll ACP arbeiten — das ist derselbe Agent mit denselben Einstellungen; Anbieter und Rollen müssen nicht erneut hinterlegt werden.