Faites tourner Goose sur un endpoint compatible OpenAI personnalisé.

Réponse rapide : gardez le fournisseur openai, surchargez l'hôte.

Goose fournit un chemin documenté pour endpoint personnalisé : gardez GOOSE_PROVIDER réglé sur openai et surchargez la destination de ce fournisseur. OPENAI_HOST remplace l'hôte par défaut api.openai.com, OPENAI_API_KEY authentifie, et GOOSE_MODEL choisit le modèle par son id exact. Le chemin de requête est séparé : OPENAI_BASE_PATH vaut par défaut v1/chat/completions et n'a normalement besoin d'aucun changement. Notez bien la forme, car c'est l'inverse de la plupart des outils de cette catégorie : OPENAI_HOST prend l'hôte nu, https://api.apisrouter.com, sans suffixe /v1. La partie /v1/chat/completions vit dans OPENAI_BASE_PATH. Ajouter /v1 à l'hôte double le chemin et produit des 404 qui ressemblent à une passerelle cassée.

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

Comment Goose parle à son fournisseur.

Goose (block sur GitHub, environ 51 000 étoiles) est un agent d'ingénierie autonome de Block qui planifie des tâches, édite des fichiers, exécute des commandes shell, et pilote des extensions basées sur MCP. Tout cela repose sur une seule conversation de modèle : chaque étape de la boucle est une requête /v1/chat/completions avec des définitions d'outils jointes, donc la configuration du fournisseur décide où tourne l'agent tout entier. La configuration est en couches. Le chemin interactif est goose configure, qui pour le fournisseur openai demande la clé API et un hôte personnalisé optionnel, puis écrit des réglages non secrets comme GOOSE_PROVIDER et GOOSE_MODEL dans ~/.config/goose/config.yaml ; l'application desktop expose les mêmes réglages de fournisseur via son interface. Les secrets sont traités séparément : les clés vont dans le trousseau système ou proviennent de variables d'environnement, et une clé collée directement dans config.yaml est ignorée plutôt que lue. Les variables d'environnement l'emportent sur le fichier, ce qui fait que le chemin par variables ci-dessus fonctionne partout, d'un shell d'ordinateur portable à un runner CI. Comme Goose transmet GOOSE_MODEL tel quel comme une simple chaîne, l'id peut être n'importe quoi que sert l'endpoint derrière OPENAI_HOST : un id Claude aujourd'hui, un id Kimi ou Qwen demain, à une seule variable près.

Le chemin déclaratif : un fichier de fournisseur personnalisé.

Au-delà de la surcharge par variables, la documentation actuelle de Goose décrit aussi des fournisseurs personnalisés déclaratifs : un fichier JSON déposé dans ~/.config/goose/custom_providers/ (répertoire de config propre à chaque plateforme sous Windows) qui enregistre un fournisseur nommé aux côtés des fournisseurs intégrés. Le fichier déclare le engine (openai pour les endpoints chat-completions), quelle variable d'environnement détient la clé, l'URL de l'endpoint, et les modèles que propose le fournisseur. Faites attention à la convention d'URL ici, car elle bascule à nouveau : contrairement à OPENAI_HOST, le base_url du fournisseur personnalisé est l'URL de requête complète, chemin inclus, https://api.apisrouter.com/v1/chat/completions. Chaque entrée models porte un context_limit pour que Goose sache quelle fenêtre il peut empaqueter. Le fichier déclaratif convient mieux quand vous voulez que la passerelle apparaisse comme son propre fournisseur nommé dans la liste des fournisseurs de Goose, avec sa propre variable de clé, plutôt que d'occuper l'emplacement openai. La surcharge par variables convient mieux pour la CI et les changements rapides. Les deux aboutissent au même endpoint ; choisissez-en un et évitez de les empiler.

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

Choisir un modèle pour un agent autonome.

Le workflow pratique consiste à garder votre jeu de tâches fixe et à faire tourner GOOSE_MODEL sur deux ou trois candidats pendant quelques sessions chacun. Comme chaque candidat route via la même clé, la vue d'usage par clé chiffre chaque expérience sans aucune comptabilité de votre côté.

• Goose fait tourner des séquences sans surveillance : planifier, éditer, exécuter, lire la sortie, répéter. La fiabilité des appels d'outils compte plus que l'éloquence brute, ce qui explique pourquoi claude-sonnet-4-6 et claude-opus-4-7 sont les défauts vers lesquels les gens convergent pour la boucle principale.
• Les id calibrés pour le code comme kimi-k2.7-code valent la peine d'être testés pour les sessions à forte dose de refactorisation ; via une passerelle, ce test n'est qu'un changement de GOOSE_MODEL, pas une migration de fournisseur.
• Les longues sessions accumulent le contexte. Un modèle avec une vraie fenêtre de 200k, déclaré honnêtement via context_limit dans le chemin déclaratif, permet à Goose de porter plus d'historique de session avant de résumer.
• Pour un usage scripté ou en CI, un id de milieu de gamme (gpt-5.4, qwen3.7-max) franchit souvent la barre pour des tâches bien cadrées, à une fraction de la dépense frontier ; mesurez sur vos propres tâches avant de monter en gamme par défaut.

Paiement à l'usage · en dessous du tarif officiel

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

Les modes d'échec spécifiques à Goose.

/v1 ajouté à OPENAI_HOST. La variable host prend l'hôte nu ; le chemin vit dans OPENAI_BASE_PATH, qui vaut déjà par défaut v1/chat/completions. https://api.apisrouter.com/v1 comme hôte produit des requêtes /v1/v1/... et des 404. C'est l'erreur la plus courante, précisément parce que tous les autres outils veulent le suffixe /v1. La convention d'URL complète dans les fichiers de fournisseur personnalisé. Le base_url déclaratif est l'URL de requête complète, /v1/chat/completions inclus, la convention opposée à celle d'OPENAI_HOST. Copier un hôte nu dans un fichier de fournisseur personnalisé le casse aussi sûrement que copier une URL complète dans OPENAI_HOST. Les clés dans config.yaml ne s'authentifient pas. Goose lit les secrets depuis le trousseau ou l'environnement, et ignore les valeurs de clé placées dans config.yaml. Si un 401 persiste après avoir édité le fichier, c'est la raison ; exportez la variable ou relancez goose configure et saisissez la clé quand elle est demandée. Les sessions desktop ne voient pas les exports de shell. L'application desktop n'hérite de rien de votre profil de terminal. Configurez le fournisseur via l'interface des réglages desktop, ou lancez depuis un shell où les variables sont définies. Sources de configuration empilées. Un ancien export OPENAI_HOST peut écraser ce que vous venez de régler dans config.yaml, car l'environnement l'emporte sur le fichier. Quand le routage semble faux, affichez les variables pertinentes dans le même shell qui lance Goose avant d'accuser l'une ou l'autre couche.

Qui route Goose via une passerelle.

• Les ingénieurs qui font tourner Goose au quotidien et veulent Claude, GPT, Kimi et Qwen accessibles derrière une seule clé plutôt qu'un jeu d'identifiants par fournisseur.
• Les équipes qui intègrent Goose dans des jobs CI ou planifiés. Le chemin uniquement par variables signifie que le runner n'a besoin que de deux variables de routage et d'un seul secret, faciles à injecter et à faire tourner.
• Les développeurs qui comparent des modèles d'agent sur de vraies tâches. Chaque candidat n'est qu'une valeur GOOSE_MODEL contre le même endpoint, chiffrée automatiquement par l'usage par clé.
• Les équipes plateforme qui veulent la dépense d'agent visible par clé et par modèle sur une seule surface de facturation, plutôt que de réconcilier plusieurs tableaux de bord fournisseur.
• Les développeurs sans accès à la facturation d'un fournisseur donné. Un accès basé sur la recharge, sans exigence de carte, supprime la dépendance à une inscription par fournisseur.

Vérifiez l'endpoint et déboguez la première session.

Confirmez que la passerelle sert l'id de GOOSE_MODEL avant de démarrer une session ; le listing /v1/models est l'orthographe faisant autorité, suffixes de version inclus. Les échecs de première session sont cohérents. Un 404 signifie que l'hôte et le chemin se sont mal composés, presque toujours /v1 dans OPENAI_HOST. Un 401 signifie que la clé n'est pas là où Goose regarde : pas exportée dans le shell qui l'a lancé, pas dans le trousseau, ou logée inutilement dans config.yaml. Une erreur de modèle introuvable venant de la passerelle est une faute de frappe dans l'id de GOOSE_MODEL. Si la session démarre mais que les appels d'outils se comportent bizarrement, vérifiez que vous êtes sur un modèle qui prend réellement en charge l'usage d'outils ; tous les id du tableau ci-dessus le font. Une fois la boucle en marche, la console APIsRouter affiche le modèle par requête, le nombre de tokens et la dépense. Un agent autonome est la charge de travail où cela compte le plus : les sessions sont longues, les tours d'appels d'outils sont nombreux, et la vue d'usage est ce qui vous permet de voir ce qu'a réellement coûté un après-midi de Goose.

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

Questions fréquentes