Catalogue des fournisseurs

Toutes les familles de fournisseurs de modèles livrées avec ZeroClaw. Pour chacune : la forme de configuration, des notes sur l’authentification et le comportement des points de terminaison, ainsi que la clé d’emplacement à utiliser sous [providers.models.<type>.<alias>].

Consultez Configuration pour les champs universels (api_key, uri, model, …) et l’ordre de résolution.

Les exemples ci-dessous utilisent home comme alias pour souligner que la partie alias est choisie par l’opérateur, choisissez le nom qui convient (work, personal, cn, prod, …). Référencez-le depuis un agent via model_provider = "<type>.<alias>".

Natif

Anthropic / Claude : slot anthropic

Prend en charge les clés API Console et les jetons générés par claude setup-token pour Claude Max. Les deux formes d’identifiants résident dans le champ api_key de l’emplacement canonique anthropic ; Quickstart les expose en tant que choix api_key et setup_token. Le streaming, les appels d’outils, la vision et le raisonnement sont tous pris en charge. Les points de terminaison personnalisés (proxys compatibles Anthropic, p. ex. l’API Anthropic de Z.AI) vont également sur cet emplacement : définissez uri pour remplacer.

OpenAI : emplacement openai

GPT-4o, GPT-5, modèles de raisonnement o-series. Lorsque le raisonnement est diffusé en continu, il est transmis dans le champ facultatif reasoning d’un StreamChunk encapsulé par TextDelta ; voir Streaming.

OpenAI Codex : emplacement openai avec requires_openai_auth = true

L’authentification par abonnement OpenAI Codex réside sur l’emplacement openai. Définissez wire_api = "responses" pour acheminer les requêtes via POST /v1/responses et requires_openai_auth = true pour utiliser la connexion par abonnement Codex (depuis le fichier ~/.codex/auth.json propre à la CLI Codex) au lieu d’un champ api_key sur l’entrée. Le chemin par abonnement ne lit pas OPENAI_API_KEY ; cette variable s’applique uniquement au mode openai facturé à l’usage par clé API. Consultez Provider Configuration → OAuth and subscription auth pour le modèle d’identifiants.

Ollama : emplacement ollama

Inférence locale via l’API native /api/chat d’Ollama. Sortie structurée basée sur un schéma via format. Aucune clé API requise.

Bedrock : emplacement bedrock

Gemini : emplacement gemini

L’API Gemini de Google. Prend en charge la vision et la recherche ancrée pré-exécutée (voir Streaming pour les événements PreExecutedToolCall).

Gemini CLI : emplacement gemini_cli

Lance le CLI gemini ; utilise l’authentification existante du CLI.

Grok Build CLI : emplacement grok_cli

Exécute le Grok Build CLI via la surface ACP documentée grok agent stdio et utilise par défaut le cache de connexion du CLI. Exécutez grok login, ou utilisez le pont explicite par clé API présenté ci-dessous. L’alias typé api_key n’est pas utilisé, et XAI_API_KEY n’est pas hérité de l’environnement, sauf si l’alias l’active explicitement, de sorte que le CLI Grok reste responsable de l’authentification. Il s’agit de l’unique transport : initialize → authenticate → session/new → session/prompt via JSON-RPC délimité par des retours à la ligne. Les prompts courts comme longs sont transmis via stdin et n’apparaissent jamais dans argv ni dans un fichier de prompt.

L’intégration ACP documentée et le profil d’arguments par défaut ont été validés avec Grok Build CLI 0.2.118 (sondes ACP d’annonce/en direct), avec 0.2.111 comme référence antérieure. Considérez les mises à niveau de la CLI externe comme un changement de compatibilité et revalidez grok agent stdio avant de les déployer.

Vision ACP / entrée d’image (comportement actuel de Grok Build)

Grok Build CLI (testé jusqu’à 0.2.118) indique toujours promptCapabilities.image = false dans initialize d’ACP. Il ne s’agit pas d’une surcharge par variable d’environnement de part et d’autre : ZeroClaw ne réécrit jamais l’annonce de Grok. Le seul contrôle de ZeroClaw est le champ de configuration partagé par alias vision.

[providers.models.grok_cli.default]
model = "grok-4.5"
working_directory = "/srv/zeroclaw/grok-workspace"
# Expérience facultative uniquement : envoyer des blocs d’image ACP malgré l’indication image=false.
# Cela ne permet pas à Grok Build 0.2.118 de voir ou de décrire l’image de manière fiable.
# vision = true

Laissez vision non défini pour les alias grok_cli de production. N’acheminez pas vers grok_cli les pièces jointes de canal qui nécessitent une véritable compréhension des images tant qu’un CLI déployé n’annonce pas à la fois image = true et qu’un test de fumée en conditions réelles ne montre pas que le modèle utilise le contenu de l’image. Lorsque ces conditions sont remplies, supprimez toute activation temporaire de vision = true et réévaluez si ZeroClaw doit suivre le bit d’annonce plutôt qu’une surcharge locale (GrokCliModelProvider::acp_prompt_content).

Ubuntu 24.04 : conserver le bac à sable Grok lorsque bwrap a besoin d’espaces de noms utilisateur

Lors du déploiement de Grok Build 0.2.112 ou version ultérieure, vérifiez l’initialisation d’ACP sur l’hôte cible. Sur les hôtes Ubuntu 24.04 avec kernel.apparmor_restrict_unprivileged_userns=1, Grok peut se terminer avant l’initialisation d’ACP avec bwrap: setting up uid map: Permission denied. Il s’agit d’un échec de configuration du bac à sable de l’hôte, et non d’un échec lié à ACP, à stdout ou à l’authentification.

Conservez la valeur par défaut de ZeroClaw --sandbox strict (ou un profil workspace explicite) et accordez uniquement à l’exécutable Grok concerné l’autorisation de créer un espace de noms utilisateur. Il s’agit d’une modification effectuée par l’administrateur de l’hôte ; elle préserve la restriction globale des espaces de noms utilisateur et ne désactive pas le bac à sable de Grok.

readlink -f "$(command -v grok)"

Créez /etc/apparmor.d/grok-build-userns, en remplaçant l’espace réservé par ce chemin absolu :

abi <abi/4.0>,

include <tunables/global>

profile grok-build-userns /absolute/path/to/grok flags=(unconfined) {
  userns,
}

Ensuite, chargez-le et vérifiez que le profil est actif :

sudo apparmor_parser -r /etc/apparmor.d/grok-build-userns
sudo aa-status | grep grok-build-userns

flags=(unconfined) est le mécanisme d’exception AppArmor d’Ubuntu par exécutable : il accorde userns au binaire Grok indiqué, mais ne lui ajoute aucune règle de fichiers AppArmor. Le bac à sable demandé par Grok lui-même reste activé, et la restriction applicable à l’échelle de l’hôte sur les espaces de noms utilisateur reste activée. Utilisez un profil propre à l’organisation, entièrement confiné, si Grok a également besoin de restrictions de fichiers AppArmor. Comme les mises à jour automatiques peuvent modifier le chemin de l’exécutable téléchargé, résolvez le chemin et rechargez ce profil après chaque mise à jour de Grok.

N’utilisez pas --sandbox off simplement pour éviter cette erreur : cela désactive le bac à sable de Grok. Ne désactivez pas kernel.apparmor_restrict_unprivileged_userns à l’échelle du système. xAI documente l’utilisation de Landlock pour le bac à sable Linux standard et documente bubblewrap uniquement pour les profils personnalisés de refus de lecture ; si cela se produit sans liste deny personnalisée et non vide, signalez la version, l’erreur exacte, le profil de bac à sable et les diagnostics non secrets de l’hôte et d’AppArmor à xAI.

max_acp_stdout_bytes limite toute la sortie stdout lue depuis le processus enfant Grok ACP au cours d’une requête, y compris les trames de protocole et les mises à jour des outils natifs. Sa valeur par défaut est de 4 MiB ; configurez-le par alias lorsqu’une charge de travail avec outils évaluée nécessite un budget plafonné plus élevé.

[providers.models.grok_cli.default]
model = "grok-4.5"
working_directory = "/srv/zeroclaw/grok-workspace"
env_passthrough = ["XAI_API_KEY"]
# Facultatif : 4 MiB par défaut ; la plage acceptée est de 1 à 64 MiB.
max_acp_stdout_bytes = 8388608

Exportez XAI_API_KEY dans l’environnement du démon avant de démarrer ZeroClaw. Le client ACP ne sélectionne xai.api_key que lorsque ce nom figure dans env_passthrough et qu’une valeur non vide est présente dans l’environnement du processus au lancement du processus enfant (elle n’est pas capturée dans le handle de fournisseur à longue durée de vie). Sinon, il utilise le cache de connexion de la CLI. L’alias typé api_key reste rejeté : il s’agit intentionnellement d’un pont vers l’environnement du processus, et non d’un second champ de secret Config. Les valeurs ne sont pas écrites dans le TOML du fournisseur ; un futur pont Config typé pourra charger le même nom au moment de la configuration sans modifier l’interface opérateur.

Un working_directory absolu existant est requis. Il est canonisé et utilisé à la fois comme répertoire de travail du processus enfant et comme limite de session ACP ; le fournisseur ne revient donc jamais au répertoire de travail du démon. L’option binary_path facultative sélectionne un binaire qui n’est pas dans le PATH. L’alias timeout_secs limite les lectures et écritures du protocole (600 s par défaut).

L’environnement enfant est vidé avant le lancement. Les variables d’exécution du processus, de paramètres régionaux, de proxy et de CA figurant sur la liste blanche intégrée restent disponibles ; tous les autres noms sont bloqués, sauf si l’alias de ce fournisseur les répertorie dans env_passthrough. Ce champ est destiné au pont d’authentification explicite XAI_API_KEY et aux variables d’environnement requises par les outils Grok explicitement activés, comme les identifiants des CLI cloud. Les valeurs sont lues dans l’environnement du processus ZeroClaw au moment du lancement et ne sont pas stockées dans la configuration du fournisseur. La liste par défaut est vide. Gardez-la restreinte, car chaque secret répertorié est exposé à Grok et à tous les outils activés pour cet alias. Les autres noms XAI_* appartenant au fournisseur ainsi que tous les noms GROK_* sont refusés. La configuration utilisateur et de projet découverte par Grok, ainsi que les extra_args de l’alias, déterminent la politique des outils Grok.

L’argv par défaut ajoute --no-auto-update, --no-plan, --sandbox strict, --permission-mode dontAsk et --tools "". Par défaut, le client ACP refuse les demandes d’autorisation. Lorsque la requête fournit une option reject_once, le client choisit cette option au lieu d’annuler le tour complet de l’agent ; sinon, il annule la requête. L’outil demandé échoue toujours en mode fermé, tandis que Grok peut traiter le refus et produire une réponse finale ou réessayer avec une opération autorisée par sa stratégie.

Un alias explicitement configuré avec --always-approve, --dangerously-skip-permissions, --yolo ou --permission-mode=bypassPermissions modifie la politique de réponse ACP en mode sans interface : le client sélectionne l’option allow_once de la requête. Il ne remplace jamais allow_always et annule l’opération lorsque l’option allow_once demandée est absente. Cette approbation s’applique uniquement à la demande d’autorisation en cours ; les règles d’autorisation de Grok et le bac à sable actif du système d’exploitation peuvent toujours refuser ou restreindre l’opération.

[providers.models.grok_cli.ops]
working_directory = "/path/to/agents/ops/workspace"
extra_args = [
  "--tools=run_terminal_cmd",
  "--permission-mode=bypassPermissions",
]

Considérez ces options de contournement comme une autorisation permettant à Grok d’exécuter chaque outil pris en charge par la requête sur cet alias, sans aller-retour d’approbation humaine. Les autres modes d’autorisation, notamment acceptEdits, n’activent pas l’approbation automatique ACP. Grok évalue les règles de l’interface CLI --allow / --deny et la configuration des autorisations utilisateur/projet détectée avant d’interroger le client ACP. Ces mécanismes constituent une politique opérateur de confiance : une règle allow correspondante peut préautoriser un outil, de sorte que le client ACP ne reçoive jamais de demande d’autorisation, et les serveurs MCP, plugins ou hooks du projet peuvent ajouter des capacités. Utilisez un working_directory dédié et vérifié pour les agents de canal.

Lorsqu’une règle d’autorisation ne préautorise pas l’outil, Grok envoie tout de même session/request_permission et la politique par défaut de ZeroClaw, qui applique un rejet unique, fait échouer l’outil en mode fermé. En pratique, cela est important pour les outils shell/execute dans le cadre du --sandbox strict par défaut : une règle CLI --allow=Bash(...) peut encore escalader vers l’hôte ACP dans la version actuelle de Grok Build. Un alias shell avec outils activés doit donc soit définir une option explicite de contournement (--always-approve / --permission-mode=bypassPermissions), soit associer les règles d’autorisation à un profil de bac à sable que Grok préautorisera sans validation de l’hôte (par exemple --sandbox=workspace). Les autorisations d’outils en lecture seule, telles que --tools=Read,Grep avec une règle --allow correspondante, restent l’option d’activation explicite la plus restrictive.

Les opérateurs peuvent également accorder des outils ou assouplir la politique de bac à sable/d’autorisations avec l’alias extra_args ; ces deux interfaces constituent des activations explicites pour élargir la frontière des sous-processus. Les options transport, prompt, model, session, cwd et update restent sous la responsabilité du fournisseur et sont rejetées dans extra_args. Les arguments positionnels et courts sont également rejetés. Les options connues qui prennent une valeur acceptent soit ["--flag", "value"], soit --flag=value ; les formes d’options inconnues exigent la forme inline afin de ne pas pouvoir consommer la commande ACP finale.

Grok peut émettre une progression sous forme d’un agent_message_chunk avant un plan, un appel d’outil ou une demande d’autorisation. Le fournisseur ignore le segment de message précédent à ces limites ACP et ne renvoie que le dernier segment de réponse ; ainsi, la narration de la planification ou de la collecte via les outils n’est pas transmise comme réponse du canal. –no-plan explicite maintient également l’alias de canal par défaut à usage unique en dehors du mode de planification de Grok ; la configuration des outils/MCP reste une capacité contrôlée par l’opérateur.

Les trames stdout ACP, la sortie stdout agrégée, le texte de l’assistant et le traitement de stderr sont limités pendant l’exécution de l’enfant. Le flux stderr est lu jusqu’à épuisement, mais son contenu n’est jamais stocké, journalisé ni renvoyé. Les erreurs publiques du fournisseur restent stables et ne renvoient pas de texte libre du protocole contrôlé par l’enfant. Après chaque requête à exécution unique (réussite, expiration du délai, annulation ou erreur de protocole), ZeroClaw termine le groupe de processus de l’enfant sous Unix ou le Job Object sous Windows, puis récupère le processus enfant direct. Cela couvre les descendants ordinaires ; un processus qui crée une nouvelle session ou un nouveau groupe de processus peut échapper à l’arrêt du groupe sous Unix. La couverture de Job Object sous Windows est vérifiée par compilation dans CI et n’est pas entièrement exécutée sur chaque hôte Linux de développement.

Modèle recommandé : chatbot du canal par défaut

Utilisez un alias de fournisseur dédié pour l’agent de messagerie (par exemple agents.default). L’alias par défaut n’accorde aucun outil intégré de Grok. Grok charge toujours sa configuration utilisateur et de projet habituelle ; utilisez donc un espace de travail dédié dont les règles d’autorisation, les serveurs MCP, les plugins et les hooks ont été examinés pour le périmètre de confiance du canal. Utilisez un alias et un espace de travail distincts pour un agent de développement et d’exploitation approuvé par un opérateur.

Précontrôle de l’intention de réponse (classifieur) : ZeroClaw effectue une brève classification REPLY / NO_REPLY[*] avant la boucle complète de l’agent. Préférez une API stable de chat-completions pour ce précontrôle (par exemple l’emplacement HTTP/OAuth xai, ou tout autre alias de modèle non-CLI), et gardez grok_cli uniquement pour model_provider (la réponse complète). Les backends d’agents CLI émettent souvent un texte de planification au lieu d’un unique jeton sentinelle ; ce texte peut être envoyé comme message du canal (« reste silencieux » / « aucune réponse Slack »). Un classifier_provider vide réutilise model_provider : cela convient aux modèles API, mais pas aux bots de canal CLI. Les canaux ACP ignorent entièrement le classifieur.

# Réponses complètes : ACP, bac à sable strict, aucun outil intégré, configuration Grok vérifiée
[providers.models.grok_cli.default]
model = "grok-4.5"
binary_path = "/home/you/.grok/bin/grok"
working_directory = "/path/to/agents/default/workspace"

# Vérification préalable REPLY / NO_REPLY - API (format stable). Réutilisez un alias xAI
# HTTP existant si vous en avez déjà un ; ne le faites pas pointer vers grok_cli.
[providers.models.xai.default]
model = "grok-4.5"
# uri / auth comme pour le fournisseur xAI normal (session OAuth ou api_key)

# Agents Ops / de développement : politique explicite et activation volontaire des outils
[providers.models.grok_cli.ops]
model = "grok-4.5"
binary_path = "/home/you/.grok/bin/grok"
working_directory = "/path/to/agents/ops/workspace"
env_passthrough = ["AWS_ACCESS_KEY_ID", "AWS_SECRET_ACCESS_KEY"]
# Outils en lecture seule : les options --allow correspondantes peuvent préautoriser l’accès sans approbation ACP.
extra_args = ["--tools=Read,Grep", "--allow=Read", "--allow=Grep"]

# Alias Ops compatible avec le shell : contournez l’approbation ACP ou associez allow à un
# profil de bac à sable que Grok préautorise (workspace étant le choix courant).
[providers.models.grok_cli.ops_shell]
model = "grok-4.5"
binary_path = "/home/you/.grok/bin/grok"
working_directory = "/path/to/agents/ops/workspace"
extra_args = [
  "--tools=run_terminal_cmd",
  "--allow=Bash(printf *)",
  "--sandbox=workspace",
]

[agents.default]
model_provider = "grok_cli.default"
classifier_provider = "xai.default"
channels = ["slack.default"]   # exemple

[agents.dependabot]
model_provider = "grok_cli.ops"

Conservez les alias destinés aux canaux sur leurs valeurs par défaut et attribuez-leur des espaces de travail dédiés et examinés. Les règles d’autorisation, les serveurs MCP, les plugins et les hooks découverts par Grok, ainsi que les indicateurs d’autorisation/de bac à sable/d’outils dans extra_args, constituent une politique opérateur de confiance et peuvent élargir le périmètre des sous-processus.

Bac à sable du système d’exploitation de Grok CLI (comment l’utiliser depuis ZeroClaw)

Il s’agit du bac à sable des processus de Grok Build (Landlock / Seatbelt / seccomp appliqué au sous-processus grok). Il ne s’agit pas du bac à sable des outils de ZeroClaw sur [risk_profiles.*.sandbox_*] : celui-ci enveloppe les outils de ZeroClaw après les appels d’outils natifs. Si un opérateur active un alias de fournisseur pour les outils de Grok, le --sandbox de Grok constitue le confinement effectif pour cette tâche. Voir également Mise en bac à sable pour le bac à sable du profil de risque de ZeroClaw.

ZeroClaw fournit toujours une option de sandbox explicite. La valeur par défaut est strict. Définissez --sandbox=<profile> dans extra_args de l’alias du fournisseur pour choisir un autre profil ; la configuration Grok ambiante ou GROK_SANDBOX ne peut pas assouplir silencieusement la valeur par défaut propre au fournisseur.

Le projet .grok/config.toml peut contenir MCP / des plug-ins / [permission]. Grok charge ce fichier en tant que politique d’opérateur de confiance ; les règles allow correspondantes peuvent autoriser des outils sans demande d’autorisation ACP. Il ne sélectionne pas à lui seul le profil de sandbox actif. Les noms de profil et les contenus de profils personnalisés peuvent être stockés dans le projet <workspace>/.grok/sandbox.toml ; transmettez --sandbox=<name> via extra_args pour activer ce profil.

Profils intégrés (tirés de la documentation du bac à sable de Grok) :

Le blocage réseau des processus enfants du shell s’applique uniquement sous Linux ; les outils Grok exécutés dans le processus (LLM, recherche web intégrée) ont toujours besoin du réseau. Préférez strict pour les bots de messagerie afin de limiter la surface d’écriture par défaut du système de fichiers à l’espace de travail de l’agent et aux chemins d’exécution de Grok. Les profils intégrés ne constituent pas une barrière permanente pour les informations d’identification : la documentation du sandbox de xAI avertit que les chemins tels que ~/.ssh ne sont pas garantis comme protégés par les profils intégrés et recommande un profil personnalisé avec une liste deny imposée par le noyau pour les secrets. Utilisez read-only uniquement lorsque l’agent doit lire en dehors de l’espace de travail sans écrire dans les fichiers du projet.

Exemple de profil personnalisé (à définir dans l’espace de travail, à sélectionner dans ZeroClaw) :

# <agent-workspace>/.grok/sandbox.toml
[profiles.channel-bot]
extends = "strict"
# Chemins facultatifs à refuser au niveau du noyau (nécessite bubblewrap sous Linux lorsqu’ils ne sont pas vides) :
# deny = ["**/.env", "**/*.pem"]

# ZeroClaw config.toml
[providers.models.grok_cli.default]
working_directory = "/path/to/agents/default/workspace"
extra_args = ["--sandbox=channel-bot"]

Sandbox par agent : utilisez des alias de fournisseur distincts avec des extra_args différents et explicites et des répertoires de travail dédiés. Conservez les alias de canal sur la valeur par défaut stricte/sans outils intégrés, examinez la configuration Grok découverte pour chaque espace de travail et pointez chaque agent vers l’alias model_provider correspondant.

Azure OpenAI : emplacement azure

resource, deployment et api_version se trouvent dans cette configuration typée, ils ne sont pas lus depuis les variables d’environnement.

Copilot : emplacement copilot

Utilise un abonnement GitHub Copilot pour l’inférence de l’agent. L’authentification utilise un jeton OAuth Copilot obtenu auprès de GitHub.

Telnyx : emplacement telnyx

Point de terminaison IA orienté voix. À associer au canal clawdtalk pour des appels SIP en temps réel.

KiloCLI : emplacement kilocli

Inférence locale via KiloCLI.

Kilo AI Gateway : emplacement kilo

[providers.models.kilo.home]
model   = "anthropic/claude-sonnet-4-6"
api_key = "..."
# endpoint = "gateway"  # default → https://api.kilo.ai/api/gateway

API cloud via Kilo AI Gateway. Authentification par jeton Bearer avec plusieurs niveaux de modèles (free, balanced, pro). Le point de terminaison /models est public (PUBLIC_MODEL_LISTING), donc la liste des modèles fonctionne sans identifiant. Comme il est interrogé en direct, c’est la source qui transmet la tarification à l’éditeur de taux de coûts. Le catalogue partagé models.dev (clé kilo) n’est qu’une solution de repli lorsque le point de terminaison en direct est inaccessible, et il n’inclut pas la tarification.

Migration de nommage : kilo désigne désormais ce fournisseur de passerelle. Le fournisseur de sous-processus KiloCLI conserve son emplacement kilocli (synonyme kilo-cli). Si vous aviez précédemment configuré le fournisseur CLI sous le raccourci kilo, passez à kilocli.

ZeroRouter : emplacement zerorouter

[providers.models.zerorouter.gateway]
model   = "anthropic/claude-sonnet-5"
api_key = "..."   # une clé ZeroRouter (préfixée par `zcr_`) ; ou injectez-la depuis l’environnement
# uri = "http://localhost:8080/v1"  # un routeur auto-hébergé ou local ; omettez-la pour la valeur par défaut hébergée

Passerelle LLM compatible avec OpenAI ; authentification par jeton Bearer. ZeroRouter est actuellement en version bêta. Le slot utilise par défaut le déploiement public hébergé à https://zerorouter.ai/v1, ce qui permet la découverte des modèles sans aucune configuration. ZeroRouter peut également être auto-hébergé (AGPL) ; pour accéder à votre propre routeur, localement à http://localhost:8080/v1 ou ailleurs, définissez explicitement uri. Une clé générée sur un routeur ne permet pas de s’authentifier auprès d’un autre ; api_key doit donc provenir du déploiement pointé par uri.

En plus du protocole chat-completions pris en charge par ce slot, ZeroRouter prend également en charge en entrée l’API Responses d’OpenAI (POST /v1/responses), de sorte que les clients utilisant le protocole Responses, tels qu’un Codex CLI model_provider avec wire_api = "responses", peuvent pointer directement vers le même déploiement avec la même clé.

Le point de terminaison /v1/models est public (PUBLIC_MODEL_LISTING) : la liste des modèles ainsi que leurs tarifs de prompt et de complétion sont récupérés en direct auprès du routeur lui-même, sans identifiants ; comme il est interrogé en direct, c’est lui qui fournit les tarifs à l’éditeur des tarifs de coût (cette famille ne dispose d’aucun mécanisme de secours models.dev ou OpenRouter). L’inférence nécessite toutefois une clé : définissez directement api_key ou injectez-la depuis l’environnement, comme pour toute autre clé de fournisseur (voir Configuration pour connaître l’ordre de résolution de api_key).

Pas de connexion intégrée. Ce préréglage configure le fournisseur uniquement via le chemin api_key typé standard ; il n’ajoute ni connexion par flux d’appareil, ni OAuth, ni stockage des identifiants propre au fournisseur. Définissez api_key (ou son injection via une variable d’environnement) pour exécuter l’inférence.

Tous les emplacements

Chaque slot canonique, son point de terminaison par défaut, s’il s’exécute localement et l’ensemble complet de ses champs de configuration, générés à partir du registre des fournisseurs et du schéma de configuration. Cliquez sur un slot pour développer ses champs ; cliquez sur un champ pour voir comment le définir. Les entrées fixes affichent les valeurs par défaut canoniques. operator required signifie que l’alias nécessite des informations de point de terminaison, telles qu’une ressource et un déploiement Azure ou un custom uri. Les points de terminaison dynamic / resolved at runtime peuvent dépendre des identifiants, de la région, de la découverte ou de l’état d’exécution et ne nécessitent pas forcément de uri. Les fournisseurs pilotés par la CLI utilisent leur commande locale.

Champs partagés

Chaque emplacement de fournisseur accepte ces champs. Les options supplémentaires propres à chaque emplacement sont listées par fournisseur ci-dessous.

zeroclaw config set providers.models.openrouter.<alias>.api_key    # entrée masquée, stockée chiffrée

export ZEROCLAW_providers__models__openrouter__<alias>__api_key=

zeroclaw config set providers.models.openrouter.<alias>.chat_template_kwargs <value>

export ZEROCLAW_providers__models__openrouter__<alias>__chat_template_kwargs=

zeroclaw config set providers.models.openrouter.<alias>.context_window <value>

export ZEROCLAW_providers__models__openrouter__<alias>__context_window=

zeroclaw config set providers.models.openrouter.<alias>.extra_headers    # entrée masquée, stockée chiffrée

export ZEROCLAW_providers__models__openrouter__<alias>__extra_headers=

zeroclaw config set providers.models.openrouter.<alias>.fallback <value>

export ZEROCLAW_providers__models__openrouter__<alias>__fallback=

zeroclaw config set providers.models.openrouter.<alias>.fallback_models <value>

export ZEROCLAW_providers__models__openrouter__<alias>__fallback_models=

zeroclaw config set providers.models.openrouter.<alias>.kind <value>

export ZEROCLAW_providers__models__openrouter__<alias>__kind=

zeroclaw config set providers.models.openrouter.<alias>.live_pricing <value>

export ZEROCLAW_providers__models__openrouter__<alias>__live_pricing=

zeroclaw config set providers.models.openrouter.<alias>.max_tokens <value>

export ZEROCLAW_providers__models__openrouter__<alias>__max_tokens=

zeroclaw config set providers.models.openrouter.<alias>.merge_system_into_user <value>

export ZEROCLAW_providers__models__openrouter__<alias>__merge_system_into_user=

zeroclaw config set providers.models.openrouter.<alias>.model <value>

export ZEROCLAW_providers__models__openrouter__<alias>__model=

zeroclaw config set providers.models.openrouter.<alias>.native_tools <value>

export ZEROCLAW_providers__models__openrouter__<alias>__native_tools=

zeroclaw config set providers.models.openrouter.<alias>.pricing <value>

export ZEROCLAW_providers__models__openrouter__<alias>__pricing=

zeroclaw config set providers.models.openrouter.<alias>.provider_extra <value>

export ZEROCLAW_providers__models__openrouter__<alias>__provider_extra=

zeroclaw config set providers.models.openrouter.<alias>.replay_assistant_reasoning <value>

export ZEROCLAW_providers__models__openrouter__<alias>__replay_assistant_reasoning=

zeroclaw config set providers.models.openrouter.<alias>.requires_openai_auth <value>

export ZEROCLAW_providers__models__openrouter__<alias>__requires_openai_auth=

zeroclaw config set providers.models.openrouter.<alias>.temperature <value>

export ZEROCLAW_providers__models__openrouter__<alias>__temperature=

zeroclaw config set providers.models.openrouter.<alias>.think <value>

export ZEROCLAW_providers__models__openrouter__<alias>__think=

zeroclaw config set providers.models.openrouter.<alias>.timeout_secs <value>

export ZEROCLAW_providers__models__openrouter__<alias>__timeout_secs=

zeroclaw config set providers.models.openrouter.<alias>.tls_ca_cert_path <value>

export ZEROCLAW_providers__models__openrouter__<alias>__tls_ca_cert_path=

zeroclaw config set providers.models.openrouter.<alias>.tool_result_image_policy <value>

export ZEROCLAW_providers__models__openrouter__<alias>__tool_result_image_policy=

zeroclaw config set providers.models.openrouter.<alias>.uri <value>

export ZEROCLAW_providers__models__openrouter__<alias>__uri=

zeroclaw config set providers.models.openrouter.<alias>.vision <value>

export ZEROCLAW_providers__models__openrouter__<alias>__vision=

zeroclaw config set providers.models.openrouter.<alias>.wire_api <value>

export ZEROCLAW_providers__models__openrouter__<alias>__wire_api=

Principal

zeroclaw config set providers.models.azure.<alias>.api_version <value>

export ZEROCLAW_providers__models__azure__<alias>__api_version=

zeroclaw config set providers.models.azure.<alias>.deployment <value>

export ZEROCLAW_providers__models__azure__<alias>__deployment=

zeroclaw config set providers.models.azure.<alias>.resource <value>

export ZEROCLAW_providers__models__azure__<alias>__resource=

zeroclaw config set providers.models.ollama.<alias>.num_ctx <value>

export ZEROCLAW_providers__models__ollama__<alias>__num_ctx=

zeroclaw config set providers.models.ollama.<alias>.num_predict <value>

export ZEROCLAW_providers__models__ollama__<alias>__num_predict=

zeroclaw config set providers.models.ollama.<alias>.temperature_override <value>

export ZEROCLAW_providers__models__ollama__<alias>__temperature_override=

zeroclaw config set providers.models.gemini.<alias>.auth_mode <value>

export ZEROCLAW_providers__models__gemini__<alias>__auth_mode=

zeroclaw config set providers.models.gemini.<alias>.oauth_client_id <value>

export ZEROCLAW_providers__models__gemini__<alias>__oauth_client_id=

zeroclaw config set providers.models.gemini.<alias>.oauth_client_secret <value>

export ZEROCLAW_providers__models__gemini__<alias>__oauth_client_secret=

zeroclaw config set providers.models.gemini.<alias>.oauth_project <value>

export ZEROCLAW_providers__models__gemini__<alias>__oauth_project=

Compatible OpenAI

zeroclaw config set providers.models.moonshot.<alias>.endpoint <value>

export ZEROCLAW_providers__models__moonshot__<alias>__endpoint=

zeroclaw config set providers.models.zai.<alias>.endpoint <value>

export ZEROCLAW_providers__models__zai__<alias>__endpoint=

zeroclaw config set providers.models.glm.<alias>.endpoint <value>

export ZEROCLAW_providers__models__glm__<alias>__endpoint=

zeroclaw config set providers.models.minimax.<alias>.auth_mode <value>

export ZEROCLAW_providers__models__minimax__<alias>__auth_mode=

zeroclaw config set providers.models.minimax.<alias>.endpoint <value>

export ZEROCLAW_providers__models__minimax__<alias>__endpoint=

zeroclaw config set providers.models.minimax.<alias>.oauth_client_id <value>

export ZEROCLAW_providers__models__minimax__<alias>__oauth_client_id=

zeroclaw config set providers.models.minimax.<alias>.oauth_refresh_token <value>

export ZEROCLAW_providers__models__minimax__<alias>__oauth_refresh_token=

zeroclaw config set providers.models.bedrock.<alias>.region <value>

export ZEROCLAW_providers__models__bedrock__<alias>__region=

zeroclaw config set providers.models.qwen.<alias>.auth_mode <value>

export ZEROCLAW_providers__models__qwen__<alias>__auth_mode=

zeroclaw config set providers.models.qwen.<alias>.endpoint <value>

export ZEROCLAW_providers__models__qwen__<alias>__endpoint=

zeroclaw config set providers.models.qwen.<alias>.oauth_client_id <value>

export ZEROCLAW_providers__models__qwen__<alias>__oauth_client_id=

zeroclaw config set providers.models.qwen.<alias>.oauth_refresh_token <value>

export ZEROCLAW_providers__models__qwen__<alias>__oauth_refresh_token=

zeroclaw config set providers.models.qwen.<alias>.oauth_resource_url <value>

export ZEROCLAW_providers__models__qwen__<alias>__oauth_resource_url=

zeroclaw config set providers.models.gemini_cli.<alias>.binary_path <value>

export ZEROCLAW_providers__models__gemini_cli__<alias>__binary_path=

zeroclaw config set providers.models.grok_cli.<alias>.binary_path <value>

export ZEROCLAW_providers__models__grok_cli__<alias>__binary_path=

zeroclaw config set providers.models.grok_cli.<alias>.env_passthrough <value>

export ZEROCLAW_providers__models__grok_cli__<alias>__env_passthrough=

zeroclaw config set providers.models.grok_cli.<alias>.extra_args <value>

export ZEROCLAW_providers__models__grok_cli__<alias>__extra_args=

zeroclaw config set providers.models.grok_cli.<alias>.max_acp_stdout_bytes <value>

export ZEROCLAW_providers__models__grok_cli__<alias>__max_acp_stdout_bytes=

zeroclaw config set providers.models.grok_cli.<alias>.working_directory <value>

export ZEROCLAW_providers__models__grok_cli__<alias>__working_directory=

zeroclaw config set providers.models.kilocli.<alias>.binary_path <value>

export ZEROCLAW_providers__models__kilocli__<alias>__binary_path=

zeroclaw config set providers.models.kilo.<alias>.endpoint <value>

export ZEROCLAW_providers__models__kilo__<alias>__endpoint=

Inférence rapide

Plateformes d’hébergement de modèles

IA chinoise

zeroclaw config set providers.models.stepfun.<alias>.endpoint <value>

export ZEROCLAW_providers__models__stepfun__<alias>__endpoint=

Points de terminaison d’IA cloud

Pour un exemple détaillé par famille, consultez Configuration. Si votre fournisseur n’est pas répertorié, utilisez l’emplacement custom (Fournisseurs personnalisés).

Exemples détaillés : Morph, GitHub Models, Upstage, Featherless, Arcee, Lambda AI, Inception

Chacun de ces emplacements est un slot standard compatible OpenAI : définissez model et api_key, laissez uri de côté (le point de terminaison typé le fournit). Aucun d’entre eux ne propose d’index de modèles public, donc le sélecteur de modèles reste vide jusqu’à ce que vous colliez un identifiant. Une fois une clé définie, ZeroClaw liste les modèles depuis le point de terminaison /models en direct du fournisseur. Les identifiants de modèles ci-dessous sont fournis à titre d’exemple ; vérifiez le catalogue actuel dans le tableau de bord du fournisseur.

Morph : slot morph. Modèles d’application rapide de modifications (morph-v3-large, morph-v3-fast ou auto). Clé disponible sur le tableau de bord Morph.

GitHub Models : slot github_models (alias github-models). Modèles OpenAI / Meta / Microsoft accessibles via un seul GitHub Personal Access Token. Créez un PAT avec la permission models (à granularité fine) ; un jeton Copilot n’est pas le même identifiant. Les ID de modèles sont préfixés par l’éditeur (p. ex. openai/gpt-4o).

Upstage : slot upstage. Solar Pro / Solar Mini (par ex. solar-pro2). Clé depuis la console Upstage.

Featherless : slot featherless. Modèles serverless à poids ouverts, désignés par leurs identifiants de dépôt Hugging Face (p. ex. meta-llama/Meta-Llama-3.1-8B-Instruct). Clé disponible sur featherless.ai.

Arcee : slot arcee. Les modèles natifs incluent conductor, maestro, virtuoso-large, coder-large et blitz. Clé disponible sur la plateforme Arcee. L’API de la plateforme Arcee utilise le chemin de base non standard /api/v1 ; le point de terminaison typé en tient déjà compte, donc laissez toujours uri de côté.

Lambda AI : slot lambda_ai (alias lambda-ai). Inférence hébergée de Lambda (par ex. hermes3-405b). Clé disponible sur la page des clés API de Lambda Cloud.

Inception : slot inception. La famille de LLM à diffusion Mercury (mercury-coder et le plus récent mercury-2). Clé disponible sur la plateforme Inception.

Atlas Cloud : slot atlascloud. Point de terminaison compatible avec OpenAI https://api.atlascloud.ai/v1 avec authentification par jeton bearer. Utilisez uniquement le slot canonique atlascloud ; atlas, atlas-cloud et atlas_cloud ne sont pas des alias d’exécution.

[providers.models.atlascloud.home]
model = "..."
api_key = "..."

Les identifiants proviennent uniquement de la configuration (api_key) ou du remplacement --credential à l’exécution ; ces emplacements ne lisent pas de variable d’environnement *_API_KEY propre à chaque fournisseur.

Exemple NEAR AI Cloud :

[providers.models.nearai.tee]
model   = "..."       # choisissez un modelId depuis https://cloud-api.near.ai/v1/model/list
api_key = "..."

Le slot nearai utilise https://cloud-api.near.ai/v1 par défaut et envoie Authorization: Bearer <api_key>. Pour transférer une variable shell NEARAI_API_KEY existante vers la surface d’environnement à miroir de schéma de ZeroClaw, définissez ZEROCLAW_providers__models__nearai__tee__api_key="$NEARAI_API_KEY".

Familles multi-régions

Plusieurs fournisseurs chinois exposent des points de terminaison régionaux distincts avec différents modèles par défaut. Utilisez un seul emplacement canonique et choisissez la région à l’aide du champ typé endpoint sur l’entrée d’alias.

Moonshot : emplacement moonshot

Variantes : cn, intl, code.

Qwen / DashScope : emplacement qwen

Les comptes Qwen adossés à OAuth utilisent le même emplacement avec auth_mode = "o_auth".

GLM : emplacement glm

MiniMax : emplacement minimax

[providers.models.minimax.intl]
model    = "MiniMax-M3"                       # ou MiniMax-M2.7, MiniMax-M2.7-highspeed
api_key  = "..."
endpoint = "intl"                            # variantes : cn, intl

Pour l’API compatible Anthropic de MiniMax, utilisez [providers.models.anthropic.minimax] avec uri = "https://api.minimax.io/anthropic" (Global) ou uri = "https://api.minimaxi.com/anthropic" (Chine) à la place.

Z.AI : emplacement zai

Pour l’API compatible Anthropic de Z.AI, utilisez [providers.models.anthropic.zai] avec uri = "https://api.z.ai/api/anthropic" à la place.

Doubao / Volcengine : emplacement doubao

Les emplacements restants pour la région Chine (yi, hunyuan, qianfan, baichuan) figurent dans le tableau de tous les emplacements ci-dessus ; sélectionnez la région avec le champ endpoint typé sur l’entrée d’alias.

Couches de routage

OpenRouter est traité comme un fournisseur de première classe à part entière, et non comme un méta-routeur. Le runtime ne voit qu’un seul point de terminaison ; OpenRouter gère la répartition entre les fournisseurs derrière ce point de terminaison.

Pour le routage par tâche, exécutez plusieurs agents et laissez les canaux choisir quel agent traite quel trafic, voir Routage. Pour un mécanisme d’indication plus restreint dans la configuration, utilisez [[model_routes]].

Il manque quelque chose ?

• Si le point de terminaison est compatible avec OpenAI, utilisez l’emplacement custom avec uri défini.
• S’il possède son propre slot canonique ci-dessus, utilisez-le, même si vous ne voyez qu’une seule de ses régions, l’énumération endpoint du slot couvre les autres.
• S’il utilise un format de communication non-OpenAI et nécessite sa propre implémentation, consultez Fournisseurs personnalisés.