OpenBot ne se connecte pas à APIYI ? 3 variables d’environnement et votre collègue IA allume lui-même l’ordinateur

Note de l’auteur : OpenBot ne propose pas d’interface pour « choisir un modèle ». Le modèle est configuré dans .env et dans le fichier model.yaml du package du locataire. Cet article explique comment connecter APIYI en modifiant trois variables d’environnement et une ligne YAML, puis comment n’autoriser que 3 outils informatiques avant de valider l’installation en une seule séquence : « ouvrir une page web + lire un fichier + consulter l’audit ».

Vous avez cloné OpenBot de CopilotKit, ouvert .env.example et parcouru l’interface dans tous les sens, sans jamais trouver de menu pour « choisir un fournisseur de modèle ». Vous n’avez pas de carte acceptée par OpenAI et vous voulez simplement utiliser APIYI avec une facturation à l’usage pour accéder à claude-opus-5-5. Mais impossible de savoir où configurer le modèle.

La réponse est simple : OpenBot n’a pas de bouton pour « choisir un modèle ». Le modèle est configuré dans .env et dans le fichier model.yaml du package du locataire. Pour connecter APIYI, inutile de modifier le code : trois variables d’environnement et une ligne YAML suffisent. Commencez ensuite par n’autoriser que 3 outils informatiques, puis élargissez l’accès selon vos besoins une fois les tests réussis.

Ce n’est pas un tutoriel « prêt en un clic ». OpenBot est un modèle de projet qui nécessite Docker, Bun 1.4+, un projet CopilotKit Intelligence et une clé pour accéder au modèle. Tous ces prérequis sont expliqués dans l’article. Il existe aussi deux projets GitHub nommés OpenBot : nous parlons ici de celui de CopilotKit.

Ce que vous allez apprendre : à la fin de cet article, vous saurez modifier les trois éléments de configuration, démarrer avec 3 outils et effectuer une validation concrète : « ouvrir une page web + lire un fichier + consulter l’audit ». Un tableau de dépannage vous aidera aussi à résoudre les problèmes courants : erreurs 400 ou 401, modèle introuvable, outil non appelé ou démarrage refusé.

Le modèle d’OpenBot ne se configure pas dans l’interface

OpenBot est un modèle de projet, pas un produit

CopilotKit/OpenBot est un dépôt open source sous licence MIT, créé le 17 août 2026. Au 2 novembre 2026, il compte 9 561 étoiles et sa dernière version officielle est la v0.2.0, publiée le 12 octobre 2026. Le haut du README porte toujours la mention Beta. Son objectif : donner à chaque collègue IA, appelé Bot dans le dépôt, son propre ordinateur, avec un vrai navigateur, sa propre session de connexion, ses fichiers et les quelques outils qui lui sont accordés.

Le README le dit clairement : c’est « un modèle de projet, pas un produit ». Il n’existe pas de version hébergée à laquelle s’inscrire, et il n’est pas distribué comme paquet de dépendance. Pour l’utiliser, il faut cloner le dépôt, remplacer les exemples de locataires dans examples/ par vos propres collègues, canaux et compétences, puis l’exécuter vous-même. La réponse à la question « où choisir le modèle ? » se trouve donc dans les fichiers de configuration, pas dans l’interface.

Les quatre prérequis pour lancer OpenBot

Le tableau ci-dessous présente ce qu’il faut préparer avant de connecter un modèle. S’il manque un seul élément, impossible de vérifier la configuration qui suit.

Prérequis	Exigences	Remarques
Docker	Exécuter PostgreSQL avec pgvector et le Bot intégré	`scripts/start.sh` lance les services Docker et exécute les migrations
Bun	Version 1.4 ou ultérieure	Installer les dépendances avec `bun install`
CopilotKit Intelligence	Un projet et une licence ; une offre gratuite est disponible	L’environnement d’évaluation local utilise macOS et Docker Desktop. La licence locale est valable 30 jours et peut être renouvelée avec `npx copilotkit@latest local renew`
Clé du modèle	Une clé pour un point d’accès compatible OpenAI	Cet article utilise un jeton APIYI, avec `https://api.apiyi.com/v1` comme base_url

Intelligence est le prérequis qu’on risque le plus de sous-estimer. Les commentaires de .env.example précisent que si l’URL d’Intelligence, l’URL de la passerelle ou la clé manque, le serveur refuse de démarrer : « Il n’y a pas de mode dégradé. » Intelligence gère en effet les fils de discussion persistants et la mémoire ; sans lui, le contexte serait perdu à chaque conversation. OpenBot ne peut donc pas être présenté comme une solution « entièrement hors ligne ».

OPENAI_BASE_URL s’applique à tout le déploiement

Le README précise qu’« aucun modèle n’est inclus » : les modèles ne sont pas livrés avec le projet. Les identifiants sont fournis par l’administrateur, chiffrés avant leur stockage en base et exclus des journaux. Le choix du modèle dépend de variables d’environnement définies à l’échelle du déploiement. La plus importante est OPENAI_BASE_URL : selon la documentation officielle, elle peut désigner n’importe quel point d’accès utilisant la même API, qu’il s’agisse d’une passerelle multifournisseur, d’un proxy ou d’un modèle exécuté sur votre propre matériel. Les commentaires de .env.example sont plus précis : tout point d’accès prenant en charge /v1/chat/completions convient.

Cette variable s’applique à l’ensemble du déploiement, et non à un seul Bot. Elle est lue à trois endroits : par le client que le serveur API utilise pour l’agent intégré, par agent-bot qui construit son propre client, et par agent-langgraph lorsque BOT_PROVIDER=openai. Selon la documentation officielle, cela évite qu’une moitié des requêtes pointe vers la nouvelle adresse tandis que l’autre utilise encore l’ancienne.

Connecter OpenBot à APIYI : configuration des variables d’environnement

Les points de connexion entre OpenBot et APIYI

APIYI propose une interface compatible avec OpenAI. Il suffit de définir base_url sur https://api.apiyi.com/v1 : les requêtes passent par /v1/chat/completions, ce qui répond aux exigences d’OpenBot pour OPENAI_BASE_URL. Autre point important : OpenBot transmet le nom du modèle tel quel. Comme /v1/models renvoie le nom sans préfixe claude-opus-5-5 chez APIYI, n’ajoutez pas le préfixe openai/ utilisé dans l’exemple de la passerelle officielle. L’exemple officiel openai/gpt-5.6-terra ne s’applique qu’aux points de terminaison qui utilisent un espace de noms dans le nom du modèle.

Voici d’abord un tableau récapitulatif, suivi des étapes de configuration.

Où modifier	Valeur à utiliser	Pourquoi
`OPENAI_API_KEY` dans `.env`	Le jeton `sk-...` créé dans la console APIYI	L’agent intégré et les deux bots fournis utilisent cette clé par défaut
`OPENAI_BASE_URL` dans `.env`	`https://api.apiyi.com/v1`	Dirige les requêtes de modèle de tout le déploiement vers le point de terminaison compatible d’APIYI
`BOT_MODEL` dans `.env`	`claude-opus-5-5`	Définit le modèle utilisé par le bot au démarrage ; si la valeur est absente, celle du fichier de spécification du fournisseur est utilisée
`default_model` dans `examples/<你的包>/model.yaml`	`claude-opus-5-5`	Le paquet d’exemple utilise actuellement `gpt-5.6-terra` ; sans modification, une erreur de modèle introuvable se produit
`BOT_RESPONSES_API` dans `.env`	Conserver `false`	Claude renvoie une erreur 400 sur le point de terminaison Responses d’APIYI

Première étape : créer un jeton dédié

Sur la page des jetons APIYI, api.apiyi.com/token, créez une clé, définissez un plafond de crédit et une date d’expiration, puis indiquez « Évaluation locale d’OpenBot » comme usage.
Depuis votre machine, envoyez une requête curl à GET https://api.apiyi.com/v1/models, avec l’en-tête Authorization: Bearer sk-....

Critère de validation : la requête renvoie HTTP 200 et la liste contient claude-opus-5-5. Lors de notre test du 2 novembre 2026, nous avons obtenu 259 modèles, dont claude-opus-5-5 et claude-opus-5-5-thinking.

Un jeton dédié permet de séparer l’usage de cette machine de la production. Pendant la phase de configuration, le bot procédera à de nombreux essais : un plafond de crédit offre une sécurité appréciable.

Deuxième étape : modifier trois lignes dans .env

Comme indiqué dans le guide de démarrage rapide officiel, exécutez d’abord cp .env.example .env et bun install. Lancez ensuite, dans l’ordre, npx --yes copilotkit@latest login, npx --yes copilotkit@latest project select et bun scripts/setup-learning.ts pour enregistrer la clé runtime et le conteneur Learning dans .env. Modifiez ensuite ces trois lignes :

OPENAI_API_KEY=sk-votre-jeton-APIYI
OPENAI_BASE_URL=https://api.apiyi.com/v1
BOT_MODEL=claude-opus-5-5

Vérifiez aussi quatre points : BOT_PROVIDER conserve sa valeur par défaut, openai ; BOT_RESPONSES_API reste à false ; KEY_ENCRYPTION_KEY est générée avec openssl rand -base64 32 ; AGENT_BOT_MODEL est utilisé uniquement par agent-bot, destiné à une preuve de concept. Sa valeur par défaut est gpt-5.5 et elle est indépendante de BOT_MODEL. Si vous souhaitez aussi lancer agent-bot, vérifiez que ce nom figure dans /v1/models, ou remplacez-le par le modèle de votre choix.

Critère de validation : la commande grep OPENAI_ .env affiche la bonne clé et la bonne adresse. Celle-ci se termine par /v1, sans barre oblique ni espace supplémentaire. Si l’accès au même point de terminaison depuis le conteneur nécessite un routage différent, utilisez OPENAI_CONTAINER_BASE_URL pour remplacer l’adresse. Mais comme APIYI est accessible publiquement, cette variable n’est généralement pas nécessaire.

Troisième étape : modifier une ligne de model.yaml dans le paquet du locataire

Ouvrez examples/fintech/model.yaml ou la copie que vous avez créée du paquet du locataire. Les valeurs actuelles sont model.provider: openai, model.credential_secret_ref: openai-api-key et model.default_model: gpt-5.6-terra.

Remplacez la valeur de default_model par claude-opus-5-5.
Gardez openai pour provider. Selon la documentation officielle, seules les valeurs openai et anthropic sont acceptées ici. Pour utiliser le point d’accès compatible OpenAI d’APIYI, choisissez openai.
Ne remplacez pas credential_secret_ref par une clé en clair : ce champ fait référence à des identifiants déjà enregistrés.

Critère de validation : après avoir exécuté bash scripts/start.sh, tous les contrôles de santé passent et les deux collègues par défaut, General Assistant et Knowledge, apparaissent sur http://localhost:3010.

Attention à un piège. Au démarrage, le serveur vérifie normalement auprès d’OpenAI ou d’Anthropic si la clé peut accéder à default_model. Si ce n’est pas le cas, il affiche model-unavailable ou model-credential-rejected. Mais dès que OPENAI_BASE_URL est défini, cette vérification est ignorée. Avec APIYI, une erreur dans le nom du modèle ne sera donc pas signalée au démarrage : elle n’apparaîtra qu’à l’envoi du premier message. Un démarrage réussi indique seulement que le service est lancé, pas que le modèle est correctement configuré.

Versions : différences entre v0.2.0 et la branche main

Ce point mérite d’être clair. Dans la section Unreleased du CHANGELOG de la branche main, une modification concerne les modèles openai/... du Bot intégré : si OPENAI_BASE_URL pointe vers un service qui n’est « ni OpenAI ni Azure », le Bot appelle désormais /chat/completions sur ce service, plutôt que l’API Responses. Selon l’équipe officielle, la plupart des points de terminaison compatibles OpenAI ne proposent que Chat Completions. Cette modification ajoute aussi COPILOTKIT_OPENAI_API=responses|chat, qui permet d’imposer l’une ou l’autre API.

Cette modification n’est pas encore incluse dans le tag officiel v0.2.0. Si vous utilisez v0.2.0, le Bot intégré peut encore appeler Responses lorsque son URL de base pointe vers un service tiers. Au vu des tests ci-dessous, c’est probablement la source de l’erreur 400. Deux options s’offrent à vous : évaluer la branche main, en gardant à l’esprit qu’elle évolue encore, ou attendre que cette modification soit intégrée à une version officielle avant de procéder à l’intégration.

🚀 Pour commencer rapidement : avant de toucher à OpenBot, nous vous conseillons de tester séparément /v1/chat/completions avec un jeton APIYI apiyi.com. Incluez une définition de fonction et vérifiez que finish_reason renvoie tool_calls. Une fois l’interface validée, vous pourrez concentrer le diagnostic sur la configuration d’OpenBot.

Autoriser seulement 3 outils au départ : limiter les permissions d’OpenBot

Pourquoi ne pas activer tous les outils d’OpenBot dès le début ?

La documentation officielle résume ainsi le problème : « Un modèle choisit le bon outil de manière fiable parmi une dizaine d’outils, mais plus parmi une trentaine. » Le code source d’OpenBot enregistre treize outils de type computer. Si l’on y ajoute les outils du catalogue MCP, cette limite peut vite être dépassée dès le premier jour.

Lorsqu’un Bot dispose de plus de douze outils, chaque exécution ne reçoit que les outils nécessaires au skill correspondant au message en cours. Mais la documentation officielle précise que cela limite seulement les outils visibles : « Ce n’est pas une barrière de sécurité et cela ne remplace jamais une telle barrière. » Les véritables barrières sont au nombre de trois : les autorisations (grants) accordées à chaque Bot dans Admin, la politique d’action AGENT_COMPUTER_POLICY et les entrées d’audit. Attention : la configuration de démarrage par défaut est deny: [] avec allow: ["true"], ce qui revient à tout autoriser.

Les 3 outils à autoriser au départ

Nom de l’outil	Fonction	Au départ
`computer_navigate`	Ouvrir une URL dans le navigateur	✅ Autorisé
`computer_snapshot`	Obtenir un instantané de la page	✅ Autorisé
`computer_read_file`	Lire un fichier de l’espace de travail	✅ Autorisé
`computer_click` / `computer_type` / `computer_key`	Cliquer, saisir du texte, appuyer sur une touche	⏸ À autoriser au besoin après validation
`computer_write_file`	Écrire un fichier	⏸ À autoriser au besoin après validation
`computer_run_command`	Exécuter une commande shell	⛔ Explicitement refusé

Il faut bloquer computer_run_command séparément. Avec Compose, si COMPUTER_SEPARATE_WORKSPACES est activé, chaque Bot lance son shell dans son propre dossier, mais la documentation officielle reconnaît que « les commandes peuvent toujours lire les autres dossiers ». Pour obtenir une véritable isolation, il faut utiliser computers.mode: sandbox. Au départ, inutile de prendre ce risque.

Définir AGENT_COMPUTER_POLICY

La politique est un objet JSON dont les règles utilisent des expressions CEL. Celles-ci peuvent lire des champs comme tool.name, page.host et file.path. Pour commencer, voici une configuration possible :

Ajoutez cette ligne dans .env : AGENT_COMPUTER_POLICY={"mode":"enforce","deny":["tool.name == 'computer_run_command'"],"allow":["tool.name in ['computer_navigate','computer_snapshot','computer_read_file']"]}
Dans Admin, accordez ces trois outils à General Assistant, sans en ajouter d’autres.
Redémarrez le service. Si le JSON est mal formé, le serveur ne démarre pas, ce qui permet de repérer le problème immédiatement.

Deux règles d’évaluation sont à connaître. D’abord, deny est évalué avant allow : même si vous élargissez allow plus tard, le shell reste bloqué. Ensuite, le moteur applique une logique de refus par défaut : si la politique est absente ou vide, rien n’est autorisé ; une règle deny incorrecte entraîne un refus ; une règle allow incorrecte n’accorde aucune autorisation. Le principe tient en une phrase : commencez avec des permissions restreintes, puis élargissez-les au besoin. Après validation, ajoutez les fonctions de clic, de saisie ou d’écriture de fichiers une par une, en consultant l’audit après chaque ajout.

Validation et dépannage de la connexion d’OpenBot à APIYI

Un test de validation : ouvrir une page Web, lire un fichier et consulter l’audit

Selon l’architecture officielle, un appel d’outil suit cet ordre : analyse de la cible, évaluation selon la politique en vigueur, écriture d’une ligne d’audit, puis exécution de l’action sur l’ordinateur. Si l’action transmise échoue, une deuxième ligne d’audit est ajoutée. L’ordinateur lui-même ne prend aucune décision concernant la politique : cette vérification relève de la gateway du serveur. La validation doit donc couvrir deux aspects : « l’action peut être exécutée » et « elle est enregistrée ».

Placez un fichier notes.md dans /workspace et écrivez-y quelques lignes.
Demandez à General Assistant d’ouvrir une page Web publique, de vous donner son titre, puis de lire le contenu de /workspace/notes.md.
Demandez-lui ensuite d’exécuter ls /. Cette action doit être refusée, et la réponse doit indiquer quelle règle l’a bloquée.
Ouvrez la page Audit : vous devez y voir les enregistrements d’autorisation pour navigate, snapshot et read_file, ainsi que le refus de run_command. Pour les exporter, vous pouvez appeler GET /api/admin/audit-events?format=csv : chaque export est limité à 5 000 lignes.

Côté modèle, nous avons testé la disponibilité uniquement sur APIYI. Le 2 novembre 2026, nous avons appelé /v1/chat/completions avec claude-opus-5-5 et une définition de fonction read_file. L’appel a renvoyé un code HTTP 200 en 4,06 secondes, avec finish_reason égal à tool_calls et les paramètres {"path":"/workspace/notes.md"}. La consommation était de 393 tokens pour le prompt et de 55 tokens pour la complétion. Avec stream: true, l’appel a également renvoyé un code 200 : les fragments SSE contenaient le nom de la fonction et les paramètres transmis progressivement, avant de se terminer par data: [DONE]. Cela montre que le point d’accès chat d’APIYI peut renvoyer les appels d’outils de Claude au format OpenAI. C’est précisément ce dont a besoin un agent dont le modèle choisit la fonction à appeler, sans se charger de l’exécuter.

Tableau de dépannage : cinq échecs fréquents

Symptôme	Cause la plus probable	Solution
400 `field messages is required`	La requête a été envoyée au point de terminaison Responses. Lors de nos tests, `claude-opus-5-5` renvoie cette erreur via `/v1/responses` d’APIYI	Vérifiez que `BOT_RESPONSES_API=false`. Avec la version v0.2.0, le bot intégré peut encore utiliser Responses : passez à la branche main et définissez `COPILOTKIT_OPENAI_API=chat` (fonctionnalité encore non publiée)
401	La clé est incorrecte ou expirée, ou le plafond de crédit du jeton est atteint	Vérifiez la date d’expiration et le solde sur la page des jetons APIYI, puis testez à nouveau `/v1/models` avec curl
Modèle introuvable	`default_model` vaut encore `gpt-5.6-terra`, ou le nom est précédé de `openai/`	Indiquez le nom seul, `claude-opus-5-5`, aux deux endroits. Comme la vérification au démarrage est ignorée, vous devez envoyer un message pour valider la configuration
L’outil n’est pas appelé	Le modèle ne prend pas en charge l’appel d’outils, l’autorisation nécessaire n’a pas été accordée, ou une règle bloque l’outil	Selon la documentation officielle, un bot qui ne peut pas appeler d’outils ne peut pas piloter l’ordinateur. Vérifiez d’abord si le journal d’audit contient des refus
Démarrage refusé	La configuration Intelligence est incomplète, le JSON de la politique est incorrect, ou un fournisseur a été ajouté dans la spécification des fournisseurs sans mettre à jour `PROVIDER_IDS`	Renseignez les trois paramètres Intelligence et validez le JSON. Pour connecter APIYI, inutile d’ajouter un fournisseur : conservez `openai`

💡 Conseil de dépannage : en cas d’erreur, commencez par envoyer la même requête directement à /v1/chat/completions d’APIYI, sur apiyi.com. Si l’appel direct fonctionne mais échoue dans OpenBot, le problème vient de la configuration ou de la version d’OpenBot. Si l’appel direct échoue aussi, vérifiez le jeton et le modèle. Vous pourrez ainsi délimiter rapidement la source du problème.

Coût d’utilisation de Claude avec OpenBot

APIYI propose une facturation à l’usage, sans frais mensuels fixes. Voici les tarifs de claude-opus-5-5 relevés le 2 novembre 2026 ; claude-opus-5-5-thinking est facturé au même prix :

Poste de facturation	Prix unitaire (par million de tokens)
Entrée	$4
Sortie	$20
Lecture du cache	$0.2

Consultez la liste des modèles de la plateforme pour connaître les modèles et tarifs en vigueur. Dans notre requête de test avec outils, les 393 tokens d’entrée et les 55 tokens de sortie ont entraîné un coût très faible. Mais dès que le bot enchaîne plusieurs tours de navigation et de lecture de fichiers, le contexte grossit vite. Nous recommandons donc de définir aussi un plafond de dépenses pour le jeton.

Questions fréquentes

Q1 : faut-il modifier le code source pour connecter OpenBot à APIYI ?

Non. Il suffit de modifier les trois lignes `OPENAI_API_KEY`, `OPENAI_BASE_URL` et `BOT_MODEL` dans `.env`, puis de changer `default_model` dans le fichier `model.yaml` du package du tenant. La modification de la spécification du fournisseur et de `PROVIDER_IDS` n’est nécessaire que pour ajouter un tout nouveau type de fournisseur. APIYI utilise une interface compatible OpenAI, ce qui n’est donc pas le cas ici.

Q2 : pourquoi ne pas utiliser un nom avec préfixe comme openai/claude-opus-5-5 ?

OpenBot transmet le nom du modèle tel quel : il faut donc utiliser celui publié par le point de terminaison. Dans la liste `/v1/models` d’APIYI apiyi.com, le nom est simplement `claude-opus-5-5`. Avec un préfixe, le modèle ne sera pas trouvé.

Q3 : peut-on activer BOT_RESPONSES_API pour utiliser la Responses API ?

Ne l’activez pas avec Claude. Lors de notre test, un appel de `claude-opus-5-5` au point de terminaison `/v1/responses` d’APIYI a renvoyé une erreur 400 `field messages is required`, tandis qu’un appel avec `gpt-5.4-mini` a renvoyé un code 200. La documentation officielle précise aussi que cette option ne doit être activée que si le point de terminaison implémente réellement la Responses API.

Q4 : avez-vous fait fonctionner OpenBot dans son ensemble ?

Non. Nous avons uniquement vérifié la partie APIYI : la liste des modèles, un appel chat avec outils, la sortie en streaming et l’erreur du point de terminaison Responses. Nous n’avons pas exécuté l’ensemble d’OpenBot (Docker et le projet Intelligence) sur la machine utilisée pour rédiger l’article. Les passages sur le fonctionnement interne d’OpenBot s’appuient sur le dépôt et la documentation officiels.

Q5 : comment éviter que le bot dépasse le budget d’une clé facturée à l’usage ?

Sur la page des jetons d’APIYI apiyi.com, définissez un plafond de dépenses et une date d’expiration pour cette clé, et gérez-la séparément des clés de production. En combinant ces limites avec la stratégie à trois outils présentée dans cet article, vous limitez à la fois les actions du bot et ses dépenses.

Conclusion

Connecter OpenBot à APIYI : les points clés

Le modèle ne se configure pas dans l’interface : il faut modifier trois lignes dans .env et une ligne dans le fichier model.yaml du package tenant.
base_url s’applique à tout le déploiement : modifier OPENAI_BASE_URL fait basculer les trois types de bots en même temps.
Un démarrage réussi ne garantit pas que le modèle est correct : après connexion à la passerelle, les vérifications sont ignorées. Il faut envoyer un premier message pour valider la configuration.
Vérifiez la version : le passage à /chat/completions figure encore dans la section Unreleased de la branche main et n’est pas inclus dans la v0.2.0.
Commencez avec seulement 3 outils : deny prend le pas sur allow, et le shell doit être refusé séparément. Limitez d’abord les accès, puis élargissez-les progressivement.
Démarrez à l’usage avec APIYI : utilisez un jeton dédié avec un plafond de solde, et indiquez claude-opus-5-5 sans préfixe.

Si la configuration du modèle est difficile à trouver dans OpenBot, c’est parce qu’elle ne se trouve pas dans l’interface. Modifiez trois lignes dans .env et une dans model.yaml, laissez Responses désactivé, puis commencez avec une politique qui n’autorise que 3 outils. La chaîne de configuration devient alors plus facile à comprendre. Pour valider le tout, vérifiez trois choses : la page web s’ouvre, les fichiers peuvent être lus et les actions refusées apparaissent dans les journaux d’audit.

Nous recommandons de commencer par tester séparément le chat et l’appel d’outils avec un jeton dédié APIYI sur apiyi.com, avant de les connecter à OpenBot. En cas de problème, vous pourrez ainsi rapidement déterminer de quel côté il se situe.

📚 Références

Dépôt CopilotKit/OpenBot : README, Requirements et Quick start
Lien : github.com/CopilotKit/OpenBot
Contenu : positionnement du modèle, prérequis et informations sur la version v0.2.0
Documentation de configuration d’OpenBot : variables d’environnement du modèle, model.yaml et vérification au démarrage
Lien : github.com/CopilotKit/OpenBot/blob/main/docs/configuration.md
Contenu : définitions d’origine de OPENAI_BASE_URL, BOT_MODEL et BOT_RESPONSES_API
Documentation d’architecture d’OpenBot : passerelle, politiques et audit
Lien : github.com/CopilotKit/OpenBot/blob/main/docs/architecture.md
Contenu : ordre d’appel des outils et interface d’exportation des audits
Centre de documentation APIYI : mode compatible OpenAI, appels de fonctions et liste des modèles
Lien : docs.apiyi.com
Contenu : syntaxe de base_url, format de tools et prix de claude-opus-5-5

Auteur : équipe technique APIYI
Échanges techniques : contactez-nous sur le site officiel d’APIYI, apiyi.com. Pour plus de ressources sur l’intégration, consultez le centre de documentation docs.apiyi.com.

OpenBot ne se connecte pas à APIYI ? 3 variables d’environnement et votre collègue IA allume lui-même l’ordinateur

Le modèle d’OpenBot ne se configure pas dans l’interface