Draai Goose op een aangepast OpenAI-compatibel endpoint.

Updated 2026-07-29

De provider openai van Goose accepteert een host-override. Zet GOOSE_PROVIDER=openai, wijs OPENAI_HOST naar https://api.apisrouter.com, exporteer één sleutel, en de hele agentlus, tool calls inbegrepen, routeert via één enkel endpoint met elk catalogusmodel aanspreekbaar per ID.

Snel antwoord: behoud de provider openai, override de host.

Goose levert een gedocumenteerd pad voor aangepaste endpoints: houd GOOSE_PROVIDER ingesteld op openai en override waar die provider naartoe wijst. OPENAI_HOST vervangt de standaardhost api.openai.com, OPENAI_API_KEY authenticeert, en GOOSE_MODEL kiest het model op exact ID. Het verzoekpad is apart: OPENAI_BASE_PATH staat standaard op v1/chat/completions en hoeft normaal niet gewijzigd te worden. Let goed op de vorm, want het is het omgekeerde van de meeste tools in deze klasse: OPENAI_HOST neemt de kale host, https://api.apisrouter.com, zonder /v1-suffix. Het deel /v1/chat/completions leeft in OPENAI_BASE_PATH. /v1 aan de host toevoegen verdubbelt het pad en produceert 404's die eruitzien als een kapotte gateway.

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

Hoe Goose met zijn provider praat.

Goose (block op GitHub, ruim 51K sterren) is een autonome engineeringagent van Block die taken plant, bestanden bewerkt, shellopdrachten uitvoert en MCP-gebaseerde extensies aanstuurt. Dat alles rust op één modelgesprek: elke stap van de lus is een /v1/chat/completions-verzoek met tooldefinities eraan gehecht, dus de providerconfiguratie bepaalt waar de hele agent draait. Configuratie is gelaagd. Het interactieve pad is goose configure, dat voor de provider openai vraagt om de API-sleutel en een optionele aangepaste host, en vervolgens niet-geheime instellingen zoals GOOSE_PROVIDER en GOOSE_MODEL wegschrijft naar ~/.config/goose/config.yaml; de desktopapp toont dezelfde providerinstellingen via zijn UI. Secrets worden apart behandeld: sleutels gaan naar de systeemsleutelketen of komen uit omgevingsvariabelen, en een sleutel die rechtstreeks in config.yaml is geplakt, wordt genegeerd in plaats van gelezen. Omgevingsvariabelen overschrijven het bestand, en dat is waarom het bovenstaande env-pad overal werkt, van een laptopshell tot een CI-runner. Omdat Goose GOOSE_MODEL als platte string doorgeeft, kan het ID alles zijn wat het endpoint achter OPENAI_HOST bedient: vandaag een Claude-ID, morgen een Kimi- of Qwen-ID, één variabele verschil.

Het declaratieve pad: een bestand voor een aangepaste provider.

Naast de env-override beschrijft de huidige documentatie van Goose ook declaratieve aangepaste providers: een JSON-bestand dat je in ~/.config/goose/custom_providers/ plaatst (platformspecifieke configuratiemap op Windows) en dat een benoemde provider naast de ingebouwde registreert. Het bestand declareert de engine (openai voor chat-completions-endpoints), welke omgevingsvariabele de sleutel bevat, de endpoint-URL, en de modellen die de provider aanbiedt. Let hier op de URL-conventie, want die draait weer om: in tegenstelling tot OPENAI_HOST is de base_url van de aangepaste provider de volledige verzoek-URL inclusief het pad, https://api.apisrouter.com/v1/chat/completions. Elke models-vermelding draagt een context_limit zodat Goose weet welk venster het kan inpakken. Het declaratieve bestand past beter als je wilt dat de gateway als zijn eigen benoemde provider verschijnt in de providerlijst van Goose, met zijn eigen sleutelvariabele, in plaats van het slot openai in te nemen. De env-override past beter voor CI en snel wisselen. Beide komen bij hetzelfde endpoint uit; kies er één en stapel ze niet.

{
  "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
}

Een model kiezen voor een autonome agent.

De praktische workflow is om je takenset vast te houden en GOOSE_MODEL over twee of drie kandidaten te roteren voor een paar sessies elk. Omdat elke kandidaat via dezelfde sleutel routeert, prijst de gebruiksweergave per sleutel elk experiment zonder enige boekhouding aan jouw kant.

  • Goose draait onbewaakte periodes: plannen, bewerken, draaien, output lezen, herhalen. Betrouwbaarheid van tool calls telt zwaarder dan pure welsprekendheid, en daarom komen mensen voor de hoofdlus vaak uit bij claude-sonnet-4-6 en claude-opus-4-7 als standaard.
  • Codegestemde ID's zoals kimi-k2.7-code zijn het waard om te testen bij refactor-zware sessies; via een gateway is die test één wijziging in GOOSE_MODEL, geen providermigratie.
  • Lange sessies stapelen context op. Een model met een echt venster van 200k, eerlijk gedeclareerd via context_limit in het declaratieve pad, laat Goose meer sessiegeschiedenis meedragen voordat er wordt samengevat.
  • Voor gescript of CI-gebruik haalt een midtier-ID (gpt-5.4, qwen3.7-max) vaak de lat voor goed afgebakende taken tegen een fractie van de frontier-uitgaven; meet op je eigen taken voordat je standaard omhoog gaat.

Betaal naar gebruik · onder officiële prijzen

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

ModelOfficiële prijsOnze prijs
Claude Sonnet 4.6$3.00 / $15.00 per M$2.40 / $12.00 per M
Claude Opus 4.7$5.00 / $25.00 per M$4.00 / $20.00 per M
GPT-5.4$2.50 / $15.00 per M$2.00 / $12.00 per M
Kimi K2.7 Code$0.95 / $4.00 per M$1.00 / $4.00 per M
Qwen 3.7 Max$2.50 / $7.50 per M$2.50 / $7.50 per M

De faalmodi specifiek voor Goose.

/v1 toegevoegd aan OPENAI_HOST. De host-variabele neemt de kale host; het pad leeft in OPENAI_BASE_PATH, dat al standaard op v1/chat/completions staat. https://api.apisrouter.com/v1 als host levert /v1/v1/...-verzoeken en 404's op. Dit is verreweg de meest voorkomende fout, precies omdat elke andere tool het /v1-suffix wil. De volledige-URL-conventie in bestanden voor aangepaste providers. De declaratieve base_url is de complete verzoek-URL inclusief /v1/chat/completions, de tegenovergestelde conventie van OPENAI_HOST. Een kale host in een bestand voor een aangepaste provider plakken breekt het net zo zeker als een volledige URL in OPENAI_HOST plakken. Sleutels in config.yaml authenticeren niet. Goose leest secrets uit de sleutelketen of de omgeving, en negeert sleutelwaarden die in config.yaml zijn geplaatst. Als een 401 aanhoudt na het bewerken van het bestand, is dat de reden; exporteer de variabele of draai goose configure opnieuw en voer de sleutel in wanneer daarom wordt gevraagd. Desktopsessies zien shellexports niet. De desktopapp erft niets van je terminalprofiel. Configureer de provider via de desktopinstellingen-UI, of start vanuit een shell waarin de variabelen zijn ingesteld. Gestapelde configuratiebronnen. Een oude OPENAI_HOST-export kan overschrijven wat je zojuist in config.yaml hebt ingesteld, omdat omgeving wint van bestand. Als routering er verkeerd uitziet, print dan de relevante variabelen in dezelfde shell die Goose start voordat je een van beide lagen de schuld geeft.

Wie routeert Goose via een gateway.

  • Engineers die Goose als dagelijkse workhorse draaien en Claude, GPT, Kimi en Qwen bereikbaar willen achter één sleutel in plaats van één credentialset per leverancier.
  • Teams die Goose in CI of geplande jobs zetten. Het env-only-pad betekent dat de runner precies twee routingvariabelen en één secret nodig heeft, makkelijk te injecteren en makkelijk te roteren.
  • Developers die agentmodellen vergelijken op echte taken. Elke kandidaat is één GOOSE_MODEL-waarde tegen hetzelfde endpoint, automatisch geprijsd door gebruik per sleutel.
  • Platformteams die agentuitgaven zichtbaar willen per sleutel en per model op één factureringsoppervlak, in plaats van meerdere leveranciersdashboards te reconciliëren.
  • Developers zonder toegang tot de facturering van een bepaalde leverancier. Toegang op basis van opwaarderen zonder kaartvereiste verwijdert de aanmeldingsafhankelijkheid per provider.

Verifieer het endpoint en debug de eerste sessie.

Bevestig dat de gateway het ID in GOOSE_MODEL bedient voordat je een sessie start; de /v1/models-lijst is de gezaghebbende spelling, versiesuffixen inbegrepen. Mislukkingen bij de eerste sessie zijn consistent. Een 404 betekent dat host en pad verkeerd zijn samengesteld, bijna altijd /v1 in OPENAI_HOST. Een 401 betekent dat de sleutel niet staat waar Goose zoekt: niet geëxporteerd in de shell die het startte, niet in de sleutelketen, of nutteloos in config.yaml. Een model-not-found-fout van de gateway is een tikfout in het ID in GOOSE_MODEL. Als de sessie start maar tool calls zich vreemd gedragen, controleer dan of je op een model zit dat daadwerkelijk tool-gebruik ondersteunt; de ID's in de bovenstaande tabel doen dat allemaal. Zodra de lus draait, toont de APIsRouter-console model per verzoek, tokenaantallen en uitgaven. Een autonome agent is de workload waar dit het meest toe doet: sessies zijn lang, tool-call-beurten zijn talrijk, en de gebruiksweergave is hoe je ziet wat een middag Goose daadwerkelijk heeft gekost.

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

Veelgestelde vragen

Kan Goose Claude- of Kimi-modellen aansturen via zijn provider openai?

Ja. De provider openai is een protocolclient, geen leveranciersvergrendeling: met OPENAI_HOST gericht op een endpoint met meerdere leveranciers, kan GOOSE_MODEL elk bediend ID zijn, Claude, Kimi en Qwen inbegrepen, en de agentlus met tool calling werkt ongewijzigd.

Heeft OPENAI_HOST het /v1-suffix nodig?

Nee, en het toevoegen ervan breekt de routering. OPENAI_HOST neemt de kale host (https://api.apisrouter.com); het verzoekpad leeft in OPENAI_BASE_PATH, dat standaard op v1/chat/completions staat. Dit is het omgekeerde van de conventie die de meeste tools gebruiken.

Wat is het verschil tussen de env-override en een bestand voor een aangepaste provider?

De env-override herroutt de ingebouwde provider openai: het snelst in te stellen, ideaal voor CI. Een JSON voor een aangepaste provider in ~/.config/goose/custom_providers/ registreert de gateway als zijn eigen benoemde provider met zijn eigen sleutelvariabele en modellenlijst. Sowieso hetzelfde endpoint; kies er één.

Waarom negeert Goose de API-sleutel die ik in config.yaml heb gezet?

Met opzet. Goose leest secrets uit de systeemsleutelketen of omgevingsvariabelen en negeert sleutels in config.yaml. Exporteer OPENAI_API_KEY (of je api_key_env-variabele), of voer de sleutel in via goose configure of de desktopinstellingen zodat hij in de sleutelketen terechtkomt.

Delen de CLI en de desktopapp deze configuratie?

Ze delen config.yaml en de sleutelketen, maar niet je shellomgeving: variabelen die in een terminal zijn geëxporteerd, bereiken CLI-sessies die vanuit die terminal zijn gestart, niet de desktopapp. Configureer de desktopapp via zijn instellingen-UI, of vertrouw op het gedeelde configuratiebestand plus de sleutelketen.

Welk model moet GOOSE_MODEL noemen voor agentwerk?

Begin met claude-sonnet-4-6 voor de hoofdlus; het houdt goed stand bij meerstaps tool-gebruik. Test kimi-k2.7-code bij refactor-zware sessies en een midtier-ID bij goed afgebakende CI-taken. Achter één endpoint is elke test een wijziging van één variabele.