Rode o Open Interpreter em um endpoint personalizado compatível com OpenAI.
Updated 2026-07-30
O Open Interpreter expõe api_base diretamente. Aponte-o para https://api.apisrouter.com/v1, prefixe o id do modelo com openai/ para que o LiteLLM fale chat completions, e o modelo que escreve e roda código na sua máquina pode ser qualquer id do catálogo sob uma chave.
Resposta rápida: api_base mais o prefixo de modelo openai/.
O Open Interpreter documenta um caminho de endpoint personalizado nas duas interfaces. Na CLI, passe --api_base com o endpoint e --model com um prefixo openai/ no id. Em Python, defina interpreter.llm.api_base, interpreter.llm.api_key, e interpreter.llm.model antes de chamar chat(). O prefixo não é decoração. O Open Interpreter roda sobre o LiteLLM, e o LiteLLM resolve qual cliente de provider usar a partir da string do modelo. openai/claude-sonnet-4-6 significa "fale o protocolo chat-completions da OpenAI com o que api_base diz, com claude-sonnet-4-6 como o campo de modelo". Remova o prefixo e o LiteLLM infere o provider do nome puro em vez disso, roteando um id claude-* para o cliente da Anthropic e ignorando o endpoint que você configurou.
export OPENAI_API_KEY=sk-APIsRouter-...
interpreter \
--api_base https://api.apisrouter.com/v1 \
--model openai/claude-sonnet-4-6O que o Open Interpreter faz com seu modelo.
O Open Interpreter (openinterpreter no GitHub, cerca de 66 mil estrelas) dá a um modelo de linguagem um interpretador de código na sua máquina: você declara um objetivo em linguagem natural, o modelo escreve Python ou shell, o Open Interpreter o executa localmente, e a saída realimenta a conversa para o próximo passo. Esse loop o torna qualitativamente diferente de um cliente de chat. O modelo não está produzindo prosa; está produzindo código que roda com as permissões do seu usuário, e itera contra erros reais do seu sistema real. Duas consequências seguem para o roteamento. Primeiro, qualidade de modelo é diretamente uma propriedade de segurança e correção: um modelo que alucina flags ou interpreta mal um traceback produz outra ida e volta falha, e no modo de execução automática produz uma que você não revisou. Segundo, o loop é faminto por tokens de uma forma específica: cada turno reenvia a conversa, código, e saída capturada em crescimento, então sessões de depuração longas acumulam contexto rapidamente. A configuração api_base move esse loop inteiro para um endpoint. Como o campo de modelo passa como uma string simples depois do prefixo openai/, um id Claude, um id GPT, e um id DeepSeek são escolhas intercambiáveis de uma flag em vez de configurações de provider separadas.
Configuração completa: API Python e um perfil.
O caminho Python define os mesmos três valores em interpreter.llm e adiciona as duas configurações que o LiteLLM não consegue descobrir para um id personalizado: context_window e max_tokens. O Open Interpreter usa context_window para decidir quanto histórico de conversa manter antes de cortar, então deixá-lo sem definição ou no padrão em um modelo de 200 mil corta muito antes do necessário; declare o que o modelo de fato suporta. Para uma configuração persistente, as mesmas chaves vivem em um YAML de perfil sob um bloco llm: (abra o diretório de perfis com interpreter --profiles). Um perfil mantém o endpoint, modelo, e configurações de janela fora do histórico do seu shell e torna a configuração compartilhável entre máquinas, com a chave ainda fornecida pelo ambiente.
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"
# o LiteLLM não consegue inferir isso para um id personalizado: declare
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.")Escolhendo o modelo que escreve seu código.
A comparação de modelo aqui é incomumente concreta: dê a dois modelos a mesma tarefa e conte idas-e-voltas até um resultado funcional. A visão de uso por chave adiciona o custo de token por sessão, que junto com a contagem de idas-e-voltas é a comparação inteira. Atrás de um endpoint, cada candidato é uma flag.
- O loop principal quer um modelo que escreva código executável e leia tracebacks bem na primeira passada; claude-sonnet-4-6 e gpt-5.5 são o meio-termo confiável, e toda ida-e-volta falha que um modelo melhor evita são tokens e tempo real economizados.
- deepseek-v4-pro é um forte candidato para sessões pesadas em código onde volume importa; através de um endpoint, testá-lo contra suas próprias tarefas é uma única mudança de --model.
- Sessões de utilidade rápidas (renomear arquivos, transformações pontuais, conversões de formato) não precisam de raciocínio de ponta; claude-haiku-4-5-20251001 ou glm-5.2 as mantêm rápidas e baratas.
- O modo de execução automática (-y) remove a etapa de revisão humana entre geração e execução de código. Se você o usar de alguma forma, use-o com o modelo mais forte que você roda, em um sandbox ou container, nunca com um modelo que você ainda está avaliando.
Pague pelo uso · abaixo do preço oficial
Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.
| Modelo | Preço oficial | Nosso preço |
|---|---|---|
| Claude Sonnet 4.6 | $3.00 / $15.00 per M | $2.40 / $12.00 per M |
| GPT-5.5 | $5.00 / $30.00 per M | $4.00 / $24.00 per M |
| DeepSeek V4 Pro | $0.43 / $0.87 per M | $0.40 / $0.90 per M |
| Claude Haiku 4.5 20251001 | $1.00 / $5.00 per M | $0.80 / $4.00 per M |
| GLM-5.2 | $1.14 / $4.00 per M | $1.10 / $4.00 per M |
Os modos de falha específicos do Open Interpreter.
Um id de modelo nu contorna seu endpoint. Sem o prefixo openai/, o LiteLLM resolve o provider a partir do nome: ids claude-* vão para o cliente da Anthropic, e o resultado é um erro de autenticação ou roteamento contra um host que você nunca configurou. Se erros mencionam um SDK de fornecedor em vez do seu gateway, o prefixo está faltando. Suposições padrão de contexto cortam suas sessões. Para um id que o LiteLLM não reconhece, nada preenche a janela de contexto; o Open Interpreter recai em comportamento conservador e corta o histórico cedo. Declare context_window explicitamente, porque uma sessão de depuração de código que perde suas tentativas anteriores refaz os mesmos erros. Sessões crescentes, contas crescentes. Cada turno reenvia conversa mais código mais saída capturada. Uma sessão que cola um dataframe grande ou um log longo no loop o carrega em toda requisição subsequente. Prefira que o modelo escreva código que inspecione arquivos em vez de colar conteúdo de arquivo no chat, e comece sessões novas quando uma tarefa muda. Incompatibilidade de chamada de função. O Open Interpreter pode usar chamadas de função estruturadas onde suportado; a flag supports_functions existe para ids onde a detecção adivinha errado. Se blocos de código chegam malformados em um modelo que você sabe ser capaz, defina-a como True explicitamente; se um modelo genuinamente não tem suporte a ferramentas, defina False para que o caminho de fallback entre em ação. O lado de execução é seu. api_base move o tráfego do modelo; o código ainda roda localmente com suas permissões. Um gateway não faz sandbox de nada, então mantenha a execução automática confinada a containers e deixe a revisão de segurança permanecer no loop em todo o resto.
Quem roteia o Open Interpreter por um gateway.
- Desenvolvedores usando o Open Interpreter como uma ferramenta de automação diária que querem geração de código com qualidade Claude, variedade GPT, e ids de utilidade rápidos atrás de uma chave.
- Pessoas de dados rodando loops de análise exploratória, onde uma sessão pode consumir contexto surpreendente e uso por chave torna o custo por notebook-equivalente visível.
- Engenheiros comparando modelos de escrita de código em idas-e-voltas até funcionar, o benchmark mais honesto disponível, uma flag --model por candidato.
- Curiosos rodando jobs de interpreter agendados ou em container, onde um endpoint por variável de ambiente e um segredo vencem um conjunto de credenciais por fornecedor.
- Desenvolvedores sem acesso ao faturamento de um determinado fornecedor. O acesso baseado em recarga sem exigência de cartão remove a dependência de cadastro por provedor.
Verifique o endpoint e depure a primeira sessão.
Liste os modelos do gateway primeiro; o id depois de openai/ precisa corresponder a um id servido exatamente, sufixo de versão incluído. Falhas de primeira sessão seguem um padrão. Erros nomeando anthropic ou outro SDK de fornecedor significam que o prefixo openai/ está faltando e o LiteLLM roteou pelo nome. Um 401 significa que a chave não está visível no shell que lançou o interpreter, ou foi definida para uma variável diferente da que está em uso; com o prefixo no lugar, OPENAI_API_KEY ou um api_key explícito funcionam ambos. Um erro model-not-found do gateway é um erro de digitação no id. Um erro de conexão geralmente significa que api_base perdeu seu sufixo /v1; o cliente anexa /chat/completions a qualquer base que você fornecer. Assim que o loop roda, o console da APIsRouter mostra modelo, contagens de token e gasto por requisição. Sessões de interpreter são o caso clássico de uma carga que parece pequena e cobra médio, e a visão de uso é como você vê quais sessões de fato carregaram os tokens.
curl -s https://api.apisrouter.com/v1/models \
-H "Authorization: Bearer $APISROUTER_API_KEY" | head -50Perguntas frequentes
O Open Interpreter pode rodar modelos Claude ou DeepSeek através de um endpoint?
Sim. Com api_base apontando para o gateway e o prefixo openai/ no id do modelo, o LiteLLM fala chat completions padrão para aquele endpoint e encaminha o id como uma string simples. Ids Claude, GPT, DeepSeek, e GLM todos funcionam com as mesmas duas configurações.
Por que o id do modelo precisa do prefixo openai/?
O Open Interpreter roda sobre o LiteLLM, que escolhe seu cliente de provider a partir da string do modelo. O prefixo openai/ força o cliente do protocolo OpenAI direcionado ao seu api_base. Um id claude-* nu resolve para o cliente da Anthropic em vez disso e ignora seu endpoint.
Qual variável de ambiente contém a chave?
Com o prefixo openai/ em jogo, OPENAI_API_KEY é a escolha convencional, ou defina interpreter.llm.api_key explicitamente em Python, ou passe --api_key na CLI. Mantenha a chave fora de perfis e scripts; o ambiente é o lugar certo para ela.
Preciso definir context_window manualmente?
Para ids personalizados, sim. O LiteLLM não consegue inferir a janela para um modelo que não reconhece, e o Open Interpreter corta o histórico de conversa contra essa cifra. Declare a janela real do modelo (200000 para os ids Claude na tabela) ou sessões longas perdem seu contexto anterior.
Rotear por um gateway torna a execução automática (-y) segura?
Não. O gateway carrega o tráfego do modelo; o código gerado ainda executa localmente com suas permissões. A execução automática remove a etapa de revisão, então confine-a a containers ou sandboxes independentemente de qual endpoint serve o modelo.
Quantos tokens uma sessão de interpreter usa?
Escala com turnos e com o que entra no loop: cada ida-e-volta reenvia conversa, código, e saída capturada. Tarefas de utilidade curtas são modestas; sessões de depuração longas com dados colados se acumulam rapidamente. A visão de uso por chave no console da APIsRouter mostra a cifra real por sessão.