Alternatives à Open Interpreter : agent actuel, Python historique et migration

Avant de chercher des alternatives à Open Interpreter, déterminez quel Open Interpreter vous quittez : ce nom désigne désormais un agent de codage terminal Rust qui est un fork de Codex d’OpenAI, tandis que l’outil Python qui exécutait du code généré sur votre propre machine est figé en version 0.4.3 depuis octobre 2024 et n’est plus maintenu par le projet. Toutes ses générations sont gratuites et open source ; il ne s’agit donc jamais d’une décision concernant le prix d’une licence — c’est une décision sur le programme que vous voulez, le seul coût récurrent étant celui de l’API du modèle vers laquelle vous le dirigez.

Deux redirections dissimulent cette séparation. La demande de l’ancien chemin de dépôt OpenInterpreter/open-interpreter via l’API GitHub renvoie openinterpreter/openinterpreter, en langage Rust, et docs.openinterpreter.com répond HTTP 308 vers la documentation du terminal Rust. Les liens d’un tutoriel de 2023 ou 2024 continuent de fonctionner ; ils fournissent simplement la documentation d’un autre programme, décrivant des commandes que le binaire installé ne possède pas. Les deux éléments ont été vérifiés le 18 septembre 2026.

Un nom, trois programmes et un paquet abandonné

La redirection depuis l’ancien chemin du dépôt explique pourquoi la séparation est facile à manquer. Le README actuel l’indique en une seule ligne vers le bas — « Il s’agit de la nouvelle version Rust d’Open Interpreter, basée sur Codex. Vous cherchez le projet Python original ? Il continue d’exister sous la forme d’un fork maintenu par la communauté à l’adresse endolith/open-interpreter. » Notez que la licence a également changé avec la réécriture, passant d’AGPL-3.0 à Apache-2.0, ce qui compte si vous avez intégré l’ancien code à votre projet. L’organisation détient aussi le projet vocal dormant 01, dont le dernier push date de novembre 2024, ainsi que 01-app et aifs, qui n’ont tous deux pas été touchés depuis 2024. Aucun des trois n’est archivé, et aucun n’est actuel non plus.

Tarification d’Open Interpreter : il n’y en a pas, et ces trois chiffres ne la représentent pas

Il n’existe aucun forfait, siège, quota ni compte. openinterpreter.com/pricing a renvoyé HTTP 404 le 18 septembre 2026 ; les pages d’installation dans le terminal, de démarrage rapide et de configuration ne contiennent aucun texte relatif aux prix, aux abonnements ou à la facturation ; et le README du produit de bureau indique lui-même qu’il « ne nécessite pas de compte Interpreter ». Il s’agit d’une conclusion fondée sur l’absence de preuve — aucune page tarifaire trouvée, plutôt qu’une promesse du projet qu’il n’y en aura jamais — mais c’est la réponse honnête à « open interpreter pricing » : le seul coût récurrent concerne les jetons du modèle.

Les prix qui dominent cette recherche appartiennent à d’autres produits. Ne les incluez pas dans votre budget :

Les prix des deux outils ont été vérifiés le 18 septembre 2026.

Quelle alternative convient à quel utilisateur

Ce qui se migre, et ce qui ne se migre pas

Rien ne se transfère de la génération Python. Les indicateurs, l’API Python, les fichiers de profils YAML et Python ainsi que la convention de noms de modèles LiteLLM ont tous disparu. En revanche, la configuration compatible avec Codex et avec les standards se transfère ; le projet la documente volontairement sur sa page de migration :

Vérifiez le conflit de noms binaires avant l’installation. La roue héritée 0.4.3 déclare quatre scripts de console — interpreter, i, interpreter-classic et wtf — tandis que l’installateur actuel place interpreter, i et codex-code-mode-host dans ~/.local/bin, conformément à la page d’installation. Si vous avez déjà exécuté pip install open-interpreter, deux programmes différents se disputent désormais deux de ces noms, interpreter et i, et celui qui l’emporte dépend de la priorité du shell. Exécutez which -a interpreter, which -a i et interpreter --version d’abord, puis à nouveau après l’installation.

Retour arrière. Sauvegardez ~/.openinterpreter/ avant de changer de fournisseur — la boucle de désinstallation documentée supprime l’installation autonome gérée, mais conserve volontairement ce répertoire, y compris la configuration, les sessions, les journaux et les identifiants stockés dans des fichiers ; une réinstallation restaure donc votre configuration. Dans l’autre sens, conservez l’environnement virtuel hérité au lieu de le supprimer : la version 0.4.3 est toujours disponible sur PyPI, mais il n’est pas garanti qu’un ancien ensemble de dépendances puisse être résolu à nouveau ultérieurement.

Configurer l’agent actuel pour utiliser un point de terminaison compatible avec OpenAI

C’est la phrase la plus importante si vous arrivez de notre configuration de Codex CLI, qui indique que wire_api n’a qu’une seule valeur autorisée. Cette règle est vraie pour Codex en amont et fausse pour Open Interpreter. La propre référence de configuration du projet amont indique à propos de wire_api que « responses est la seule valeur prise en charge et la valeur par défaut lorsqu’elle est omise ». Le delta maintenu d’Open Interpreter présente donc comme ajouts délibérés un « transport OpenAI-compatible Chat Completions de première classe » et un « transport compatible avec Anthropic Messages pour les fournisseurs exposant cette API ». Le fork atteint ainsi des points de terminaison auxquels Codex en amont ne peut pas accéder, et les trois interfaces de Kunavo — /v1/responses, /v1/chat/completions et /v1/messages — disposent d’une valeur de protocole correspondante.

La structure documentée d’un fournisseur personnalisé, présentée sur la page des fournisseurs, est un bloc chat-completions avec une URL de base se terminant par /v1 ; la même page montre une passerelle hébergée configurée exactement de cette manière. Appliqué à Kunavo :

# Top-level keys come FIRST. Anything written after a [table] header
# belongs to that table, so model_provider placed below would be ignored.
model_provider = "kunavo"
model = "gpt-5-6-terra"

[model_providers.kunavo]
name = "Kunavo"
base_url = "https://api.kunavo.com/v1"
env_key = "KUNAVO_API_KEY"
wire_api = "chat"

Trois limites qu’il vaut la peine de connaître avant d’y consacrer une soirée, toutes tirées de la documentation du projet et non testées ici :

• Kunavo ne figure pas dans le catalogue intégré ; définissez donc model manuellement. Le catalogue des fournisseurs généré est construit à partir de models.dev et de quelques points de terminaison de fournisseurs actifs ; il comptait 116 fournisseurs lors de la vérification. Kunavo ne figure ni dans ce catalogue ni dans models.dev. Ne vous attendez pas à ce que le sélecteur /model renseigne les métadonnées de fenêtre de contexte ou de capacités pour un fournisseur défini manuellement.
• Le routage du harnais est strict. Selon la page du harnais, chat accepte le chat natif ainsi que claude-code, claude-code-bare, deepseek-tui, kimi-code, kimi-cli, qwen-code, swe-agent et minimal ; responses accepte le mode natif, claude-code et claude-code-bare ; et avec messages, « le mode natif est rejeté, car Messages nécessite un transport propre au harnais ». Toute chaîne de harnais non reconnue revient au chat sans générateur de requêtes intégré ; une faute de frappe dégrade donc silencieusement l’exécution. La documentation n’indique pas quel harnais offre les meilleures performances avec un modèle donné, et cette page ne le suppose pas.
• L’URL de base Messages est une déduction, pas un exemple Kunavo documenté. Les fournisseurs Messages fournis dans le catalogue — Anthropic et ZCode de Z.AI — utilisent tous deux une racine d’API sans /v1, et la page de Z.AI indique que la requête ZCode Messages est envoyée à /v1/messages — le client ajoute donc le chemin. Selon cette règle, un bloc compatible avec Anthropic utiliserait la racine de l’API plutôt que l’URL /v1 ci-dessus ; toutefois, aucun exemple de fournisseur Messages personnalisé n’existe dans la documentation officielle et cela n’a pas été exécuté. Commencez avec le protocole chat, qui est la structure documentée.

Deux autres détails documentés : env_key désigne le nom de la variable d’environnement, pas la clé elle-même, et pour les exécutions ponctuelles interpreter --chat-completions remplace la structure de la requête pour cette invocation sans modifier l’URL de base, les identifiants ou le modèle du fournisseur. La connexion ChatGPT est répertoriée comme l’authentification du fournisseur intégré openai, et non comme une option de fournisseur personnalisé ; les sources d’authentification documentées par la page des fournisseurs pour un tableau de fournisseurs sont env_key, experimental_bearer_token et un bloc auth adossé à une commande, ainsi qu’un bloc aws réservé à Amazon Bedrock.

Estimation détaillée du coût d’une session

Il s’agit d’un calcul illustratif de jetons, pas de coûts de tâche mesurés ni d’un plafond de facturation. Supposons une session d’agent qui envoie 300 000 jetons d’entrée non mis en cache et reçoit 20 000 jetons de sortie — une forme choisie à titre d’illustration, car un harnais de type Codex renvoie le contexte accumulé à chaque tour. Votre propre dépôt et votre nombre de tours seront différents. Les tarifs sont les prix actuels du catalogue Kunavo par million de jetons.

L’écart est le point important, plutôt qu’une ligne en particulier : selon ces hypothèses, les modèles Claude Haiku 4.5 facturent la même session $0.280 contre $0.840 pour Claude Sonnet 4.6. Cela ne constitue pas une recommandation de choisir le tarif le moins cher. Le prix affiché le plus bas et le coût total le plus faible pour terminer la tâche sont deux affirmations différentes ; un modèle qui nécessite trois tentatives pour une refactorisation peut coûter plus cher qu’un modèle qui réussit en une seule passe — mesurez les deux sur votre propre dépôt avant de décider. Le montant du catalogue Kunavo est un plancher de facturation, pas un plafond : lorsque le fournisseur amont communique son montant, la facture correspond au plus élevé entre le coût du catalogue et le coût amont multiplié par la majoration applicable. Les frais de cache et les outils externes ne sont pas inclus dans cet exemple. Le rechargement minimal est de $10 de crédit prépayé, ce qui constitue un minimum de financement, et non des frais de tâche ou un abonnement — consultez les détails de facturation.

Configuration, en toute honnêteté

Open Interpreter n’a pas été testé en conditions d’exécution avec Kunavo : rien sur cette page n’a été exécuté et chaque affirmation de configuration ci-dessus a été lue dans le dépôt et la documentation du projet le 18 septembre 2026. La référence publiée la plus proche est l’intégration Codex CLI, dont le bloc TOML a la même structure — copiez-le, remplacez le répertoire de configuration par ~/.openinterpreter/config.toml et ignorez sa règle imposant un seul wire_api, qui appartient à Codex en amont. Conservez une route fonctionnelle, exécutez une tâche limitée, puis consultez le montant enregistré par votre compte. Créez un compte Kunavo lorsque vous serez prêt à approvisionner une clé.

Vous comparez encore les routes plutôt que les clients ? L’API compatible avec OpenAI couvre ce que le protocole chat garantit ou non, et la passerelle LLM traite en général du compromis entre une clé unique et un solde unique.

Questions fréquentes

État du dépôt, versions, registres de paquets, documentation et catalogue des fournisseurs généré vérifiés le 18 septembre 2026 ; les prix des outils OpenAI et Anthropic ont été lus sur leurs propres pages tarifaires le même jour. Aucun prix d’abonnement ChatGPT n’est cité, car cette page a refusé la récupération. Rien ici n’a été testé en conditions d’exécution avec un point de terminaison. Les tarifs des jetons Kunavo proviennent du catalogue actuel, et chaque exemple en dollars de cette page est un calcul illustratif de jetons, non un coût de tâche mesuré.