Fai girare Goose su un endpoint personalizzato compatibile OpenAI.

Risposta rapida: mantieni il provider openai, sovrascrivi l'host.

Goose fornisce un percorso documentato per endpoint personalizzati: mantieni GOOSE_PROVIDER impostato su openai e sovrascrivi dove punta quel provider. OPENAI_HOST sostituisce l'host predefinito api.openai.com, OPENAI_API_KEY autentica, e GOOSE_MODEL sceglie il modello per id esatto. Il percorso della richiesta è separato: OPENAI_BASE_PATH ha come default v1/chat/completions e normalmente non necessita modifiche. Nota la forma con attenzione, perché è l'opposto della maggior parte degli strumenti di questa classe: OPENAI_HOST prende l'host nudo, https://api.apisrouter.com, senza suffisso /v1. La parte /v1/chat/completions risiede in OPENAI_BASE_PATH. Aggiungere /v1 all'host raddoppia il percorso e produce 404 che sembrano un gateway rotto.

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

Come Goose parla con il suo provider.

Goose (block su GitHub, circa 51K stelle) è un agente di ingegneria autonomo di Block che pianifica task, modifica file, esegue comandi shell, e guida estensioni basate su MCP. Tutto ciò risiede in un'unica conversazione con il modello: ogni passo del ciclo è una richiesta /v1/chat/completions con definizioni di strumenti allegate, quindi la configurazione del provider decide dove gira l'intero agente. La configurazione è a strati. Il percorso interattivo è goose configure, che per il provider openai chiede la chiave API e un host personalizzato opzionale, poi scrive impostazioni non segrete come GOOSE_PROVIDER e GOOSE_MODEL in ~/.config/goose/config.yaml; l'app desktop espone le stesse impostazioni provider tramite la sua UI. I segreti sono gestiti separatamente: le chiavi vanno nel portachiavi di sistema o provengono da variabili d'ambiente, e una chiave incollata direttamente in config.yaml viene ignorata invece che letta. Le variabili d'ambiente hanno la precedenza sul file, il che è ciò che rende il percorso via env sopra funzionante ovunque, da una shell su laptop a un runner CI. Poiché Goose passa GOOSE_MODEL come semplice stringa, l'id può essere qualsiasi cosa serva l'endpoint dietro OPENAI_HOST: un id Claude oggi, un id Kimi o Qwen domani, a distanza di una variabile.

Il percorso dichiarativo: un file di provider personalizzato.

Oltre all'override via env, la documentazione attuale di Goose descrive anche i provider personalizzati dichiarativi: un file JSON inserito in ~/.config/goose/custom_providers/ (directory di configurazione per piattaforma su Windows) che registra un provider con nome accanto a quelli integrati. Il file dichiara l'engine (openai per gli endpoint chat-completions), quale variabile d'ambiente contiene la chiave, l'URL dell'endpoint, e i modelli che il provider offre. Fai attenzione alla convenzione dell'URL qui, perché si ribalta di nuovo: a differenza di OPENAI_HOST, il base_url del provider personalizzato è l'URL completo della richiesta incluso il percorso, https://api.apisrouter.com/v1/chat/completions. Ogni voce models porta un context_limit così che Goose sappia la finestra che può impacchettare. Il file dichiarativo è la scelta migliore quando vuoi che il gateway compaia come proprio provider con nome nella lista dei provider di Goose, con la propria variabile chiave, invece di occupare lo slot openai. L'override via env è la scelta migliore per CI e cambi rapidi. Entrambi arrivano allo stesso endpoint; scegline uno ed evita di impilarli.

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

Scegliere un modello per un agente autonomo.

Il workflow pratico è tenere fisso il tuo set di task e far ruotare GOOSE_MODEL tra due o tre candidati per alcune sessioni ciascuno. Poiché ogni candidato instrada attraverso la stessa chiave, la vista di utilizzo per chiave prezza ogni esperimento senza alcuna contabilità da parte tua.

• Goose gira in tratti non presidiati: pianifica, modifica, esegui, leggi l'output, ripeti. L'affidabilità delle tool call conta più dell'eloquenza grezza, ed è per questo che claude-sonnet-4-6 e claude-opus-4-7 sono i default su cui converge la gente per il ciclo principale.
• Gli id ottimizzati per il coding come kimi-k2.7-code vale la pena testarli per sessioni ricche di refactoring; attraverso un gateway quel test è un singolo cambio di GOOSE_MODEL, non una migrazione di provider.
• Le sessioni lunghe accumulano contesto. Un modello con una finestra genuina da 200k, dichiarata onestamente via context_limit nel percorso dichiarativo, permette a Goose di portare più cronologia di sessione prima di riassumere.
• Per l'uso scriptato o in CI, un id di fascia media (gpt-5.4, qwen3.7-max) spesso supera l'asticella per task ben delimitati a una frazione della spesa di frontiera; misura sui tuoi task prima di salire di default.

Pagamento a consumo · sotto i prezzi ufficiali

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

Le modalità di errore specifiche di Goose.

/v1 aggiunto a OPENAI_HOST. La variabile host prende l'host nudo; il percorso risiede in OPENAI_BASE_PATH, che ha già come default v1/chat/completions. https://api.apisrouter.com/v1 come host produce richieste /v1/v1/... e 404. Questo è l'errore più comune in assoluto, precisamente perché ogni altro strumento vuole il suffisso /v1. La convenzione URL completo nei file di provider personalizzato. Il base_url dichiarativo è l'URL completo della richiesta incluso /v1/chat/completions, la convenzione opposta rispetto a OPENAI_HOST. Copiare un host nudo in un file di provider personalizzato lo rompe con la stessa certezza con cui copiare un URL completo in OPENAI_HOST. Le chiavi in config.yaml non autenticano. Goose legge i segreti dal portachiavi o dall'ambiente, e ignora i valori di chiave inseriti in config.yaml. Se un 401 persiste dopo aver modificato il file, è per questo; esporta la variabile o riesegui goose configure e inserisci la chiave quando richiesto. Le sessioni desktop non vedono gli export di shell. L'app desktop non eredita nulla dal tuo profilo di terminale. Configura il provider tramite la UI delle impostazioni desktop, oppure lancia da una shell che ha le variabili impostate. Fonti di configurazione impilate. Un vecchio export di OPENAI_HOST può sovrascrivere ciò che hai appena impostato in config.yaml, perché l'ambiente batte il file. Quando l'instradamento sembra sbagliato, stampa le variabili rilevanti nella stessa shell che lancia Goose prima di dare la colpa a uno dei due livelli.

Chi instrada Goose tramite un gateway.

• Ingegneri che usano Goose come daily driver e vogliono Claude, GPT, Kimi e Qwen raggiungibili dietro una chiave invece di un set di credenziali per fornitore.
• Team che inseriscono Goose in CI o job schedulati. Il percorso solo-env significa che il runner ha bisogno esattamente di due variabili di instradamento e un segreto, facile da iniettare e facile da ruotare.
• Sviluppatori che confrontano modelli agente su task reali. Ogni candidato è un valore GOOSE_MODEL contro lo stesso endpoint, prezzato automaticamente dall'utilizzo per chiave.
• Team di piattaforma che vogliono la spesa dell'agente visibile per chiave e per modello su un'unica superficie di fatturazione, invece di riconciliare diverse dashboard fornitore.
• Sviluppatori senza accesso alla fatturazione di un dato fornitore. L'accesso basato su ricarica senza obbligo di carta rimuove la dipendenza dalla registrazione per provider.

Verifica l'endpoint e fai debug della prima sessione.

Conferma che il gateway serva l'id in GOOSE_MODEL prima di iniziare una sessione; l'elenco /v1/models è l'ortografia autorevole, suffissi di versione inclusi. I fallimenti della prima sessione sono coerenti. Un 404 significa che host e percorso si sono composti male, quasi sempre /v1 in OPENAI_HOST. Un 401 significa che la chiave non è dove Goose la cerca: non esportata nella shell che l'ha lanciato, non nel portachiavi, o seduta inutilmente dentro config.yaml. Un errore modello-non-trovato dal gateway è un errore di battitura dell'id in GOOSE_MODEL. Se la sessione parte ma le tool call si comportano stranamente, controlla di essere su un modello che supporta davvero l'uso di strumenti; gli id nella tabella sopra lo fanno tutti. Una volta che il ciclo gira, la console di APIsRouter mostra modello per richiesta, conteggi dei token e spesa. Un agente autonomo è il carico di lavoro dove questo conta di più: le sessioni sono lunghe, i turni di tool-call sono molti, e la vista di utilizzo è come vedi quanto è costato davvero un pomeriggio di Goose.

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

Domande frequenti