Rode o Goose em um endpoint compatível com OpenAI personalizado.

Resposta rápida: mantenha o provider openai, sobrescreva o host.

O Goose vem com um caminho de endpoint personalizado documentado: mantenha GOOSE_PROVIDER definido como openai e sobrescreva para onde esse provider aponta. OPENAI_HOST substitui o host padrão api.openai.com, OPENAI_API_KEY autentica, e GOOSE_MODEL escolhe o modelo pelo id exato. O caminho da requisição é separado: OPENAI_BASE_PATH usa v1/chat/completions por padrão e normalmente não precisa de mudança. Preste atenção no formato com cuidado, porque é o inverso da maioria das ferramentas dessa classe: OPENAI_HOST recebe o host puro, https://api.apisrouter.com, sem sufixo /v1. A parte /v1/chat/completions vive em OPENAI_BASE_PATH. Anexar /v1 ao host duplica o caminho e produz 404s que parecem um gateway quebrado.

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

goose session

Como o Goose fala com seu provider.

O Goose (block no GitHub, cerca de 51 mil estrelas) é um agente de engenharia autônomo da Block que planeja tarefas, edita arquivos, roda comandos de shell, e dirige extensões baseadas em MCP. Tudo isso se apoia em uma única conversa de modelo: cada passo do loop é uma requisição /v1/chat/completions com definições de ferramenta anexadas, então a configuração de provider decide onde o agente inteiro roda. A configuração é em camadas. O caminho interativo é goose configure, que para o provider openai pergunta a chave de API e um host personalizado opcional, depois grava configurações não sensíveis como GOOSE_PROVIDER e GOOSE_MODEL em ~/.config/goose/config.yaml; o app de desktop expõe as mesmas configurações de provider pela sua UI. Segredos são tratados separadamente: chaves vão para o keychain do sistema ou vêm de variáveis de ambiente, e uma chave colada diretamente no config.yaml é ignorada em vez de lida. Variáveis de ambiente sobrescrevem o arquivo, o que é o que faz o caminho de env acima funcionar em qualquer lugar, de um shell de laptop a um runner de CI. Como o Goose passa GOOSE_MODEL adiante como uma string simples, o id pode ser qualquer coisa que o endpoint atrás de OPENAI_HOST sirva: um id Claude hoje, um id Kimi ou Qwen amanhã, uma variável de distância.

O caminho declarativo: um arquivo de provider personalizado.

Além do override de env, a documentação atual do Goose também descreve providers personalizados declarativos: um arquivo JSON colocado em ~/.config/goose/custom_providers/ (diretório de configuração específico da plataforma no Windows) que registra um provider nomeado ao lado dos nativos. O arquivo declara o engine (openai para endpoints de chat-completions), qual variável de ambiente guarda a chave, a URL do endpoint, e os modelos que o provider oferece. Preste atenção na convenção de URL aqui, porque ela vira de novo: ao contrário de OPENAI_HOST, a base_url do provider personalizado é a URL de requisição completa incluindo o caminho, https://api.apisrouter.com/v1/chat/completions. Cada entrada em models carrega um context_limit para que o Goose saiba a janela que pode empacotar. O arquivo declarativo é o encaixe melhor quando você quer que o gateway apareça como seu próprio provider nomeado na lista de providers do Goose, com sua própria variável de chave, em vez de ocupar o slot openai. O override de env é o encaixe melhor para CI e troca rápida. Os dois terminam no mesmo endpoint; escolha um e evite empilhá-los.

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

Escolhendo um modelo para um agente autônomo.

O fluxo de trabalho prático é manter seu conjunto de tarefas fixo e rotacionar GOOSE_MODEL entre dois ou três candidatos por algumas sessões cada. Como todo candidato roteia pela mesma chave, a visão de uso por chave precifica cada experimento sem nenhuma contabilidade do seu lado.

• O Goose roda trechos sem supervisão: planejar, editar, rodar, ler saída, repetir. A confiabilidade de tool call importa mais que a eloquência bruta, e é por isso que claude-sonnet-4-6 e claude-opus-4-7 são os padrões para os quais as pessoas convergem no loop principal.
• Ids ajustados para código como kimi-k2.7-code valem a pena testar em sessões pesadas de refatoração; por um gateway esse teste é uma mudança de GOOSE_MODEL, não uma migração de provider.
• Sessões longas acumulam contexto. Um modelo com uma janela genuína de 200k, declarada com honestidade via context_limit no caminho declarativo, deixa o Goose carregar mais histórico de sessão antes de sumarizar.
• Para uso em script ou CI, um id de nível intermediário (gpt-5.4, qwen3.7-max) frequentemente supera a barra para tarefas bem delimitadas a uma fração do gasto de ponta; meça nas suas próprias tarefas antes de assumir o padrão mais caro.

Pague pelo uso · abaixo do preço oficial

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

Os modos de falha específicos do Goose.

/v1 anexado ao OPENAI_HOST. A variável de host recebe o host puro; o caminho vive em OPENAI_BASE_PATH, que já usa v1/chat/completions por padrão. https://api.apisrouter.com/v1 como host produz requisições /v1/v1/... e 404s. Esse é o erro mais comum, precisamente porque toda outra ferramenta quer o sufixo /v1. A convenção de URL completa em arquivos de provider personalizado. A base_url declarativa é a URL de requisição completa incluindo /v1/chat/completions, a convenção oposta de OPENAI_HOST. Colar um host puro em um arquivo de provider personalizado quebra tanto quanto colar uma URL completa em OPENAI_HOST. Chaves no config.yaml não autenticam. O Goose lê segredos do keychain ou do ambiente, e ignora valores de chave colocados no config.yaml. Se um 401 persiste depois de editar o arquivo, é por isso; exporte a variável ou rode goose configure de novo e insira a chave quando solicitado. Sessões de desktop não veem exports de shell. O app de desktop não herda nada do perfil do seu terminal. Configure o provider pela UI de configurações do desktop, ou lance de um shell que tenha as variáveis definidas. Fontes de configuração empilhadas. Um OPENAI_HOST antigo exportado pode sobrescrever o que você acabou de definir no config.yaml, porque ambiente vence arquivo. Quando o roteamento parecer errado, imprima as variáveis relevantes no mesmo shell que lança o Goose antes de culpar qualquer uma das camadas.

Quem roteia o Goose por um gateway.

• Engenheiros rodando o Goose como padrão diário que querem Claude, GPT, Kimi e Qwen alcançáveis atrás de uma chave em vez de um conjunto de credenciais por fornecedor.
• Times colocando o Goose em CI ou jobs agendados. O caminho só-de-env significa que o runner precisa de exatamente duas variáveis de roteamento e um segredo, fácil de injetar e fácil de rotacionar.
• Desenvolvedores comparando modelos de agente em tarefas reais. Cada candidato é um valor de GOOSE_MODEL contra o mesmo endpoint, precificado automaticamente pelo uso por chave.
• Times de plataforma que querem o gasto de agente visível por chave e por modelo em uma única superfície de faturamento, em vez de reconciliar vários painéis de fornecedor.
• Desenvolvedores sem acesso ao faturamento de um determinado fornecedor. O acesso baseado em recarga sem exigência de cartão remove a dependência de cadastro por provedor.

Verifique o endpoint e depure a primeira sessão.

Confirme que o gateway serve o id em GOOSE_MODEL antes de começar uma sessão; a listagem /v1/models é a grafia autoritativa, sufixos de versão incluídos. As falhas da primeira sessão são consistentes. Um 404 significa que o host e o caminho se compuseram errado, quase sempre /v1 em OPENAI_HOST. Um 401 significa que a chave não está onde o Goose procura: não exportada no shell que o lançou, não no keychain, ou parada inutilmente dentro do config.yaml. Um erro de modelo não encontrado do gateway é um erro de digitação no id em GOOSE_MODEL. Se a sessão começa mas as tool calls se comportam de forma estranha, verifique se você está em um modelo que genuinamente suporta uso de ferramentas; os ids na tabela acima todos suportam. Assim que o loop roda, o console da APIsRouter mostra modelo, contagens de token e gasto por requisição. Um agente autônomo é a carga de trabalho onde isso mais importa: sessões são longas, turnos de tool call são muitos, e a visão de uso é como você vê quanto uma tarde de Goose realmente custou.

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

Perguntas frequentes