Run Open Interpreter on a custom OpenAI-compatible endpoint.

Quick answer: api_base plus the openai/ model prefix.

Open Interpreter documents a custom-endpoint path in both interfaces. On the CLI, pass --api_base with the endpoint and --model with an openai/ prefix on the id. In Python, set interpreter.llm.api_base, interpreter.llm.api_key, and interpreter.llm.model before calling chat(). The prefix is not decoration. Open Interpreter runs on LiteLLM, and LiteLLM resolves which provider client to use from the model string. openai/claude-sonnet-4-6 means "speak the OpenAI chat-completions protocol to whatever api_base says, with claude-sonnet-4-6 as the model field." Drop the prefix and LiteLLM infers the provider from the bare name instead, routing a claude-* id toward Anthropic's client and ignoring the endpoint you configured.

export OPENAI_API_KEY=sk-APIsRouter-...

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

What Open Interpreter does with its model.

Open Interpreter (openinterpreter on GitHub, roughly 66K stars) gives a language model a code interpreter on your machine: you state a goal in natural language, the model writes Python or shell, Open Interpreter executes it locally, and the output feeds back into the conversation for the next step. That loop makes it qualitatively different from a chat client. The model is not producing prose; it is producing code that runs with your user's permissions, and it iterates against real errors from your real system. Two consequences follow for routing. First, model quality is directly a safety and correctness property: a model that hallucinates flags or misreads a traceback produces another failing round trip, and in auto-run mode it produces one you did not review. Second, the loop is token-hungry in a specific way: each turn resends the growing conversation, code, and captured output, so long debugging sessions compound context quickly. The api_base setting moves this whole loop to one endpoint. Because the model field passes through as a plain string after the openai/ prefix, a Claude id, a GPT id, and a DeepSeek id are interchangeable one-flag choices rather than separate provider setups.

Full setup: Python API and a profile.

The Python path sets the same three values on interpreter.llm and adds the two settings LiteLLM cannot discover for a custom id: context_window and max_tokens. Open Interpreter uses context_window to decide how much conversation history to keep before trimming, so leaving it unset or defaulted on a 200k model trims far earlier than necessary; declare what the model actually supports. For a persistent setup, the same keys live in a profile YAML under an llm: block (open the profiles directory with interpreter --profiles). A profile keeps the endpoint, model, and window settings out of your shell history and makes the configuration shareable across machines, with the key still supplied by the environment.

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.")

Choosing the model that writes your code.

Model comparison here is unusually concrete: give two models the same task and count round trips to a working result. The per-key usage view adds the token cost per session, which together with round-trip count is the whole comparison. Behind one endpoint each candidate is one flag.

• The main loop wants a model that writes runnable code and reads tracebacks well on the first pass; claude-sonnet-4-6 and gpt-5.5 are the dependable middle, and every failed round trip a better model avoids is tokens and wall-clock saved.
• deepseek-v4-pro is a strong candidate for code-heavy sessions where volume matters; through one endpoint, trying it against your own tasks is a single --model change.
• Quick utility sessions (file renames, one-off transforms, format conversions) do not need frontier reasoning; claude-haiku-4-5-20251001 or glm-5.2 keep them fast and inexpensive.
• Auto-run mode (-y) removes the human review step between code generation and execution. If you use it at all, use it with the strongest model you run, in a sandbox or container, never with a model you are still evaluating.

Pay-as-you-go · transparent per-model pricing

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

The failure modes specific to Open Interpreter.

A bare model id routes around your endpoint. Without the openai/ prefix, LiteLLM resolves the provider from the name: claude-* ids head for Anthropic's client, and the result is an auth or routing error against a host you never configured. If errors mention a vendor SDK rather than your gateway, the prefix is missing. Default context assumptions trim your sessions. For an id LiteLLM does not recognize, nothing fills in the context window; Open Interpreter falls back to conservative behavior and trims history early. Declare context_window explicitly, because a code-debugging session that loses its earlier attempts re-makes the same mistakes. Growing sessions, growing bills. Each turn resends conversation plus code plus captured output. A session that pastes a large dataframe or a long log into the loop carries it in every subsequent request. Prefer having the model write code that inspects files over pasting file contents into chat, and start fresh sessions when a task changes. Function-calling mismatch. Open Interpreter can use structured function calls where supported; the supports_functions flag exists for ids where detection guesses wrong. If code blocks arrive malformed on a model you know is capable, set it to True explicitly; if a model genuinely lacks tool support, set False so the fallback path engages. The execution side is yours. api_base moves the model traffic; the code still runs locally with your permissions. A gateway does not sandbox anything, so keep auto-run confined to containers and let the safety review stay in the loop everywhere else.

Who routes Open Interpreter through a gateway.

• Developers using Open Interpreter as a daily automation tool who want Claude-quality code generation, GPT variety, and fast utility ids behind one key.
• Data folks running exploratory analysis loops, where a session can burn through surprising context and per-key usage makes the cost per notebook-equivalent visible.
• Engineers comparing code-writing models on round-trips-to-working, the most honest benchmark available, one --model flag per candidate.
• Tinkerers running scheduled or containerized interpreter jobs, where an env-var endpoint and one secret beat a per-vendor credential set.
• Developers without access to a given vendor's billing. Top-up based access with no card requirement removes the sign-up dependency per provider.

Verify the endpoint and debug the first session.

List the gateway's models first; the id after openai/ must match a served id exactly, version suffix included. First-session failures follow a pattern. Errors naming anthropic or another vendor SDK mean the openai/ prefix is missing and LiteLLM routed by name. A 401 means the key is not visible in the shell that launched the interpreter, or was set for a different variable than the one in use; with the prefix in place, OPENAI_API_KEY or an explicit api_key both work. A model-not-found error from the gateway is an id typo. A connection error usually means api_base lost its /v1 suffix; the client appends /chat/completions to whatever base you provide. Once the loop runs, the APIsRouter console shows per-request model, token counts, and spend. Interpreter sessions are the classic case of a workload that feels small and bills medium, and the usage view is how you see which sessions actually carried the tokens.

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

FAQ