Faites tourner Open Interpreter sur un endpoint compatible OpenAI personnalisé.

Réponse rapide : api_base plus le préfixe de modèle openai/.

Open Interpreter documente un chemin d'endpoint personnalisé dans les deux interfaces. Sur la CLI, passez --api_base avec l'endpoint et --model avec un préfixe openai/ sur l'id. En Python, réglez interpreter.llm.api_base, interpreter.llm.api_key et interpreter.llm.model avant d'appeler chat(). Le préfixe n'est pas décoratif. Open Interpreter tourne sur LiteLLM, et LiteLLM résout quel client de fournisseur utiliser à partir de la chaîne de modèle. openai/claude-sonnet-4-6 signifie "parle le protocole chat-completions d'OpenAI à ce que dit api_base, avec claude-sonnet-4-6 comme champ model". Retirez le préfixe et LiteLLM déduit plutôt le fournisseur du nom nu, routant un id claude-* vers le client d'Anthropic et ignorant l'endpoint que vous avez configuré.

export OPENAI_API_KEY=sk-APIsRouter-...

interpreter \
  --api_base https://api.apisrouter.com/v1 \
  --model openai/claude-sonnet-4-6

Ce qu'Open Interpreter fait avec son modèle.

Open Interpreter (openinterpreter sur GitHub, environ 66 000 étoiles) donne à un modèle de langage un interpréteur de code sur votre machine : vous énoncez un objectif en langage naturel, le modèle écrit du Python ou du shell, Open Interpreter l'exécute localement, et la sortie retourne dans la conversation pour l'étape suivante. Cette boucle le rend qualitativement différent d'un client de chat. Le modèle ne produit pas de la prose ; il produit du code qui tourne avec les permissions de votre utilisateur, et il itère contre de vraies erreurs de votre vrai système. Deux conséquences en découlent pour le routage. D'abord, la qualité du modèle est directement une propriété de sécurité et de correction : un modèle qui hallucine des flags ou lit mal une trace produit un autre aller-retour échoué, et en mode auto-run il en produit un que vous n'avez pas révisé. Ensuite, la boucle est vorace en tokens d'une façon spécifique : chaque tour renvoie la conversation, le code et la sortie capturée qui grossissent, donc les longues sessions de débogage cumulent vite le contexte. Le réglage api_base déplace toute cette boucle vers un seul endpoint. Comme le champ model est transmis comme une simple chaîne après le préfixe openai/, un id Claude, un id GPT et un id DeepSeek sont des choix interchangeables d'un seul flag plutôt que des configurations de fournisseur séparées.

Configuration complète : API Python et un profil.

Le chemin Python règle les mêmes trois valeurs sur interpreter.llm et ajoute les deux réglages que LiteLLM ne peut pas découvrir pour un id personnalisé : context_window et max_tokens. Open Interpreter utilise context_window pour décider combien d'historique de conversation garder avant de tronquer, donc le laisser non défini ou par défaut sur un modèle à 200k tronque bien plus tôt que nécessaire ; déclarez ce que le modèle supporte réellement. Pour une configuration persistante, les mêmes clés vivent dans un YAML de profil sous un bloc llm: (ouvrez le répertoire des profils avec interpreter --profiles). Un profil garde les réglages d'endpoint, de modèle et de fenêtre hors de votre historique shell et rend la configuration partageable entre machines, avec la clé toujours fournie par l'environnement.

import os
from interpreter import interpreter

interpreter.llm.api_base = "https://api.apisrouter.com/v1"
interpreter.llm.api_key = os.environ["APISROUTER_API_KEY"]
interpreter.llm.model = "openai/claude-sonnet-4-6"

# LiteLLM cannot infer these for a custom id; declare them:
interpreter.llm.context_window = 200000
interpreter.llm.max_tokens = 8192
interpreter.llm.supports_functions = True

interpreter.chat("Profile data.csv and plot the top 10 rows by revenue.")

Choisir le modèle qui écrit votre code.

La comparaison de modèles ici est inhabituellement concrète : donnez la même tâche à deux modèles et comptez les allers-retours jusqu'à un résultat fonctionnel. La vue d'usage par clé ajoute le coût en tokens par session, ce qui, avec le nombre d'allers-retours, constitue toute la comparaison. Derrière un seul endpoint, chaque candidat n'est qu'un flag.

• La boucle principale veut un modèle qui écrit du code exécutable et lit bien les traces dès le premier passage ; claude-sonnet-4-6 et gpt-5.5 sont le milieu fiable, et chaque aller-retour échoué qu'évite un meilleur modèle représente des tokens et du temps réel économisés.
• deepseek-v4-pro est un candidat solide pour les sessions à forte charge de code où le volume compte ; via un seul endpoint, l'essayer contre vos propres tâches est un simple changement de --model.
• Les sessions utilitaires rapides (renommages de fichiers, transformations ponctuelles, conversions de format) n'ont pas besoin de raisonnement de pointe ; claude-haiku-4-5-20251001 ou glm-5.2 les gardent rapides et peu coûteuses.
• Le mode auto-run (-y) retire l'étape de révision humaine entre la génération de code et l'exécution. Si vous l'utilisez, faites-le avec le modèle le plus puissant que vous faites tourner, dans un bac à sable ou un conteneur, jamais avec un modèle que vous êtes encore en train d'évaluer.

Paiement à l'usage · en dessous du tarif officiel

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Les modes d'échec spécifiques à Open Interpreter.

Un id de modèle nu contourne votre endpoint. Sans le préfixe openai/, LiteLLM résout le fournisseur d'après le nom : les ids claude-* se dirigent vers le client d'Anthropic, et le résultat est une erreur d'authentification ou de routage contre un hôte que vous n'avez jamais configuré. Si les erreurs mentionnent un SDK fournisseur plutôt que votre passerelle, le préfixe manque. Les hypothèses de contexte par défaut tronquent vos sessions. Pour un id que LiteLLM ne reconnaît pas, rien ne remplit la fenêtre de contexte ; Open Interpreter retombe sur un comportement conservateur et tronque l'historique tôt. Déclarez context_window explicitement, parce qu'une session de débogage de code qui perd ses tentatives précédentes refait les mêmes erreurs. Sessions qui grossissent, factures qui grossissent. Chaque tour renvoie la conversation plus le code plus la sortie capturée. Une session qui colle un grand dataframe ou un long log dans la boucle le porte dans chaque requête suivante. Préférez faire écrire par le modèle du code qui inspecte les fichiers plutôt que de coller le contenu des fichiers dans le chat, et démarrez des sessions fraîches quand une tâche change. Discordance d'appel de fonction. Open Interpreter peut utiliser des appels de fonction structurés là où c'est supporté ; le flag supports_functions existe pour les ids où la détection devine mal. Si des blocs de code arrivent malformés sur un modèle que vous savez capable, réglez-le explicitement sur True ; si un modèle manque réellement de support d'outils, réglez sur False pour que le chemin de repli s'enclenche. Le côté exécution est le vôtre. api_base déplace le trafic du modèle ; le code tourne toujours localement avec vos permissions. Une passerelle ne met rien en bac à sable, donc gardez l'auto-run confiné à des conteneurs et laissez la révision de sécurité rester dans la boucle partout ailleurs.

Qui route Open Interpreter via une passerelle.

• Les développeurs qui utilisent Open Interpreter comme outil d'automatisation quotidien et veulent une génération de code de qualité Claude, la variété de GPT, et des ids utilitaires rapides derrière une seule clé.
• Les gens de la donnée qui font tourner des boucles d'analyse exploratoire, où une session peut brûler un contexte surprenant et l'usage par clé rend visible le coût par équivalent-notebook.
• Les ingénieurs qui comparent des modèles d'écriture de code sur les allers-retours jusqu'au fonctionnement, le benchmark le plus honnête disponible, un flag --model par candidat.
• Les bricoleurs qui font tourner des jobs interpreter planifiés ou conteneurisés, où un endpoint en variable d'environnement et un seul secret l'emportent sur un jeu d'identifiants par fournisseur.
• Les développeurs sans accès à la facturation d'un fournisseur donné. Un accès basé sur la recharge, sans exigence de carte, supprime la dépendance à une inscription par fournisseur.

Vérifiez l'endpoint et déboguez la première session.

Listez d'abord les modèles de la passerelle ; l'id après openai/ doit correspondre exactement à un id servi, suffixe de version inclus. Les échecs de première session suivent un motif. Les erreurs nommant anthropic ou un autre SDK fournisseur signifient que le préfixe openai/ manque et que LiteLLM a routé par nom. Un 401 signifie que la clé n'est pas visible dans le shell qui a lancé l'interpreter, ou a été réglée pour une variable différente de celle utilisée ; avec le préfixe en place, OPENAI_API_KEY ou un api_key explicite fonctionnent tous les deux. Une erreur model-not-found de la passerelle est une faute de frappe dans l'id. Une erreur de connexion signifie généralement qu'api_base a perdu son suffixe /v1 ; le client ajoute /chat/completions à quelle que soit la base que vous fournissez. Une fois que la boucle tourne, la console APIsRouter affiche le modèle par requête, le nombre de tokens et la dépense. Les sessions interpreter sont le cas classique d'une charge qui semble petite et facture moyennement, et la vue d'usage est la façon de voir quelles sessions ont réellement porté les tokens.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

Questions fréquentes