Open Interpreter alternatives: current agent, legacy Python and migration

Before you shop for Open Interpreter alternatives, settle which Open Interpreter you are leaving: the name now belongs to a Rust terminal coding agent that is a fork of OpenAI's Codex, while the Python tool that ran generated code on your own machine is frozen at 0.4.3 from October 2024 and is no longer maintained by the project. Every generation of it is free and open source, so this is never a licence-price decision — it is a decision about which program you want, and the only recurring cost is the model API you point it at.

Two redirects hide the split. Requesting the old repository path OpenInterpreter/open-interpreter through the GitHub API returns openinterpreter/openinterpreter, language Rust, and docs.openinterpreter.com answers HTTP 308 to the Rust terminal docs. A 2023 or 2024 tutorial's links still resolve; they just deliver documentation for a different program, describing commands the installed binary does not have. Both checked September 18, 2026.

One name, three programs, plus a dead package

The redirect from the old repository path is why the split is easy to miss. The current README states it in a single line near the bottom — "This is the new Rust version of Open Interpreter, based on Codex. Looking for the original Python project? It lives on as a community-maintained fork at endolith/open-interpreter." Note the licence changed with the rewrite as well, from AGPL-3.0 to Apache-2.0, which matters if you vendored the old code. The organisation also holds the dormant 01 voice project, last pushed November 2024, plus 01-app and aifs, neither touched since 2024. None of the three is archived, and none of them is current either.

Open Interpreter pricing: there is none, and three numbers are not it

There is no plan, seat, quota or account. openinterpreter.com/pricing returned HTTP 404 on September 18, 2026; the terminal install, quickstart and configuration pages contain no price, subscription or billing text; and the desktop product's own README says it "does not require an Interpreter account". That is an absence-of-evidence conclusion — no pricing page found, rather than a promise from the project that none will appear — but it is the honest answer to "open interpreter pricing": the only recurring cost is model tokens.

The prices that dominate this search belong to other products. Keep them out of your budget:

Both tool prices checked September 18, 2026.

Which alternative fits which user

What migrates, and what does not

Nothing carries from the Python generation. The flags, the Python API surface, the YAML and Python profile files and the LiteLLM model-name convention are all gone. What does carry is Codex-shaped and standards-shaped setup, which the project documents deliberately on its migrate page:

Check the binary-name collision before you install. The legacy 0.4.3 wheel declares four console scripts — interpreter, i, interpreter-classic and wtf — while the current installer places interpreter, i and codex-code-mode-host in ~/.local/bin, per the install page. If you ever ran pip install open-interpreter, two different programs are now competing for two of those names, interpreter and i, and which one wins depends on shell precedence. Run which -a interpreter, which -a i and interpreter --version first, and again after installing.

Rollback. Back up ~/.openinterpreter/ before you change providers — the documented uninstall loop removes the managed standalone install but deliberately keeps that directory, including configuration, sessions, logs and file-stored credentials, so reinstalling restores your setup. Going the other way, keep the legacy virtualenv intact rather than deleting it: 0.4.3 is still on PyPI, but pinning an old dependency set again later is not guaranteed to resolve.

Pointing the current agent at an OpenAI-compatible endpoint

This is the sentence that matters most if you arrive from our Codex CLI setup, which tells you wire_api has exactly one legal value. That rule is true of upstream Codex and false of Open Interpreter. Upstream's own config reference says of wire_api that "responses is the only supported value, and it is the default when omitted". Open Interpreter's maintained delta lists as deliberate additions a "first-class OpenAI-compatible Chat Completions transport" and an "Anthropic Messages-compatible transport for providers that expose that API". So the fork reaches endpoints upstream Codex cannot, and all three of Kunavo's surfaces — /v1/responses, /v1/chat/completions and /v1/messages — have a corresponding wire value.

The documented custom-provider shape, from the providers page, is a chat-completions block with a base URL ending in /v1; the same page shows a hosted gateway configured exactly that way. Applied to 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-luna"

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

Three boundaries worth knowing before you spend an evening on it, all read from the project's documentation rather than tested here:

• Kunavo is not in the bundled catalog, so set model by hand. The generated provider catalog is built from models.dev plus a few live provider endpoints and carried 116 providers when checked; Kunavo is in neither it nor models.dev. Do not expect the /model picker to seed context-window or capability metadata for a hand-written provider.
• Harness routing is strict. Per the harness page, chat accepts native chat plus claude-code, claude-code-bare, deepseek-tui, kimi-code, kimi-cli, qwen-code, swe-agent and minimal; responses accepts native, claude-code and claude-code-bare; and on messages, "native mode is rejected because Messages requires a harness-native transport". Any unrecognised harness string falls back to chat with no built-in request builder, so a typo silently degrades the run. Which harness performs best against any given model is not documented, and this page does not guess.
• The Messages base URL is an inference, not a documented Kunavo example. The shipped Messages providers in the catalog — Anthropic and Z.AI's ZCode — both use an API root without /v1, and the Z.AI page states the ZCode Messages request is sent to /v1/messages — so the client appends the path. By that rule an Anthropic-wire block would use the API root rather than the /v1 URL above, but there is no custom-provider Messages example anywhere in the official docs and this was not run. Start on the chat wire, which is the documented shape.

Two more documented details: env_key names the environment variable, not the key itself, and for one-off runs interpreter --chat-completions overrides the request shape for that invocation without changing the provider's base URL, credentials or model. ChatGPT sign-in is listed as the built-in openai provider's auth, not as a custom-provider option; the auth sources the providers page documents for a provider table are env_key, experimental_bearer_token and a command-backed auth block, plus an aws block for Amazon Bedrock only.

A worked cost estimate for a session

These are illustrative token arithmetic, not measured task costs and not a bill ceiling. Assume one agent session that sends 300,000 uncached input tokens and receives 20,000 output tokens — a shape chosen for illustration, because a Codex-style harness re-sends accumulated context on every turn. Your own repository and turn count will differ. Rates are live Kunavo catalog prices per million tokens.

The spread is the point rather than any single row: under these assumptions GPT-5.6 Luna models the same session at $0.029 against $0.480 for Claude Sonnet 4.6. That is not a recommendation to take the cheapest rate. Cheapest listed price and lowest cost to finish the task are different claims, and a model that needs three attempts at a refactor can cost more than one that needs a single pass — measure both on your own repository before deciding. Kunavo's catalog amount is a billing floor rather than a cap: when the upstream reports its charge, the bill is the greater of catalog cost and upstream cost times the applicable markup. Cache charges and external tools sit outside this example. The minimum top-up is $10 in prepaid credit, which is a funding minimum rather than a task fee or a subscription — see billing details.

Setting it up, honestly

Open Interpreter has not been runtime tested against Kunavo: nothing on this page was executed, and every configuration claim above was read from the project's repository and documentation on September 18, 2026. The closest published reference is the Codex CLI integration, whose TOML block is the same shape — copy it, change the config home to ~/.openinterpreter/config.toml, and ignore its single-wire_api rule, which belongs to upstream Codex. Keep a working route available, run one bounded task, then read the charge your account recorded for it. Create a Kunavo account when you are ready to fund a key.

Still comparing routes rather than clients? OpenAI-compatible API covers what the chat wire does and does not guarantee, and LLM gateway covers the one-key, one-balance trade-off in general.

FAQ

Repository state, releases, package registries, documentation and the generated provider catalog checked September 18, 2026; the OpenAI and Anthropic tool prices were read from their own pricing pages the same day. No ChatGPT subscription price is quoted because that page refused the fetch. Nothing here was runtime tested against any endpoint. Kunavo token rates come from the live catalog, and every dollar example on this page is illustrative token arithmetic rather than a measured task cost.