dalao.ai

Open Interpreter

A terminal coding agent for open models like Kimi K3 and GLM 5.3Open source

About Open Interpreter

Open Interpreter is now a terminal coding agent; its GitHub description reads "A coding agent for open models like Kimi K3 and GLM 5.3". It's a fork of OpenAI's Codex CLI that focuses on emulating the harness each model provider recommends, while keeping Codex's OS-level sandbox. The name comes from the Python project that took off in 2023, but main was rebuilt on Codex in July 2026 and the license moved to Apache-2.0. As of 2026-10-26 the latest release is 0.0.56; the agent is free, and model costs fall on the user's own accounts or local models.

EditorialUpdated 11 min read

What it is

Open Interpreter is a command-line coding agent. Typing interpreter, or just i, inside a project opens a chat session that reads the project files, proposes changes, edits code, runs commands and reviews diffs; interpreter resume --last resumes the session later. The quickstart calls it "a terminal coding agent built from the Codex CLI surface and adapted for provider-agnostic local use." The README opens with "A coding agent optimized for low-cost models," and the GitHub description targets open models such as Kimi K3 and GLM 5.3. Both lines are the vendor's own framing.

Under the hood it's a fork of OpenAI Codex. In the README's words, "Open Interpreter is a fork of OpenAI's Codex, with a focus on emulating the agent harness that gets the best performance out of low-cost models." FORK_BRANDING.md explains that internal crates, protocol fields and file names such as codex-package.json stay as Codex has them; product and command names are swapped in one central branding module. The NOTICE file still opens with "OpenAI Codex, Copyright 2025 OpenAI". GitHub's language breakdown (as of 2026-10-26) shows roughly 69.6 MB of Rust against 1.78 MB of Python.

What it adds to stock Codex falls into three buckets. Harness emulation: /harness switches among native, claude-code, claude-code-bare, zcode, kimi-code, kimi-cli, qwen-code, deepseek-tui, swe-agent and minimal, each shaping prompts, tool definitions and messages after the agent it imitates. A script-generated provider catalog: OpenAI, Amazon Bedrock, Ollama and LM Studio are built-in runtime providers, while hosted services such as Kimi, DeepSeek, Z.AI and Zhipu AI, and Google AI Studio come from the generated catalog. And Agent Client Protocol support: point an ACP-capable editor at interpreter acp and it becomes the editor's agent.

The same company, Open Interpreter Inc., also ships Interpreter, a desktop app for non-developers (open-source repo: interpreter-workstation). The blog says it runs on the new Open Interpreter runtime and can work in the browser, Office documents and other local apps. The terminal agent and the desktop app are separate products.

On the name: the 2023 tool that let a model write and run Python on the local machine has been handed to the community fork endolith/open-interpreter, per the README; that repo is still AGPL-3.0 and, as of 2026-10-26, was last pushed on October 25. The old open-interpreter package on PyPI is still at 0.4.3 (uploaded 2024-10-26); the new agent installs from a script on the official site, not from PyPI.

A coding agent optimized for low-cost models.

Open Interpreter README, opening line

What stands out

A harness per model. The launch post argues that every coding model is trained against a particular set of tool names, arguments, system prompts and compaction habits, and that forcing them all through one generic harness costs performance, so Open Interpreter reproduces the setup each provider recommends. Its evidence comes from the 89 tasks of Terminal-Bench 2.1: Kimi-K2.5 solved 50 in Open Interpreter versus 39 in OpenCode 1.15.7, and DeepSeek V4 Flash solved 53 versus 42 (as reported by the vendor, which ran the tests itself). When no harness is set, the docs say it infers one: kimi-code for Kimi and Moonshot, qwen-code for Qwen, claude-code for Anthropic and Claude models, claude-code-bare for DeepSeek. Tool calls still run in Open Interpreter's own Rust runtime; it never shells out to the real Kimi Code or Claude Code binaries.

Native sandboxing with approvals. Inherited from Codex, safety comes in two layers. Sandbox mode sets the technical boundary (read-only, workspace-write, or danger-full-access; workspace-write keeps network off unless it is enabled). Approval policy decides when it stops to ask (untrusted, on-request, or never). Enforcement uses Seatbelt on macOS, Bubblewrap and seccomp on Linux and WSL, and native sandboxing on Windows, and the docs say it should fail closed when a policy can't be enforced. The blog positions this as the main gap between it and other agents built for open models.

The Codex ecosystem, unchanged. It speaks the same Codex exec protocol; the README's example is a one-line codexPathOverride: "interpreter" for apps already on the Codex SDK. exec, MCP, skills, hooks, permissions and AGENTS.md behave as they do in Codex. "Portable by default" is a stated goal: project instructions in AGENTS.md, skills in shared .agents/skills directories, and only state with no shared standard yet under ~/.openinterpreter.

Any provider. /model swaps provider and model; any OpenAI-compatible service works through --chat-completions. The Kimi K3 guide covers both a Kimi Code subscription with browser sign-in and a Moonshot Platform API key. The Z.AI guide separates the global Z.AI service from Zhipu AI's China service and adds a zcode harness modeled on GLM coding workflows.

Built-in UI testing. A bundled QA skill can drive web apps in a real browser via agent-browser, or operate native apps via trycua.

Who it’s for

Good fit

Developers already on Codex who want to hand some work to cheaper models such as Kimi, DeepSeek, Qwen or GLM without giving up their AGENTS.md, skills and MCP setup. That migration is the headline use case in both the README and the blog.

Teams running codex exec in CI that want to choose a provider per job. The sandbox guide suggests workspace-write plus a never approval policy on an isolated runner.

Anyone who wants a sandboxed agent inside an ACP editor such as Zed, a JetBrains IDE or VS Code, and people curious how much the harness alone changes a model's results.

Terminal-first users who are happy to manage their own API keys and provider bills, and who can live with 0.0.x version numbers.

Not a fit

Anyone looking for the 2023 Python tool they could import interpreter from. The new agent is a Rust terminal program with no code carried over.

People who mostly work with documents and spreadsheets rather than code; the company's Interpreter desktop app is aimed at them.

Production integrations that need a stable interface. The project keeps merging upstream Codex changes, so flags and config can move. For GPT-only use, stock Codex removes one layer.

How it compares

The comparisons with Codex, Claude Code and OpenCode come from Open Interpreter's own README, docs and blog, as reported by the vendor.

Versus Codex CLI. Codex is the upstream project and is also Apache-2.0. The blog says Codex was built for GPT; Open Interpreter keeps its mature terminal UI, app-server protocol and cross-platform sandbox and makes multiple providers and harness emulation first-class. New upstream features arrive in Open Interpreter only once they're merged.

Versus Claude Code. The blog groups Claude Code with agents "built around one model". Open Interpreter's claude-code harness imitates its request shape and tool surface and, per the harness docs, can run over Anthropic Messages, Responses or Chat transports. It is not Anthropic's official client.

Versus OpenCode. The blog calls OpenCode "a popular coding agent with a generic harness" and uses it as the baseline for the blog's Terminal-Bench numbers, with Open Interpreter running the tests. It also argues that the most popular agents for open models had no built-in sandboxing, leaving developers to babysit permission prompts, work on isolated machines or reach for Docker.

Versus each lab's own agent. Kimi Code, Qwen Code and DeepSeek TUI are what the providers recommend; Open Interpreter recreates their harnesses in one interface, and the Kimi K3 guide says the Kimi Code CLI isn't required.

The three are positioned differently: Codex is built around GPT, Claude Code is Anthropic's official client, and Open Interpreter keeps the Codex terminal UI while connecting to models from many providers.

Getting started

Install. On macOS and Linux run curl -fsSL https://www.openinterpreter.com/install | sh; on Windows run irm https://www.openinterpreter.com/install.ps1 | iex in PowerShell. Restart the shell and confirm with interpreter --version. Per the install guide, Linux builds use musl, WSL works for Linux-style workflows, and Git is recommended. interpreter update upgrades in place, and the uninstall steps keep the config, sessions, logs and credentials under ~/.openinterpreter.

Providers and sign-in. The first run walks users through sign-in: a ChatGPT account, an API key, a local model through Ollama or LM Studio, or another compatible service. The auth guide recommends API keys such as OPENAI_API_KEY or ANTHROPIC_API_KEY for CI and headless machines; with Ollama running locally, interpreter --oss keeps model traffic on the machine. Credentials go to the system keyring or ~/.openinterpreter/auth.json, and the docs say to treat that file like a password.

First session. In the project directory, type i and ask for something concrete, say "add a /health endpoint that returns the build sha". It reads the project, proposes work, edits files and runs commands within the configured sandbox and approval settings. Handy commands: /model, /harness, /permissions, /review, and interpreter exec for one-off runs.

Permission levels. The sandbox guide suggests read-only plus on-request for unfamiliar code and workspace-write plus on-request for trusted repos. Per the same guide, --yolo removes both approval prompts and the sandbox and belongs only inside an external sandbox such as a throwaway VM or isolated container.

Coming from Codex. Existing AGENTS.md files and .agents/skills directories carry over; point the Codex SDK at interpreter; in CI, swap codex exec for interpreter exec and set model_provider and harness with -c.

/harness switches harnesses inside a session, and providers and models are configured separately, so different model and harness pairings can be compared on the same repo.

Pricing and license

The terminal agent costs nothing and is released under Apache-2.0; the spend is on models. With the user's own API key, the provider bills directly; signing in with ChatGPT draws on the user's ChatGPT plan; running locally carries no API fees. The Z.AI guide notes that GLM Coding Plan quota is used only with the matching Coding Plan provider; the general endpoint doesn't draw on it.

For the Interpreter desktop app, the blog says "try Interpreter for free" and asks enterprises to get in touch. Its privacy policy says hosted-model requests go through Open Interpreter's servers, with full requests and responses logged for up to 30 days and then deleted; with the user's own API key, content goes straight from the device to the provider.

The license history has two chapters. The old Python repo started under MIT with commit 31d4ffb (2023-07-14) and switched to AGPL-3.0 in commit 57f5695 (2023-11-30). The LICENSE on main today comes from Codex's initial commit 59a180d (2025-04-17) and became Open Interpreter's license when main was rebuilt on Codex rust-v0.144.4 on July 16, 2026 (commit e764363). NOTICE keeps OpenAI's copyright line and an MIT notice for code derived from Ratatui.

Apache-2.0 permits commercial use and closed redistribution; the license requires redistributions to keep the NOTICE attributions.

Caveats

Name and history. As of 2026-10-26 the repo shows 68,670 stars and 5,909 forks; those, along with the issue numbers, carry over from the 2023 Python project. The code is a fresh Rust fork. Many older tutorials describing a model that runs Python on the local machine are about the old version.

Contributors. GitHub's contributors API (as of 2026-10-26) lists 473 accounts; main was rebuilt on Codex, and the project's own work sits in the harnesses, the provider catalog and the branding layer.

Updates. According to the GitHub API, the latest commit on main landed on October 11, validating Codex 0.159 model-compatibility settings. The newest release, 0.0.56, shipped on 2026-10-07 11:42 (UTC+8) with GPT-6.1 Sol metadata and a refreshed provider catalog. As of 2026-10-26 there are 15 open issues and 8 open pull requests.

Benchmarks are vendor-run. Open Interpreter ran the Terminal-Bench comparison itself. The blog text says it measured DeepSeek V4 Flash, and the charts also give Kimi-K2.5 results.

Harness pairings are strict. The harness docs say a provider's wire_api must match the harness, for example zcode needs an Anthropic Messages endpoint. The Z.AI troubleshooting notes point to checking that the active provider uses wire_api = "messages" when /harness shows zcode but the behavior looks generic; the docs also advise keeping provider, model and harness separate when debugging.

Safety settings. --yolo or danger-full-access remove the local sandbox boundary, and file-based credential storage leaves a plain-text secret in auth.json.

How it started

Open Interpreter's repo was created on 2023-07-14, with its first commit the same day under the MIT license. It let a language model write and run code on the local machine. GitHub releases began on 2023-08-11 and 0.1.0 shipped on 2023-09-05; on 2023-11-30 commit 57f5695 moved the license to AGPL-3.0. The Python line continued through 0.2.0 (2024-01-05), 0.3.0 (2024-06-18) and 0.4.0 (2024-10-24), and the final PyPI release, 0.4.3, was uploaded on 2024-10-26.

The other thread starts at OpenAI: Codex CLI's initial commit, dated 2025-04-17, carried an Apache-2.0 license, and the Open Interpreter team chose it as a base. The first rust-v tag, 0.0.16, appeared on 2026-06-20. On 2026-07-16 00:35 (UTC+8), commit e764363 rebuilt main on Codex rust-v0.144.4 with a one-line message: "Rebase Open Interpreter onto Codex 0.144.4". The old Python versions are now all marked as pre-releases.

The launch post, "Introducing Open Interpreter", went up on 2026-07-13. It opens with "AI has an economics problem" and promises "the open application layer that treats open-weight models as first-class citizens" (the vendor's own words), announcing a brand-new Open Interpreter under Apache-2.0. Releases since then have mostly widened model coverage: GLM-5.3 entries in 0.0.44, new DeepSeek choices in 0.0.45, GPT-6.1 Sol in 0.0.56. The banner at the top of the README now announces native Kimi K3 support.

Our verdict

What sets Open Interpreter apart: it is built on Codex, keeping its terminal UI, exec protocol, AGENTS.md conventions and OS-level sandbox, while connecting to models from Kimi, DeepSeek, GLM, Qwen and other providers and switching harnesses per model; it is released under Apache-2.0 and the terminal agent is free.

Its limits: the project's own work sits in the harnesses, the provider catalog and branding, and it keeps merging upstream Codex changes, so flags and config can move; versions are still 0.0.x; the only performance comparison is the vendor's own test; and the stars and issue numbers carry over from the 2023 Python project.

The old Python version isn't in this repo; the community fork endolith/open-interpreter maintains it.

Why it stands out

Open Interpreter is a terminal program that turns plain-language requests into code it runs on your machine. Before agents were a category, Killian Lucas had a terminal that could resize a folder of images, edit a spreadsheet, or control a browser from one sentence.

The design decision that aged well was insisting on local execution. Your files never leave your computer; only the plan does.

It lets a model write and run code on your own machine in a loop while you watch, and execution stays local: your files never leave your computer.

Sources

Official

  1. openinterpreter/openinterpreter on GitHubGitHub · Accessed Oct 26, 2026
  2. Open Interpreter READMEGitHub · Accessed Oct 26, 2026
  3. Open Interpreter LICENSE (Apache-2.0)GitHub · Accessed Oct 26, 2026
  4. Open Interpreter NOTICE fileGitHub · Accessed Oct 26, 2026
  5. Open Interpreter: Branding a Distribution ForkGitHub · Accessed Oct 26, 2026
  6. LICENSE history on mainGitHub · Accessed Oct 26, 2026
  7. Commit 59a180d: Codex initial commitGitHub · Accessed Oct 26, 2026
  8. Commit 31d4ffb: Open Interpreter initial commitGitHub · Accessed Oct 26, 2026

Updates & reading