Utiliser Factory Droid avec Claude

Droid de Factory est une CLI agentique de la même famille que Claude Code, qui vous permet d’utiliser vos propres modèles au moyen d’un fichier de configuration. En la connectant à la passerelle AI Prime Tech, les boucles agentiques de Droid s’exécutent sur Claude, aux côtés de tous les autres modèles proposés par la passerelle.

Modifier le fichier de paramètres

Droid lit ~/.factory/settings.json. Ajoutez un tableau customModels dans lequel chaque entrée décrit un modèle que vous souhaitez rendre disponible. Il s’agit du chemin de configuration actuel ; l’ancien fichier config.json est hérité et ne prend pas en charge toutes les fonctionnalités de settings.json.

Un seul fichier couvre l’ensemble de votre configuration Droid : une seule liste customModels définit donc tous les modèles entre lesquels la CLI peut basculer. Conservez-la au niveau de l’utilisateur plutôt que par projet.

Savoir que settings.json est le fichier actuel évite bien des confusions, car d’anciennes notes et discussions font encore référence à config.json et certaines fonctionnalités se comportent différemment selon le fichier. Lorsqu’une fonctionnalité marche dans un fichier mais pas dans l’autre, settings.json est presque toujours celui auquel se fier. Lorsque les conseils se contredisent, privilégier settings.json plutôt que config.json résout la plupart des divergences. Le fichier le plus récent est celui que Factory prend activement en charge, et c’est dans ce fichier que la syntaxe des variables fonctionne réellement.

Décrire le modèle

Chaque entrée customModels comprend un identifiant de modèle, baseUrl, apiKey, provider et maxOutputTokens. Définissez model sur l’identifiant utilisé par la passerelle, tel que claude-sonnet-4-5, et baseUrl sur l’hôte de la passerelle.

Ensemble, ces champs indiquent à Droid exactement comment accéder au modèle. Comme Droid ne présuppose pas un fournisseur unique, vous renseignez explicitement chaque élément, ce qui lui donne la souplesse nécessaire pour se connecter à une passerelle.

Cette configuration explicite permet à une seule installation de Droid de donner accès à plusieurs modèles Claude sur la même passerelle, chacun dans sa propre entrée customModels partageant la même baseUrl et la même clé. La CLI les traite comme des modèles distincts que vous pouvez sélectionner, même s’ils aboutissent tous au même point de terminaison en amont. Ces champs explicites permettent précisément à une installation de donner accès à plusieurs modèles Claude via un seul point de terminaison. Chaque entrée partage la même baseUrl et la même clé tout en conservant son propre identifiant de modèle : la passerelle assure donc le routage et Droid se contente de sélectionner un nom.

Choisir le mode du fournisseur

Le champ provider définit le format des échanges. Utilisez anthropic pour l’interface Messages native de la passerelle, openai pour le format Responses, ou generic-chat-completion-api pour un point de terminaison de chat /v1 au format OpenAI. Pour Claude sur la passerelle, anthropic est le choix naturel.

Faire correspondre provider à l’interface réellement exposée par la passerelle évite les erreurs au premier lancement. Avec provider défini sur anthropic, Droid utilise le format natif proposé par la passerelle pour Claude.

Les trois modes de fournisseur correspondent également aux interfaces qu’une passerelle multimodèle peut exposer. Ainsi, si la même passerelle propose un modèle au format OpenAI, vous l’ajouterez comme une entrée distincte avec generic-chat-completion-api. Veiller à ce que le provider de chaque entrée corresponde à son interface est la règle qui évite les erreurs dans une configuration mixte. Aligner provider sur l’interface de chaque entrée est la règle qui assure le bon fonctionnement d’une configuration de passerelle mixte. Une entrée Claude native et une entrée au format OpenAI peuvent parfaitement coexister.

Configurer la clé API

Renseignez la clé dans apiKey, idéalement sous forme de référence ${VAR}, telle que ${AIPRIME_API_KEY}, afin que le secret reste dans votre environnement plutôt que dans le fichier. Notez que l’expansion de ${VAR} fonctionne dans settings.json, mais pas dans l’ancien fichier config.json.

Le champ apiKey ne doit pas non plus être vide, même pour une passerelle qui accepterait techniquement une requête anonyme. Droid vérifie que le champ contient une valeur : fournissez donc toujours la clé ou la variable qui la contient.

Ces deux points expliquent une erreur courante : des utilisateurs placent ${VAR} dans l’ancien fichier config.json, où cette référence n’est pas développée, et Droid reçoit une chaîne littérale non résolue. Utilisez settings.json pour les références à des variables, et assurez-vous que la variable est effectivement exportée dans le shell qui lance Droid. Vérifier que la variable est exportée dans le shell de lancement est la dernière étape que les utilisateurs ont tendance à oublier. Droid ne voit que les variables présentes dans l’environnement qui l’a lancé.

Changer de modèle et lancer l’exécution

Dans la CLI Droid, passez d’un modèle configuré à un autre avec la commande /model. Ajoutez une autre entrée pour claude-opus-4-8 et vous pourrez l’utiliser pour les tâches plus difficiles sans modifier de nouveau la configuration.

Droid exécute alors sa boucle agentique avec Claude sur la passerelle. Comme la configuration se trouve dans settings.json, elle s’applique à chaque lancement de la CLI.

Disposer d’une entrée Sonnet et d’une entrée Opus vous permet d’adapter le modèle à la tâche à la volée : Sonnet pour une implémentation régulière, Opus lorsqu’un problème exige un raisonnement plus poussé, le tout via la passerelle sans reconfiguration. La commande /model permet d’effectuer ce changement en une ligne en cours de session. Un changement avec /model en une ligne pendant la session rend l’adaptation du modèle à la tâche très simple. Vous passez de Sonnet à Opus sans quitter la session.

// ~/.factory/settings.json
{
  "customModels": [
    {
      "model": "claude-sonnet-4-5",
      "baseUrl": "https://aiprimetech.io",
      "apiKey": "${AIPRIME_API_KEY}",
      "provider": "anthropic",
      "maxOutputTokens": 8192
    }
  ]
}
// export AIPRIME_API_KEY=<key>   (apiKey must NOT be empty)
// Switch models in the CLI with /model

Questions fréquentes

AI Prime Tech est une passerelle API indépendante. Elle n’est ni affiliée à Anthropic, ni approuvée par Anthropic, ni revendeuse d’Anthropic. Claude et les noms de modèles associés sont des marques de leurs propriétaires respectifs.