Codex CLI: eigener Schlüssel statt Abonnement

Codex ist kein Hinweisgeber im Editor, sondern ein eigenständiger Ausführender. Sie formulieren die Aufgabe in Worten, er entscheidet selbst, welche Dateien er liest, welche Befehle er ausführt und was er ändert. Ihm stehen rund ein Dutzend Werkzeuge zur Verfügung: Befehle ausführen, Dateien lesen, einen Arbeitsplan führen, beim Nutzer um Klärung bitten, untergeordnete Agenten für Teilaufgaben erzeugen.

Zwei Betriebsmodi. Interaktiv — codex ohne Argumente, Dialog im Terminal mit Anzeige jedes Schritts. Nicht interaktiv — codex exec "task", ein einmaliger Durchlauf bis zum Ergebnis: praktisch in Skripten und CI.

Sicherheit ist eingebaut: Standardmäßig arbeitet der Agent in einer Sandbox und fragt vor Änderungen um Bestätigung. Die Kontrollstufe wird in der Konfiguration festgelegt — von „alles erfragen" bis zum vollständig autonomen Durchlauf mit Schreibrecht im Arbeitsverzeichnis.

Eine weitere Besonderheit — der Zustand des Dialogs. Codex bittet den Server um nichts zu merken: Er hält die gesamte Historie bei sich und sendet sie bei jedem Zug vollständig mit. Für Sie bedeutet das, dass die Korrespondenz nicht auf der Seite des Modellanbieters liegen bleibt und ein Wechsel des Endpunkts eine begonnene Sitzung nicht zerstört.

Der Unterschied zu Claude Code und anderen Terminal-Agenten liegt genau im Protokoll. Codex kommuniziert mit dem Modell über die Responses API, bei der die Korrespondenz nicht als flache Liste von Nachrichten beschrieben wird, sondern als Band von Elementen: Text, Werkzeugaufruf, Ergebnis des Aufrufs, Reasoning-Block. Dem Werkzeug gibt das ein strengeres Dialogmodell, Ihnen die Notwendigkeit, einen Endpunkt zu haben, der dieses Protokoll versteht.

Schneller Weg — der Installer. Der Befehl npx @joingonka/setup --tool codex ergänzt in ~/.codex/config.toml selbst einen Provider-Block mit wire_api = "responses", dem Modell und seinem tatsächlichen Kontextfenster, behält deine Kommentare und übrigen Einstellungen bei und prüft anschließend per Live-Anfrage Schlüssel und Modell. Ist in der Config bereits ein anderer Provider ausgewählt, lässt der Installer ihn unangetastet und zeigt dir den Befehl für einen einmaligen Start. Den Schlüssel legt er direkt in die Datei (Rechte 600), ins Feld experimental_bearer_token — das einzige, in dem Codex den Schlüssel als Literal speichern kann; Codex selbst betrachtet es als experimentell. Die manuelle Variante unten kommt mit einer Umgebungsvariable aus.

Codex speichert seine Einstellungen in ~/.codex/config.toml. Ein eigener Provider wird über einen [model_providers.*]-Block beschrieben, und das entscheidende Feld ist hier wire_api: Ohne es versucht Codex, über Chat Completions zu sprechen, und bekommt den Agentenzyklus nicht zum Laufen.

# ~/.codex/config.toml
model_provider = "joingonka"
model = "deepseek-ai/DeepSeek-V4-Flash-0731"

[model_providers.joingonka]
name = "JoinGonka Gateway"
base_url = "https://gate.joingonka.ai/v1"
env_key = "JOINGONKA_API_KEY"
wire_api = "responses"

Der Schlüssel wird nicht in die Datei geschrieben: env_key benennt die Umgebungsvariable, aus der Codex ihn nimmt. Der Variablenname ist ein eigener, nicht OPENAI_API_KEY — so greift die Konfiguration nicht in deine anderen Tools ein, die mit OpenAI arbeiten.

export JOINGONKA_API_KEY=jg-your-key

Das Feld model legt das Standardmodell fest, model_provider gibt an, welcher der beschriebenen Blöcke verwendet wird. Beide lassen sich beim Start überschreiben, sodass eine einzige Config problemlos mehrere Provider bedient: den produktiven, den experimentellen und einen Ersatz.

Der Schlüssel wird nach der Registrierung im persönlichen Konto ausgegeben, dort sind auch Guthaben und Verbrauch einsehbar. Wenn du die allgemeine Config lieber nicht anfassen möchtest, kannst du denselben Block einmalig über -c übergeben: codex -c model_provider=joingonka …. Und um mehrere unabhängige Konfigurationen zu pflegen, gibst du das Einstellungsverzeichnis über die Variable CODEX_HOME an.

Der schnellste Weg herauszufinden, ob die Verbindung funktioniert, ist ein einmaliger Testlauf:

codex exec "Answer in one line: what is 17*3?"

In der Kopfzeile der Antwort gibt Codex aus, mit wem er arbeitet: model, provider: joingonka, den Sandbox-Modus und die Session-ID. Steht dort euer Anbieter und kommt unten eine Antwort an, lebt die Verbindung.

Als Nächstes solltet ihr das prüfen, wofür Codex überhaupt installiert wird — die Arbeit mit Dateien. Legt eine kleine Datei mit einem offensichtlichen Fehler ins Verzeichnis und bittet darum, ihn zu finden:

codex exec "Read calc.py and tell me in one sentence whether it has a bug."

Der Agent muss von sich aus das Lesewerkzeug aufrufen, die Datei öffnen und inhaltlich antworten — mit Angabe der Zeile. Passiert das, wird der vollständige agentische Zyklus (Anfrage → Werkzeugaufruf → Ergebnis → Antwort) über das Gateway korrekt zusammengesetzt.

Läuft etwas schief, lässt sich die Diagnose meist direkt aus der Meldung ablesen:

Die erste Anfrage in einer Session kann einige Sekunden dauern: Codex sendet einen großen System-Prompt und die Beschreibung aller seiner Werkzeuge, und der Netzwerkknoten muss die Aufgabe annehmen. Die folgenden Antworten kommen schneller.

Alle Netzmodelle sind zum gleichen Preis verfügbar, daher geht es bei der Auswahl um das Verhalten, nicht um das Budget. Unten sehen Sie das Ergebnis eines Live-Durchlaufs derselben Aufgabe (Lesen einer Datei und Fehlersuche) durch Codex auf DeepSeek V4 Flash und MiniMax M2.7; GLM-5.3 Flash kam erst nach dem Durchlauf ins Netzwerk — hier sind die Modelleigenschaften aufgeführt.

Die Standardempfehlung ist DeepSeek V4 Flash: Die Agentenarbeit stößt schnell an die Kontextgröße, und 380K Token ermöglichen es, viele Dateien gleichzeitig im Gedächtnis zu behalten. Wenn eine Aufgabe das Nachdenken über eine komplexe Logik erfordert, nehmen Sie GLM-5.3 Flash, aber planen Sie einen Puffer bei max_tokens ein: Ein Teil des Antwortbudgets wird für den Denkprozess verwendet. Das Modell wird durch eine einzige Zeile model in der Konfigurationsdatei oder das Flag -c model=… gewechselt, ohne die Datei zu bearbeiten.

Die aktuelle Liste der Netzmodelle gibt immer GET https://gate.joingonka.ai/v1/models zurück.

Agentenwerkzeuge verbrauchen Token anders als ein Chat: Codex fügt jeder Ihrer Aussagen einen System-Prompt und eine Beschreibung aller Werkzeuge hinzu und führt dann einen mehrstufigen Dialog mit dem Modell. Bei einem Live-Durchlauf der einfachen Aufgabe „Lese eine Datei und finde den Fehler“ wurden etwa 18.000 bis 20.000 Token verbraucht. Dies ist ein angemessener Preis für die Autonomie, und genau deshalb ist der Preis pro Token entscheidend.

Über das JoinGonka Gateway kosten Token $0.0069 pro Million beim Input und $0.021 pro Million beim Output – der Preis ist für alle Netzwerkmodelle gleich und wird auf dieser Seite aus der Live-Quelle bezogen.

Zum Vergleich – wie kostenpflichtige Optionen bei Codex selbst und bei Wettbewerbern strukturiert sind:

Die Abrechnung erfolgt nach tatsächlichem Verbrauch, ohne monatliches Abonnement und ohne Anfragelimits: Es gibt keine 5-Stunden-Fenster, „Prompt“-Limits oder Multiplikatoren zu Spitzenzeiten. Das Guthaben wird mit Kryptowährung aufgeladen; Saldo und täglicher Verbrauch sind im persönlichen Bereich einsehbar. Eine detaillierte Analyse der Wirtschaftlichkeit finden Sie im Artikel über die günstigste AI API.

Die Dialoghistorie wird von Codex selbst verwaltet. Es sendet sie bei jeder Anfrage vollständig mit und verlangt nicht vom Server, sich etwas zu merken – und wir speichern keine Chats. Ihr Code und Ihre Prompts verbleiben nach der Antwort nicht auf dem Gateway.

Websuche ist aktiv. Codex kündigt bei jeder Anfrage ein Suchwerkzeug an und das Gateway akzeptiert es: Die Suche erfolgt auf unserer Seite, die Ergebnisse werden in die Antwort des Modells eingefügt.

Werkzeuge sind lokal, nicht in der Cloud. Codex führt Befehle aus und liest Dateien lokal auf Ihrem Computer, daher hängt der Zugriff auf das Projekt nicht vom Modellanbieter ab.

Sandbox. Unter Linux verwendet Codex bubblewrap, um die ausgeführten Befehle zu isolieren. Wenn es nicht im System vorhanden ist, warnt Codex und verwendet eine integrierte Kopie – dies hat keinen Einfluss auf die Funktionalität, aber das Paket ist bequemer über den Standard-Manager zu installieren.

Wenn Sie mit Bildern arbeiten müssen – Screenshots der Benutzeroberfläche, Schemata auf Fotos –, verwenden Sie für solche Aufgaben ein Tool mit einem Modell, das über Vision-Fähigkeiten verfügt: Im Gonka Netzwerk sind die Modelle textbasiert. Für Code, Befehle und Dateien ist dies jedoch keine Einschränkung.

Andere Terminal-Agenten, falls Codex nicht geeignet ist: Der API-Schnellstart zeigt, wie man in wenigen Minuten ein kompatibles Tool anschließt.