Open Interpreter: a Rust coding agent that borrows other agents' harnesses

What Open Interpreter solves for low-cost model users

The README describes Open Interpreter as "a coding agent optimized for low-cost models," and the note at the top is more specific: the project reimplemented the provider-recommended Kimi Code harness in Rust to get what it calls maximum K3 performance behind a Codex-like interface. That framing matters. Most terminal coding agents assume you are paying frontier prices and can afford long, chatty loops. When the model is cheap, the harness around it becomes the thing that decides whether output is usable, because a weak scaffold wastes tokens on retries and malformed tool calls.

The audience is therefore narrower than the phrase "coding agent" suggests. It is for engineers who have already picked a low-cost provider (Kimi, DeepSeek, Z.AI/GLM are the three provider guides linked from the README) and who want the agent layer to adapt to that provider rather than the other way round. If you are on a frontier model and happy with your current tool, the harness-switching feature has little to offer you.

Harness emulation and the Codex lineage

Open Interpreter is a fork of OpenAI's Codex, and the repository layout confirms it: the top level still carries codex-rs, codex-cli, a Bazel build, and a package.json named codex-monorepo whose description reads "Tools for repo-wide maintenance." The Rust rewrite lives under codex-rs, and the justfile sets its working directory there, with recipes such as `just codex` and `just exec` that run `cargo run --bin codex`.

The distinctive mechanism is harness emulation. Typing `/harness` in the TUI opens a list: native, claude-code, claude-code-bare, zcode, kimi-code, kimi-cli, qwen-code, deepseek-tui, swe-agent, minimal. Each entry is a Rust-native emulation of the tool loop that a given provider or model family was tuned against. The claim is that a model trained or prompted for a particular harness performs better when the surrounding agent behaves the way that harness behaves.

That is a real design bet, and it cuts both ways. It means the project must track other people's agent conventions, which move. The README points to a harness documentation page rather than describing the internals, so how faithfully each emulation reproduces its target is not something the repository front page establishes.

Installing Open Interpreter and starting a session

The installation path is a shell one-liner. On macOS and Linux the README gives this command, which fetches and runs the install script from the project's own domain:

curl -fsSL https://www.openinterpreter.com/install | sh

Windows uses the PowerShell equivalent:

irm https://www.openinterpreter.com/install.ps1 | iex

After either script finishes, the README says to type `i` or `interpreter` in your terminal to start a session. Those two names are the entry points; the README does not document a package-manager install for either platform.

Once inside the TUI, the first thing worth doing is picking a provider and model. The README lists `/model` for that, and `/harness` for switching the active harness. The harness menu is a plain text list, so a session looks like this:

> /harness

native
claude-code
claude-code-bare
zcode
kimi-code
kimi-cli
qwen-code
deepseek-tui
swe-agent
minimal

Choosing kimi-code is the path the README's opening note recommends for K3. There is no separate Kimi binary to install; the harness is Rust code inside the same tool.

Portability: AGENTS.md, .agents/skills and the storage boundary

The most opinionated part of the README is the portability section, and it is worth reading before you install anything. The stated product goal is that Open Interpreter "should fit into your existing agent setup instead of trapping it in an Open Interpreter-only format." Concretely, that means the agent reads repository `AGENTS.md` files and shared `.agents/skills` directories, and speaks MCP, ACP and the Codex exec protocol.

Product-specific storage is confined to `~/.openinterpreter`, and the README is explicit that this is "reserved for configuration and runtime state that does not yet have a practical shared standard." Legacy product-specific skill directories remain readable, but new skills are supposed to go in `.agents/skills` or `~/.agents/skills`. If you have been burned by agents that keep skills in a private directory you cannot reuse, this is the design decision to evaluate first: it is a commitment about where your data lives, and the portability guide is the document that defines the current boundary.

The Codex compatibility claim is similarly concrete. The README shows a one-line override for anyone already using OpenAI's Codex SDK:

-const codex = new Codex();
+const codex = new Codex({ codexPathOverride: "interpreter" });

The README states that Open Interpreter speaks the same Codex exec protocol, and points to `scripts/test-codex-sdk-compat.sh` as a local, provider-free compatibility check. That script is the honest way to verify the claim without spending on API calls.

Where Open Interpreter is the wrong tool

The installation method is the first limitation. Both install commands pipe a remote script straight into a shell, and the README offers no checksum, signature or pinned-version alternative. For a tool that then runs commands on your machine, that is a supply-chain decision you are making on every install. The README also does not document rollback or an uninstall path, so removing the tool is not covered by the front page.

The second limitation is release maturity. The recent tags are rust-v0.0.38, rust-v0.0.39 and rust-v0.0.40, published on 2026-08-15, 2026-08-17 and 2026-08-20. Three patch releases in five days is a fast-moving pre-1.0 line, not a frozen API. The last push to the repository was on 2026-08-20, so the project is not archived, but the version numbering tells you to expect churn in flags and config keys.

The third is scope. There is no desktop application in the README. Search interest in an "open interpreter desktop app" exists, but the front page describes a terminal agent, an ACP server mode, and an SDK-compatible binary. If you need a GUI, this is not it. And if you need a harness that is guaranteed to match a specific upstream tool byte for byte, the README does not make that promise; it lists emulations without documenting their fidelity.

How it differs from OpenCode and Claude Code

The comparison people actually search for is Open Interpreter versus OpenCode, and the difference is architectural rather than cosmetic. OpenCode is its own agent; Open Interpreter is a fork of Codex with a harness layer bolted on top, so its identity is partly borrowed. That shows up in the repository: the monorepo still carries codex-rs, codex-cli and a Codex exec protocol implementation, and the SDK override above exists precisely because the binary is drop-in compatible.

Against Claude Code, the split is about which model you are paying for. Claude Code is built around Anthropic's models. Open Interpreter's entire premise is the opposite end of the market: the README's headline note is about Kimi K3, and the provider guides cover DeepSeek and Z.AI/GLM alongside it. If your budget assumes a low-cost model, the harness emulation is the feature that justifies looking here; if you are on Claude, the emulation of claude-code and claude-code-bare harnesses is the interesting part, but the README does not claim it reproduces Claude Code's behaviour exactly.

Aider and Goose sit in the same terminal-agent space and are not discussed in the project's documentation at all, so any comparison with them would be guesswork. The honest position is that Open Interpreter's differentiator is the harness list plus the Codex protocol compatibility, and both are documented as claims with linked guides rather than as benchmarks.

Maintenance, licence and upgrade cost

The licence is Apache-2.0, with a LICENSE file and a NOTICE file at the repository root. Apache-2.0 is permissive and includes an explicit patent grant, which matters if you intend to redistribute a branded build; the repository also ships FORK_BRANDING.md, which suggests forking and rebranding is an anticipated use. None of this is legal advice, and the NOTICE file is the one to read if you redistribute.

On upgrade cost, two mechanisms reduce it. Providers and models are generated rather than hand-maintained: the README says provider and model membership is "generated, not maintained as Rust lists," and that from `codex-rs` you refresh all hosted providers with `python3 scripts/write_provider_catalog.py`, or repeat `--provider <provider-id>` to update selected entries. Live model sources need the provider credentials documented in the provider docs. That means adding a model is a regeneration step, not a code change.

The second is the shared-file policy. Because skills and instructions live in `AGENTS.md` and `.agents/skills`, upgrading the binary does not strand your configuration in a format only this tool reads. The counterweight is the release cadence: three patch tags in five days around 2026-08-20 means you should read RELEASE_NOTES.md and CHANGELOG.md before bumping, particularly if you depend on a specific harness.

Editorial conclusion

Adopt Open Interpreter if you already run Kimi K3, DeepSeek, GLM or another low-cost model and want a Codex-shaped terminal agent that keeps your AGENTS.md and .agents/skills files readable by other tools. Skip it if you need a stable packaged release, a desktop application, or a guarantee that every harness listed by /harness is equally polished; the README names the harnesses but does not document how closely each one tracks its upstream. Before committing, run interpreter acp against your editor, check that your provider appears in the generated catalog, and confirm the sandbox behaviour on your platform.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes