Skip to Content
aicentos

Goose

Utiliser aicentos dans Goose : déclarer un provider personnalisé compatible OpenAI

Dernière mise à jour:

Goose est l'agent de codage open source de Block. Deux approches permettent de pointer vers un point d'accès compatible OpenAI : réutiliser le provider openai intégré en changeant son host, ou déclarer un provider personnalisé indépendant. La seconde est recommandée : les informations du point d'accès y sont plus centralisées et il est plus facile de conserver plusieurs configurations en parallèle.

Prérequis

Créez d'abord dans la console, page « Clés API », une clé dédiée pour Goose (nommez-la par exemple goose, pour suivre plus facilement sa consommation) :

Configuration à renseigner

ChampValeur
Fichier du provider personnalisé~/.config/goose/custom_providers/aicentos.json
engineopenai
base_urlhttps://aicentos.com/v1/chat/completions
api_key_envAICENTOS_API_KEY
Modèlenom du modèle dans la « place de marché des modèles » de la console

Étapes de configuration

1. Définir la variable d'environnement de la clé API

export AICENTOS_API_KEY="sk-votre-clé-API"

Écrivez-la dans ~/.zshrc ou ~/.bashrc pour un effet permanent. N'écrivez pas la clé dans config.yaml : l'éditeur recommande explicitement une variable d'environnement ou le trousseau système.

2. Déclarer le provider personnalisé

Créez ~/.config/goose/custom_providers/aicentos.json (sous Windows : %APPDATA%\Block\goose\config\custom_providers\) :

{
  "name": "aicentos",
  "engine": "openai",
  "display_name": "aicentos",
  "description": "Modèles exposés par aicentos",
  "api_key_env": "AICENTOS_API_KEY",
  "base_url": "https://aicentos.com/v1/chat/completions",
  "models": [
    {
      "name": "gpt-4o",
      "context_limit": 128000
    }
  ],
  "supports_streaming": true,
  "dynamic_models": true
}

Les champs obligatoires sont name, engine, display_name, base_url et models ; engine prend les valeurs openai / anthropic / ollama.

Les noms de modèles font foi tels qu'affichés dans la « place de marché des modèles » de la console, voir Modèles pris en charge.

3. Définir par défaut dans config.yaml

Éditez ~/.config/goose/config.yaml :

GOOSE_PROVIDER: aicentos
GOOSE_MODEL: gpt-4o

Au démarrage, Goose analyse le répertoire custom_providers/ et enregistre automatiquement les providers ; le basculement reste ensuite possible dans l'interface graphique.

Test

Commencez par une session non interactive :

goose run -t "Réponds en une phrase : combien font 1+1 ?"

Une réponse normale signifie que la connexion fonctionne.

Remarques

  • base_url doit contenir le chemin complet (ici avec /v1/chat/completions), ce qui diffère de l'usage de la plupart des clients. Pour préciser explicitement le chemin, les versions récentes acceptent aussi un champ base_path, prioritaire sur l'analyse de l'URL.
  • Les variables d'environnement priment sur config.yaml. Si OPENAI_HOST est exporté dans le shell, il écrase silencieusement la configuration du fichier ; en cas de doute, commencez par env | grep -i openai.
  • Goose ne démarre correctement que si un provider est sélectionné. Si vous avez écrit la configuration dans config.yaml sans jamais exécuter goose configure, vous risquez un No provider configured — erreur fréquente : les clés de configuration sont au format YAML, pas dans un .env.
  • Avec dynamic_models: true, Goose interroge le /v1/models du point d'accès pour récupérer la liste des modèles ; pour n'exposer que certains modèles, supprimez ce champ ou passez-le à false.
  • Autre approche simplifiée : réutiliser le provider intégré en posant GOOSE_PROVIDER: openai dans config.yaml, puis composer le point d'accès avec OPENAI_HOST et OPENAI_BASE_PATH. Plus rapide à mettre en œuvre, mais davantage couplée aux variables d'environnement et donc plus exposée au problème d'écrasement évoqué plus haut.
  • Ordre de dépannage : le nom du provider correspond-il exactement au nom du fichier JSON → base_url contient-il le chemin complet → les variables d'environnement sont-elles visibles → le solde est-il suffisant ?

Liens utiles