Tutoriel de l'agent de programmation goose : installation, sources de modèles, configuration API et coûts

goose est un agent de programmation IA open source (Apache-2.0) capable de lire et modifier des fichiers et d’exécuter des commandes dans un terminal ou une application de bureau. Il suffit de trois étapes pour commencer : l’installer, choisir une source de modèle (provider) et lui attribuer une session de travail avec une tâche. Il est gratuit en lui-même ; les frais proviennent du modèle auquel vous le connectez. Ce guide, fondé sur la documentation officielle du 1er octobre 2026, explique l’installation, les trois options payantes, la connexion à un endpoint compatible avec OpenAI (y compris le piège /v1 le plus fréquent) et les opérations courantes. La dernière version est v1.52.0, publiée le 23 septembre 2026.

Clarifions d’abord les noms. Cette page traite de l’agent de programmation disponible sur goose-docs.ai, dont le dépôt est aaif-goose/goose, anciennement block/goose, transféré en avril 2026 sous l’égide de l’Agentic AI Foundation de la Linux Foundation. Il ne s’agit pas de goose.ai — il s’agit d’un autre service d’inférence hébergé, sans rapport avec ces tarifs. goose ne propose actuellement pas d’interface en chinois traditionnel ; les noms des menus ci-dessous sont donc conservés en anglais.

installation

Les versions de bureau (goose Desktop) et en ligne de commande (goose CLI) sont fournies officiellement et utilisent le même fichier de configuration.

# goose Desktop(macOS)
brew install --cask block-goose

# goose CLI（macOS / Linux / Windows 的 Git Bash）
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

# 只安裝、先不進入設定
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | CONFIGURE=false bash

# 或用 Homebrew 裝 CLI
brew install block-goose-cli

Sous Windows, vous pouvez télécharger la version de bureau depuis le site officiel ; pour le CLI, il est recommandé d’exécuter la même commande d’installation dans Git Bash (PowerShell convient également). Le nom du paquet Homebrew est toujours block-goose ; cela signifie que le changement de nom n’a pas été entièrement répercuté dans le paquet d’installation, et non que le projet est encore détenu par Block.

Premier démarrage : choisir la source du modèle

Au premier lancement de goose Desktop, un écran de bienvenue s’affiche ; le CLI passe automatiquement en mode configuration (pour modifier la configuration par la suite, exécutez goose configure). La page d’installation propose trois options :

• OpenRouter Login — connectez-vous avec un compte OpenRouter pour configurer automatiquement le modèle.
• Tetrate Agent Router Service Login — connectez-vous à Tetrate ; la documentation indique que la première authentification automatique via goose donne droit à un crédit gratuit de $10, pour les nouveaux utilisateurs comme pour les utilisateurs existants.
• Manual Configuration — choisissez vous-même le fournisseur et saisissez la clé. Pour connecter un endpoint compatible avec OpenAI (comme Kunavo), choisissez cette option.

Trois options payantes : choisir la bonne avant de configurer

La description de l’option ACP provient de la documentation des fournisseurs ACP de goose, qui précise également que l’identifiant de session ACP diffère de celui de goose et que les champs de télémétrie peuvent ne pas correspondre. Si vous avez déjà un abonnement et souhaitez uniquement éviter les frais d’API, commencez par cette option.

Connexion à un endpoint compatible avec OpenAI : ne pas ajouter /v1 à l’URL Host

C’est l’endroit où la plupart des utilisateurs rencontrent un problème. goose n’accepte pas une URL de base complète ; il la divise en deux parties : « hôte » et « chemin ». Selon la documentation des fournisseurs, OPENAI_HOST est l’« URL de l’endpoint personnalisé (api.openai.com par défaut) », tandis que OPENAI_BASE_PATH est le « chemin de requête ajouté à l’hôte ( v1/chat/completions par défaut) » ; lors de la connexion à un proxy, OPENAI_HOST doit être défini sur « l’adresse racine du proxy (sans chemin) ». Avec Kunavo, par exemple :

# goose Desktop → Settings → Models → Configure providers → OpenAI
API Key           sk-kn-...
Host URL          https://api.kunavo.com      ← 只寫網域，不加 /v1
Organization ID   （留空）
Project           （留空）

# 或用環境變數（CLI 也讀）
export OPENAI_API_KEY=sk-kn-...
export OPENAI_HOST=https://api.kunavo.com
# OPENAI_BASE_PATH 不要設：預設就是 v1/chat/completions

Dans goose Desktop, l’emplacement est Settings → Models → Configure providers → OpenAI ; dans le CLI, goose configure → Configure Providers → OpenAI. Organization ID et Project servent aux comptes OpenAI eux-mêmes et peuvent rester vides. Si l’URL Host est définie sur https://api.kunavo.com/v1, la requête devient /v1/v1/chat/completions ; la documentation précise elle-même qu’une erreur « 404 signifie généralement que OPENAI_BASE_PATH ne convient pas à votre proxy » — le problème vient du chemin, pas de la clé. À l’inverse, si vous obtenez une erreur 401 « No api key passed in », la clé n’a pas été lue, par exemple parce que vous l’avez inscrite dans config.yaml (goose l’ignore).

Une autre solution, plus propre, consiste à en faire un fournisseur distinct dans la liste. goose lit les fichiers JSON de définition dans le dossier custom_providers ; Kunavo fournit un fichier généré à partir du barème en temps réel, qui ne contient que les modèles prenant en charge les appels d’outils et ne renseigne que le nom de la variable contenant la clé, jamais la clé elle-même :

# macOS / Linux:goose 會讀這個資料夾裡所有 JSON
mkdir -p ~/.config/goose/custom_providers
curl -fsSL https://kunavo.com/goose/kunavo.json \
  -o ~/.config/goose/custom_providers/kunavo.json

# 檔案裡只有變數名稱，金鑰另外設定
export KUNAVO_API_KEY=sk-kn-...
goose session start --provider kunavo

Le dossier Windows est %APPDATA%\Block\goose\config\custom_providers\. Une fois placé, Configure providers de goose Desktop affichera Kunavo ; la clé peut être enregistrée dans le trousseau système plutôt que dans une variable d’environnement. D’après le code source de goose, les modèles dont l’identifiant commence par gpt-5 ou gpt-6 passent par /v1/responses, tandis que les autres passent par /v1/chat/completions ; Kunavo fournit les deux. Vous pouvez aussi le configurer manuellement : Configure providers → Add Custom Provider, sélectionnez le type OpenAI Compatible et renseignez l’URL d’API https://api.kunavo.com/v1. La page de configuration complète en anglais se trouve dans le guide d’intégration de goose.

Transparence : la configuration ci-dessus a été compilée à partir de la documentation et du code source de goose ; Kunavo n’a pas testé ses propres endpoints avec goose — aucune session, aucun flux ni échange avec des outils n’a été exécuté. Conservez le parcours qui fonctionne actuellement pour vous et commencez par lui confier une petite tâche qui lit et écrit des fichiers.

Opérations courantes

• Démarrer une session :goose session (vous pouvez la nommer avec -n 名稱), puis la reprendre avec goose session --resume -n 名稱 ; goose session list affiche l’historique.
• Changer le mode d’autorisation : saisissez /mode dans la session, puis choisissez auto, approve, chat ou smart_approve. Pour qu’il vous demande confirmation à chaque étape, utilisez approve.
• Choisir un modèle :goose configure ne permet pas de saisir un nom de modèle personnalisé ; pour un identifiant absent de la liste, saisissez-le dans goose Desktop ou configurez-le dans config.yaml avec GOOSE_MODEL.
• Fichiers de description du projet : goose lit par défaut .goosehints et AGENTS.md (contrôlé par CONTEXT_FILE_NAMES). Écrivez-y les règles du projet afin de pouvoir les conserver lors du changement d’agent.
• Ne choisissez pas un modèle qui ne prend pas en charge les appels d’outils : la documentation indique que ce type de modèle « peut uniquement effectuer des complétions conversationnelles », et les extensions doivent également être désactivées.

Quel est le coût approximatif d’une session

Voici une arithmétique illustrative des tokens, et non le coût réel d’une tâche ni une limite de facturation. Supposons qu’une session d’agent envoie au total, sur plusieurs tours, 400,000 tokens d’entrée non mis en cache et reçoive 25,000 tokens de sortie (l’agent renvoie le contexte à chaque tour, ce qui augmente fortement le volume d’entrée). Les tarifs proviennent des prix actuels par million de tokens figurant dans la grille tarifaire de Kunavo.

À propos de la mise en cache : la documentation de goose indique que, lors de l’utilisation de Claude via les providers Anthropic, Amazon Bedrock, Databricks, OpenRouter et LiteLLM, goose ajoute automatiquement les marqueurs cache_control d’Anthropic. Claude utilisé via le provider OpenAI générique ne figure pas dans cette liste ; goose n’ajoute donc pas ces marqueurs. Le tableau ci-dessus suppose par conséquent l’absence de remise liée à la mise en cache, ce qui constitue une estimation prudente. Les montants de la grille tarifaire de Kunavo sont des planchers de facturation, et non des plafonds : lorsque l’amont signale un coût, la facture retient le montant le plus élevé entre le « montant de la grille tarifaire » et le « coût amont × majoration applicable ».

Payer depuis Taïwan

Kunavo fonctionne en prépaiement avec un débit par token, sans frais mensuels. La recharge minimale est de $10 ; le paiement passe par Stripe, et Taïwan accepte les cartes de crédit (Visa, Mastercard, American Express, JCB, UnionPay), Apple Pay, Google Pay et Link. JKoPay et LINE Pay ne figurent pas parmi les options disponibles. Consultez les informations de facturation, puis créez un compte et générez une clé. Pour comparer d’autres agents, consultez en anglais goose alternatives et goose vs Claude Code.

Questions fréquentes

Vérifié le 1er octobre 2026 : documentation de goose sur l’installation, les providers, les providers ACP, les commandes CLI et les variables d’environnement (branche main de aaif-goose/goose), ainsi que la version et l’état d’archivage via l’API GitHub. Kunavo n’a pas réellement testé son propre endpoint avec goose ; les prix proviennent de la grille tarifaire actuelle et tous les exemples de montants sont des calculs de tokens à titre illustratif.