Betreibe Goose auf einem benutzerdefinierten OpenAI-kompatiblen Endpoint.

Kurzantwort: den openai-Provider behalten, den Host überschreiben.

Goose liefert einen dokumentierten Weg für benutzerdefinierte Endpoints: GOOSE_PROVIDER bleibt auf openai gesetzt, und du überschreibst, wohin dieser Provider zeigt. OPENAI_HOST ersetzt den Standard-Host api.openai.com, OPENAI_API_KEY authentifiziert, und GOOSE_MODEL wählt das Modell per exakter ID. Der Anfragepfad ist separat: OPENAI_BASE_PATH ist standardmäßig v1/chat/completions und braucht normalerweise keine Änderung. Achte genau auf die Form, denn sie ist das Gegenteil der meisten Tools dieser Klasse: OPENAI_HOST nimmt den nackten Host, https://api.apisrouter.com, ohne /v1-Suffix. Der Teil /v1/chat/completions liegt in OPENAI_BASE_PATH. /v1 an den Host anzuhängen verdoppelt den Pfad und erzeugt 404er, die wie ein kaputtes Gateway aussehen.

export GOOSE_PROVIDER=openai
export OPENAI_HOST=https://api.apisrouter.com   # bare host, no /v1
export OPENAI_API_KEY=sk-APIsRouter-...
export GOOSE_MODEL=claude-sonnet-4-6

goose session

Wie Goose mit seinem Provider spricht.

Goose (block auf GitHub, rund 51K Stars) ist ein autonomer Engineering-Agent von Block, der Aufgaben plant, Dateien bearbeitet, Shell-Befehle ausführt und MCP-basierte Extensions steuert. All das läuft über eine einzige Modell-Konversation: Jeder Schritt der Loop ist eine /v1/chat/completions-Anfrage mit angehängten Tool-Definitionen, sodass die Provider-Konfiguration entscheidet, wo der gesamte Agent läuft. Die Konfiguration ist geschichtet. Der interaktive Weg ist goose configure, das beim openai-Provider nach dem API-Key und einem optionalen benutzerdefinierten Host fragt und dann nicht-geheime Einstellungen wie GOOSE_PROVIDER und GOOSE_MODEL in ~/.config/goose/config.yaml schreibt; die Desktop-App bietet dieselben Provider-Einstellungen über ihre UI. Secrets werden separat behandelt: Keys landen im System-Schlüsselbund oder kommen aus Umgebungsvariablen, und ein direkt in config.yaml eingefügter Key wird ignoriert statt gelesen. Umgebungsvariablen überschreiben die Datei, was den Env-Weg oben überall funktionieren lässt, von der Laptop-Shell bis zum CI-Runner. Weil Goose GOOSE_MODEL als reinen String durchreicht, kann die ID alles sein, was der Endpoint hinter OPENAI_HOST bereitstellt: heute eine Claude-ID, morgen eine Kimi- oder Qwen-ID, nur eine Variable entfernt.

Der deklarative Weg: eine Custom-Provider-Datei.

Über das Env-Override hinaus beschreibt die aktuelle Goose-Dokumentation auch deklarative Custom-Provider: eine JSON-Datei, abgelegt unter ~/.config/goose/custom_providers/ (plattformspezifisches Config-Verzeichnis unter Windows), die einen benannten Provider neben den eingebauten registriert. Die Datei deklariert die engine (openai für Chat-Completions-Endpoints), welche Umgebungsvariable den Key hält, die Endpoint-URL und die Modelle, die der Provider anbietet. Achte hier auf die URL-Konvention, denn sie kehrt sich erneut um: Anders als bei OPENAI_HOST ist die base_url des Custom-Providers die vollständige Request-URL inklusive Pfad, https://api.apisrouter.com/v1/chat/completions. Jeder models-Eintrag trägt ein context_limit, damit Goose das Fenster kennt, das es packen kann. Die deklarative Datei ist die bessere Wahl, wenn du willst, dass das Gateway als eigener benannter Provider in Gooses Provider-Liste erscheint, mit eigener Key-Variable, statt den openai-Slot zu belegen. Das Env-Override ist die bessere Wahl für CI und schnelles Wechseln. Beide enden am selben Endpoint; wähle eines und stapele sie nicht.

{
  "name": "apisrouter",
  "display_name": "APIsRouter",
  "engine": "openai",
  "api_key_env": "APISROUTER_API_KEY",
  "base_url": "https://api.apisrouter.com/v1/chat/completions",
  "models": [
    { "name": "claude-sonnet-4-6", "context_limit": 200000 },
    { "name": "claude-opus-4-7",   "context_limit": 200000 },
    { "name": "kimi-k2.7-code",    "context_limit": 200000 }
  ],
  "supports_streaming": true,
  "requires_auth": true
}

Ein Modell für einen autonomen Agenten wählen.

Der praktische Workflow ist, deine Aufgabenmenge fest zu halten und GOOSE_MODEL zwischen zwei oder drei Kandidaten für jeweils ein paar Sitzungen rotieren zu lassen. Weil jeder Kandidat über denselben Key läuft, bepreist die Per-Key-Nutzungsansicht jedes Experiment, ohne dass du selbst Buch führen musst.

• Goose läuft unbeaufsichtigte Strecken: planen, bearbeiten, ausführen, Output lesen, wiederholen. Zuverlässigkeit bei Tool-Calls zählt mehr als reine Eloquenz, weshalb claude-sonnet-4-6 und claude-opus-4-7 die Standards sind, auf die sich die meisten für die Haupt-Loop einigen.
• Coding-optimierte IDs wie kimi-k2.7-code lohnt es sich für refactoring-lastige Sitzungen zu testen; über ein Gateway ist dieser Test eine einzige GOOSE_MODEL-Änderung, keine Provider-Migration.
• Lange Sitzungen summieren Kontext. Ein Modell mit einem echten 200k-Fenster, ehrlich über context_limit im deklarativen Weg angegeben, lässt Goose mehr Sitzungshistorie tragen, bevor zusammengefasst wird.
• Für skriptgesteuerte Nutzung oder CI reicht eine Mid-Tier-ID (gpt-5.4, qwen3.7-max) oft für gut abgegrenzte Aufgaben, zu einem Bruchteil der Spitzen-Ausgaben; miss an deinen eigenen Aufgaben, bevor du standardmäßig hochstufst.

Nutzungsbasiert · unter offiziellem Preis

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Die Fehlerbilder, die speziell bei Goose auftreten.

/v1 an OPENAI_HOST angehängt. Die Host-Variable nimmt den nackten Host; der Pfad liegt in OPENAI_BASE_PATH, das bereits standardmäßig v1/chat/completions ist. https://api.apisrouter.com/v1 als Host ergibt /v1/v1/...-Anfragen und 404er. Das ist der mit Abstand häufigste Fehler, gerade weil jedes andere Tool das /v1-Suffix will. Die Full-URL-Konvention in Custom-Provider-Dateien. Die deklarative base_url ist die vollständige Request-URL inklusive /v1/chat/completions, die entgegengesetzte Konvention zu OPENAI_HOST. Einen nackten Host in eine Custom-Provider-Datei zu kopieren bricht sie ebenso sicher wie eine vollständige URL in OPENAI_HOST zu kopieren. Keys in config.yaml authentifizieren nicht. Goose liest Secrets aus dem Schlüsselbund oder der Umgebung und ignoriert Key-Werte, die in config.yaml stehen. Hält ein 401 nach dem Bearbeiten der Datei an, liegt es daran; exportiere die Variable oder führe goose configure erneut aus und gib den Key ein, wenn danach gefragt wird. Desktop-Sitzungen sehen keine Shell-Exports. Die Desktop-App erbt nichts von deinem Terminal-Profil. Konfiguriere den Provider über die Desktop-Einstellungs-UI, oder starte aus einer Shell, in der die Variablen gesetzt sind. Gestapelte Konfigurationsquellen. Ein alter OPENAI_HOST-Export kann überschreiben, was du gerade in config.yaml gesetzt hast, weil die Umgebung die Datei schlägt. Wenn das Routing falsch aussieht, gib die relevanten Variablen in derselben Shell aus, die Goose startet, bevor du eine der beiden Ebenen verdächtigst.

Wer Goose über ein Gateway routet.

• Engineers, die Goose als tägliches Werkzeug nutzen und Claude, GPT, Kimi und Qwen hinter einem Key erreichbar wollen, statt einen Credential-Satz pro Anbieter.
• Teams, die Goose in CI oder geplante Jobs einbinden. Der reine Env-Weg bedeutet, dass der Runner genau zwei Routing-Variablen und ein Secret braucht, leicht einzuschleusen und leicht zu rotieren.
• Entwickler, die Agent-Modelle an echten Aufgaben vergleichen. Jeder Kandidat ist ein GOOSE_MODEL-Wert gegen denselben Endpoint, automatisch bepreist durch die Per-Key-Nutzung.
• Platform-Teams, die Agent-Ausgaben pro Key und pro Modell auf einer Abrechnungsoberfläche sichtbar wollen, statt mehrere Vendor-Dashboards abzugleichen.
• Entwickler ohne Zugang zur Abrechnung eines bestimmten Anbieters. Guthabenbasierter Zugang ohne Kartenpflicht entfernt die Sign-up-Abhängigkeit pro Provider.

Den Endpoint verifizieren und die erste Sitzung debuggen.

Bestätige, dass das Gateway die ID aus GOOSE_MODEL bereitstellt, bevor du eine Sitzung startest; die /v1/models-Liste ist die maßgebliche Schreibweise, Versions-Suffixe eingeschlossen. Fehler bei der ersten Sitzung sind konsistent. Ein 404 bedeutet, dass Host und Pfad falsch zusammengesetzt wurden, fast immer /v1 in OPENAI_HOST. Ein 401 bedeutet, dass der Key nicht dort liegt, wo Goose nachschaut: nicht exportiert in der Shell, die es gestartet hat, nicht im Schlüsselbund, oder nutzlos in config.yaml. Ein „Model not found"-Fehler vom Gateway ist ein Tippfehler in der ID in GOOSE_MODEL. Startet die Sitzung, verhalten sich Tool-Calls aber seltsam, prüfe, ob du ein Modell nutzt, das Tool-Use tatsächlich unterstützt; die IDs in der obigen Tabelle tun das alle. Sobald die Loop läuft, zeigt die APIsRouter-Konsole Modell, Token-Zahlen und Ausgaben pro Anfrage. Ein autonomer Agent ist der Workload, bei dem das am meisten zählt: Sitzungen sind lang, Tool-Call-Turns sind zahlreich, und die Nutzungsansicht zeigt dir, was ein Nachmittag mit Goose tatsächlich gekostet hat.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY" | head -50

Häufige Fragen