Documentação

Open Interpreter

O Open Interpreter lê provedores de uma tabela TOML, como fazia seu antecessor Codex — mas manteve um transporte de Conclusões de chat que o Codex upstream removeu. Basta um bloco [model_providers.kunavo] para que o agente execute qualquer modelo acessível com a chave.

Uma única tabela [model_providers.kunavo] em ~/.openinterpreter/config.toml — base_url, env_key, wire_api = "chat" — e o agente de terminal Rust roda em qualquer modelo alcançado pela chave.

~/.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"

A URL base mantém o sufixo /v1 no protocolo chat. A documentação do Open Interpreter esclarece isso por meio de exemplos, e não de uma regra expressa: o bloco de provedor personalizado na página de provedores usa base_url = "https://api.example.com/v1", o da página de configuração usa "https://api.acme.example/v1", e o gateway hospedado que documentam pelo nome usa "https://app.nz/v1". Se você remover o sufixo, o resultado será um erro 404, não um erro de autenticação.

Kunavo não testou este cliente em seu endpoint — nem este nem qualquer outro cliente destas páginas. O que foi conferido é a configuração: as chaves abaixo são as que a documentação do próprio Open Interpreter mostra, consultada na data indicada no fim desta página; a URL base e os IDs dos modelos são da Kunavo. Uma página de configuração publicada não equivale a um teste. Considere a solicitação de verificação como o que confirma se funciona.

Há dois programas diferentes chamados "Open Interpreter", e este bloco é para o feito em Rust. O pacote Python congelado na versão 0.4.3 é configurado por meio de --api_base, --api_key e --model openai/<id>, ou por meio de interpreter.llm em Python. Nada disso existe no agente de terminal atual, que lê apenas a tabela TOML acima. Execute interpreter --version antes de editar qualquer coisa — um pip install open-interpreter de um tutorial antigo deixa um segundo binário disputando o mesmo nome.

Um ID de modelo Claude faz o Open Interpreter selecionar automaticamente o harness claude-code — os padrões documentados selecionam esse harness para "Anthropic, IDs de modelos Claude, URL base da Anthropic ou qualquer provedor messages". Essa combinação é válida aqui: a tabela de roteamento lista claude-code como compatível com wire_api = "chat". Defina harness explicitamente se quiser outro; um valor explícito sempre prevalece, e um valor não reconhecido volta para chat sem um construtor de solicitação integrado, em vez de falhar com uma mensagem clara.

Ainda não tem uma chave? Crie uma conta na Kunavo, gere uma chave (ela começa com sk-kn-) e adicione crédito a partir de $10 — as chamadas são pagas com esse saldo, e chamadas malsucedidas não são cobradas. O painel então abre na configuração de Open Interpreter.

Passo a passo

Crie uma chave em /app/keys e copie-a — ela é exibida uma única vez.
Exporte a variável com o nome que você vai inserir em env_key: export KUNAVO_API_KEY=sk-kn-.... Esse campo contém o nome da variável, não o valor dela — a documentação lista env_key como a origem que "lê um token bearer de uma variável de ambiente".
Insira o bloco acima em ~/.openinterpreter/config.toml, ou em .openinterpreter/config.toml dentro de um projeto confiável, se quiser aplicá-lo somente a um repositório. A configuração do projeto tem precedência sobre a configuração do usuário; a opção -c key=value tem precedência sobre ambas nessa execução.
Inicie interpreter e execute /model. O seletor consulta primeiro a rota de modelos do provedor ativo, e a Kunavo responde GET /v1/models, então a lista é preenchida automaticamente.
Execute /debug-config se os valores em uso estiverem errados — o comando mostra a configuração efetiva e a origem de cada valor, o que permite identificar um perfil desatualizado ou um arquivo de projeto mais rapidamente do que reler o TOML.

Verificado em Página de provedores de modelos do Open Interpreter em 21 de setembro de 2026. As configurações de terceiros podem mudar; se o nome de um campo aqui já não corresponder ao que você vê, aquela página é a autoridade, não esta.

Esta é a versão resumida. O guia completo — escolha do modelo, custo de uma sessão real e modos de falha — está em as diferenças entre as versões do Open Interpreter, preços e alternativas.

Verifique antes de depurar o cliente

Uma solicitação determina se a falha está no endpoint, na chave ou no arquivo de configuração. Se isto retornar JSON, a mesma URL base e a mesma chave funcionarão em 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-..."

Qual ID de modelo inserir no campo

Todo modelo de texto pode ser acessado como um ID de modelo — a lista atual está em GET /v1/models, e o catálogo com preços está na página de modelos. As tarifas são em USD por 1 milhão de tokens, entrada / saída.

ID do modelo	Entrada / saída da Kunavo	Onde se encaixa em Open Interpreter
`claude-sonnet-5`	$1.40 / $7.00	o modelo de trabalho padrão para ciclos de edição e execução
`claude-opus-5`	$3.50 / $17.50	planejar uma grande refatoração, quando um plano errado custa caro
`claude-haiku-4-5`	$0.70 / $3.50	sessões com muito uso do shell, nas quais a quantidade de turnos é determinante
`gpt-5-6-sol`	$2.00 / $12.00	uma segunda opinião de outra família, com a mesma chave

A cobrança é por token, usando um saldo pré-pago e sem tarifa mensal — consulte billing. Em contextos repetidos — que representam a maior parte do que um editor ou cliente de chat envia — o cache de prompt altera a conta mais do que a escolha do modelo.

Perguntas frequentes

Como aponto o Open Interpreter para um provedor de API personalizado?

Adicione uma tabela [model_providers.<id>] a ~/.openinterpreter/config.toml com name, base_url, env_key e wire_api; depois, selecione-a com a chave de nível superior model_provider e indique um modelo com model. Para um endpoint compatível com OpenAI, use wire_api = "chat" e uma URL base terminada em /v1 — esse é o formato mostrado na página de provedores do próprio Open Interpreter para um provedor personalizado e para o gateway hospedado que documenta pelo nome. env_key contém o nome de uma variável de ambiente, portanto, exporte a chave em vez de colá-la no arquivo.

A base_url do Open Interpreter precisa terminar em /v1?

No protocolo chat, sim. A documentação não declara em texto uma regra para montar o caminho, mas todos os exemplos de provedores personalizados que apresenta incluem o sufixo: https://api.example.com/v1 na página de provedores, https://api.acme.example/v1 na página de configuração e https://app.nz/v1 para o gateway que ela menciona. O protocolo messages funciona de outra forma — os provedores no estilo Anthropic que acompanham o cliente usam uma raiz de API sem /v1 — portanto, a resposta /v1 se aplica especificamente a wire_api = "chat" e a wire_api = "responses".

As opções antigas --api_base e --model openai/... ainda funcionam?

Não. Elas pertencem ao pacote Python congelado na versão 0.4.3, que fazia o roteamento pelo LiteLLM e, por isso, precisava do prefixo openai/. O agente de terminal atual é um fork em Rust do Codex e não tem essas opções nem essa convenção de prefixo: ele lê uma tabela de provedores TOML de ~/.openinterpreter/config.toml ou de .openinterpreter/config.toml no nível do projeto e seleciona o provedor e o modelo com model_provider e model. A configuração é criada do zero, e docs.openinterpreter.com redireciona para a documentação do Rust, então os links de um tutorial antigo continuam funcionando, embora descrevam um programa que você não tem instalado.

Por que o seletor /model não mostra a janela de contexto de um provedor personalizado?

Porque esses metadados vêm do catálogo incluído no cliente, gerado a partir de models.dev mais alguns endpoints de provedores ativos, e são preenchidos somente quando um provedor corresponde a uma entrada pela identidade Anthropic, URL base, nome do provedor ou variável de ambiente de autenticação. A Kunavo não está nesse catálogo gerado — isso foi conferido no arquivo do repositório em 21 de setembro de 2026 —, então um provedor configurado manualmente obtém a lista de modelos da própria rota de modelos do endpoint e nada mais. Os modelos ainda funcionam; o seletor é que tem menos informações para exibir ao lado deles.

O Open Interpreter consegue acessar um modelo Claude sem uma conta Anthropic?

Sim, porque wire_api indica um protocolo de transporte, não um fornecedor. Com wire_api = "chat", o ID do modelo é repassado ao valor de base_url configurado e resolvido ali, então a credencial usada é a do endpoint. O Open Interpreter ainda selecionará automaticamente o harness claude-code com base em um ID de modelo Claude, e esse harness é listado como compatível com o protocolo chat. Portanto, é a combinação documentada, não uma solução improvisada.