Documentation

Open Interpreter

Open Interpreter lit les fournisseurs dans une table TOML, comme son ancêtre Codex — mais il a conservé un transport Chat Completions qu’en amont Codex a abandonné. Un bloc [model_providers.kunavo] suffit pour que l’agent utilise n’importe quel modèle accessible avec la clé.

Une seule table [model_providers.kunavo] dans ~/.openinterpreter/config.toml — base_url, env_key, wire_api = "chat" — et l’agent terminal Rust fonctionne avec tout modèle accessible par la clé.

~/.openinterpreter/config.toml

model_provider = "kunavo"
model = "claude-sonnet-5"

[model_providers.kunavo]
name = "Kunavo"
base_url = "https://api.kunavo.com/v1"
env_key = "KUNAVO_API_KEY"     # the NAME of the variable, not the key
wire_api = "chat"

L’URL de base conserve le suffixe /v1 sur le protocole chat. La documentation d’Open Interpreter établit ce point par des exemples plutôt que par une règle explicite : le bloc de fournisseur personnalisé de la page des fournisseurs utilise base_url = "https://api.example.com/v1", celui de la page de configuration utilise "https://api.acme.example/v1", et la passerelle hébergée qu’elle documente nommément utilise "https://app.nz/v1". Si vous supprimez le suffixe, vous obtenez une erreur 404, et non une erreur d’authentification.

Kunavo n’a pas testé ce client avec son endpoint — ni celui-ci, ni aucun autre client présenté sur ces pages. Ce qui a été vérifié, c’est l’interface de configuration : les clés ci-dessous sont celles que la documentation officielle d’Open Interpreter affiche, consultée à la date indiquée au bas de cette page ; l’URL de base et les identifiants de modèle sont ceux de Kunavo. Une page de configuration publiée ne constitue pas un essai. Considérez la requête de vérification comme le moyen de confirmer que cela fonctionne.

Deux programmes différents répondent au nom « Open Interpreter », et ce bloc est destiné à la version Rust. Le paquet Python figé à la version 0.4.3 se configure via --api_base, --api_key et --model openai/<id>, ou via interpreter.llm en Python. Aucun de ces éléments n’existe dans l’agent de terminal actuel, qui ne lit que la table TOML ci-dessus. Exécutez interpreter --version avant de modifier quoi que ce soit — un pip install open-interpreter issu d’un ancien tutoriel laisse un deuxième binaire en concurrence sous le même nom.

Un identifiant de modèle Claude fait choisir automatiquement à Open Interpreter le moteur claude-code — ses valeurs par défaut documentées le sélectionnent pour « Anthropic, les identifiants de modèle Claude, l’URL de base Anthropic ou tout fournisseur messages ». Cette association est prise en charge ici : la table de routage indique que claude-code est compatible avec wire_api = "chat". Définissez explicitement harness si vous en voulez un autre ; une valeur explicite est toujours prioritaire, et une valeur non reconnue entraîne un repli sur chat, sans générateur de requêtes intégré, plutôt qu’un échec explicite.

Pas encore de clé ? Créez un compte Kunavo, créez une clé (elle commence par sk-kn-) et ajoutez un crédit à partir de 10 $ — les appels sont payés sur ce solde et les appels échoués ne sont pas facturés. Le tableau de bord s’ouvre ensuite sur la configuration Open Interpreter.

Étape par étape

Créez une clé sur /app/keys et copiez-la — elle n’est affichée qu’une seule fois.
Exportez-la sous le nom que vous allez inscrire dans env_key : export KUNAVO_API_KEY=sk-kn-.... Ce champ contient le nom de la variable, et non sa valeur — la documentation indique que env_key est la source qui « lit un jeton bearer dans une variable d’environnement ».
Placez le bloc ci-dessus dans ~/.openinterpreter/config.toml, ou dans .openinterpreter/config.toml au sein d’un projet de confiance si vous souhaitez qu’il s’applique à un seul dépôt. La configuration du projet est prioritaire sur celle de l’utilisateur ; une option -c key=value est prioritaire sur les deux pour cette exécution.
Lancez interpreter et exécutez /model. Le sélecteur interroge d’abord la route des modèles du fournisseur actif, et Kunavo répond GET /v1/models, de sorte que la liste se remplit automatiquement.
Exécutez /debug-config si les mauvaises valeurs sont utilisées — cette commande affiche la configuration effective et l’origine de chaque valeur, ce qui permet de repérer plus vite un ancien profil ou un fichier de projet que de relire le TOML.

Vérifié avec Page des fournisseurs de modèles d’Open Interpreter le 21 septembre 2026. Les paramètres tiers évoluent ; si le nom d’un champ ne correspond plus à ce que vous voyez ici, cette page fait autorité, pas celle-ci.

Voici la version courte. Le guide complet — choix du modèle, coût d’une session réelle et modes d’échec — se trouve dans la distinction entre les versions d’Open Interpreter, les tarifs et les alternatives.

Vérifiez avant de déboguer le client

Une requête suffit à déterminer si l’échec vient de l’endpoint, de la clé ou du fichier de configuration. Si cette requête renvoie du JSON, la même URL de base et la même clé fonctionnent dans Open Interpreter.

# Settles whether a failure is the endpoint, the key, or the client.
curl -sS https://api.kunavo.com/v1/models \
  -H "Authorization: Bearer sk-kn-..."

Quel identifiant de modèle saisir dans le champ

Tous les modèles textuels sont accessibles sous forme d’identifiant de modèle — la liste à jour se trouve sur GET /v1/models, et le catalogue avec les prix sur la page des modèles. Les tarifs sont en USD par million de tokens, entrée / sortie.

Identifiant du modèle	Entrée / sortie sur Kunavo	Où cela s’intègre dans Open Interpreter
`claude-sonnet-5`	$1.40 / $7.00	le modèle de travail par défaut pour les cycles de modification et d’exécution
`claude-opus-5`	$3.50 / $17.50	planifier une refactorisation importante, où un plan erroné coûte cher
`claude-haiku-4-5`	$0.70 / $3.50	les sessions intensives en commandes shell, où le nombre de tours est déterminant
`gpt-5-6-sol`	$2.00 / $12.00	un deuxième avis d’une autre famille, avec la même clé

La facturation se fait au token à partir d’un solde prépayé, sans frais mensuels — consultez la facturation. Avec un contexte répété — ce qu’envoient la plupart des éditeurs et clients de chat — la mise en cache des prompts influe davantage sur la facture que le choix du modèle.

Questions fréquentes

Comment configurer un fournisseur d’API personnalisé dans Open Interpreter ?

Ajoutez une table [model_providers.<id>] à ~/.openinterpreter/config.toml avec name, base_url, env_key et wire_api, puis sélectionnez-la avec la clé model_provider de premier niveau et indiquez un modèle avec model. Pour un endpoint compatible avec OpenAI, utilisez wire_api = "chat" et une URL de base se terminant par /v1 — c’est la forme présentée par la page des fournisseurs d’Open Interpreter, à la fois pour un fournisseur personnalisé et pour la passerelle hébergée qu’elle documente nommément. env_key contient le nom d’une variable d’environnement ; exportez donc la clé au lieu de la coller dans le fichier.

L’URL base_url d’Open Interpreter doit-elle se terminer par /v1 ?

Pour le protocole chat, oui. La documentation n’énonce pas en toutes lettres de règle de construction du chemin, mais tous les exemples de fournisseurs personnalisés qu’elle présente comportent ce suffixe : https://api.example.com/v1 sur la page des fournisseurs, https://api.acme.example/v1 sur la page de configuration et https://app.nz/v1 pour la passerelle nommée. Le protocole messages fonctionne différemment — les fournisseurs de style Anthropic fournis avec le client utilisent une racine d’API sans /v1 — la réponse /v1 ne s’applique donc qu’à wire_api = "chat" et à wire_api = "responses".

Les anciennes options --api_base et --model openai/... fonctionnent-elles encore ?

Non. Elles appartiennent au paquet Python figé à la version 0.4.3, qui passait par LiteLLM et nécessitait donc le préfixe openai/. L’agent de terminal actuel est un fork Rust de Codex qui n’a ni ces options ni cette convention de préfixe : il lit une table de fournisseurs TOML dans ~/.openinterpreter/config.toml ou dans un fichier .openinterpreter/config.toml au niveau du projet, puis sélectionne le fournisseur avec model_provider et le modèle avec model. La configuration est écrite à partir de zéro, et docs.openinterpreter.com redirige vers la documentation Rust ; les liens d’un ancien tutoriel fonctionnent donc toujours, tout en décrivant un programme qui n’est pas installé chez vous.

Pourquoi le sélecteur /model n’affiche-t-il aucune fenêtre de contexte pour un fournisseur personnalisé ?

Parce que ces métadonnées proviennent du catalogue intégré au client, généré à partir de models.dev et d’une poignée d’endpoints de fournisseurs interrogés en direct. Elles ne sont intégrées que si un fournisseur correspond à une entrée selon son identité Anthropic, son URL de base, son nom ou sa variable d’environnement d’authentification. Kunavo ne figure pas dans ce catalogue généré — vérifié dans le fichier du dépôt le 21 septembre 2026 — ; un fournisseur défini manuellement récupère donc la liste des modèles depuis la propre route de modèles de l’endpoint, sans rien d’autre. Les modèles fonctionnent toujours ; le sélecteur affiche simplement moins d’informations à côté.

Open Interpreter peut-il accéder à un modèle Claude sans compte Anthropic ?

Oui, car wire_api désigne un protocole de transport et non un fournisseur. Avec wire_api = "chat", l’identifiant du modèle est transmis tel quel à l’URL de base configurée, où il est résolu ; l’identifiant d’accès dont vous avez besoin est donc celui de l’endpoint. Open Interpreter sélectionnera toujours automatiquement son moteur claude-code à partir d’un identifiant de modèle Claude, et ce moteur est indiqué comme compatible avec le protocole chat : il s’agit donc de l’association documentée, pas d’un contournement.