Open Interpreter Came Back as a Codex Fork That Wears a Different Face for Every Model

The relaunched Rust agent bets the thing holding open models back isn't the model, it's the harness wrapped around it. Here's how that bet works and where it gets thin.

Open Interpreter shipped a /harness command, and switching it changes what the agent is. Type the command and you get a menu: native, claude-code, kimi-cli, qwen-code, deepseek-tui, swe-agent, minimal. Each one reshapes how the agent talks to the model underneath it. The pitch buried in that menu is unusual and worth stopping on. Most coding agents flatten every model into one house interface and let the smart ones cope. Open Interpreter's relaunch argues that flattening is exactly why open models underperform, and that the fix is to hand each model a harness shaped like the one it was trained to expect.

The project is back, rewritten in Rust, and openly a fork. The README states it plainly: "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." The original Python project, the one that hit tens of thousands of stars a couple of years ago, is gone from the main line and lives on as a community fork. What sits at the repo now is a different animal with the same name.

Why the harness is the whole argument

Start with the claim, because if you don't buy it, none of the design makes sense. The claim is that a capable open model like DeepSeek, Kimi, Qwen, or GLM often fails not because it can't reason about your code, but because the scaffolding around it is wrong for how it was trained.

A harness is everything between you and the raw model: how tools are described, how results come back, how the system prompt is framed, how the agent loop decides what to do next. Models pick up habits from the harness they were trained and evaluated against. Point Kimi at a generic tool interface it has never seen and it fumbles calls it would nail inside Kimi CLI. The model didn't get dumber. It got handed a steering wheel where it expected pedals.

Open Interpreter's answer is to stop pretending one harness fits all. It ships model-specific harnesses and lets you switch them from the terminal, so the agent loop is shaped around what each model is actually good at instead of forced through a single generic surface. That is a real position, and it runs against the grain of where the tooling world has been heading, which is one universal agent that treats the model as a swappable part. This project treats the model and its harness as a matched pair.

If the bet is right, it reframes a cost argument a lot of teams are having. The reason people reach for GPT-5.6 or Opus on coding work is often not raw intelligence, it is that the expensive models behave reliably inside whatever harness you already run. If a right-shaped harness closes even part of that reliability gap, then a DeepSeek or GLM run at a fraction of the token price stops being a downgrade you tolerate and starts being a default you choose. The savings were always theoretically there. The harness is the part that was eating them.

What you actually get

The mechanism is more concrete than the pitch, which is a good sign. This is not a wrapper that renames things.

The harness modes shape requests differently for Claude Code, Kimi CLI, Qwen Code, DeepSeek TUI, SWE-agent, or a stripped minimal chat-and-tools surface. You inspect or switch them live with /harness, and you switch models independently with /model. Providers include the ones you'd expect for open work: DeepSeek, Moonshot for Kimi, Z.ai for GLM, Alibaba for Qwen, plus Groq, OpenRouter, and Anthropic when you want a frontier model in the same tool.

The agent edits files and runs commands inside OS-level sandboxing on macOS, Linux, and Windows, which matters more this month than it would have six months ago, for reasons I'll get to. Config and session state stay local under ~/.openinterpreter. It supports exec for scripting, MCP servers, skills, hooks, permissions, and AGENTS.md, so it slots into the same conventions the rest of the agent ecosystem settled on. There's also a QA skill that lets any model drive a real browser or operate native apps to test interfaces, and it can run as an Agent Client Protocol agent so editors can talk to it directly.

The license is Apache-2.0. As of this writing the repo shows roughly 64,000 stars and 5,600 forks, though a large share of that count is inherited history and reputation from the original Python project, not a verdict on the Rust rewrite, which is new. Treat the star number as name recognition, not a quality signal for the code that's actually there now.

Put this into practice

The lowest-friction path is genuinely low. You can have it running against a cheap model in about ten minutes.

1. Install it. On macOS or Linux, curl -fsSL https://www.openinterpreter.com/install | sh. On Windows, irm https://www.openinterpreter.com/install.ps1 | iex. As always with a curl-to-shell installer, read what you're piping before you run it; this is the same trust decision as any install script, not a special exemption.

2. Start a session by typing i or interpreter in your terminal.

3. Pick a cheap model first with /model and point it at a provider you already have a key for. DeepSeek or a GLM endpoint through Z.ai is a fair starting place if you want to feel the cost difference against a frontier model.

4. Match the harness to the model with /harness. This is the step that makes or breaks the whole premise, so don't skip it or leave it on native by reflex. Running DeepSeek, try the deepseek-tui harness. Running Kimi, try kimi-cli. Then run the same real task twice, once on a mismatched harness and once on the matched one, and watch whether tool calls and edits get cleaner. That A/B is the fastest way to judge whether the project's core claim holds for your work.

5. Turn on the sandbox and permissions before you let it touch anything you care about. It ships with OS-level sandboxing and a permissions system. Use them from the first session, not after the first accident.

The honest test for this section: run one real task, on one open model, with the harness matched, and see if the output is something you'd actually keep. If the answer is yes at a tenth of the token cost, you've learned something worth the ten minutes.

Honest limitations

Lightweight is the selling word, and it cuts both ways. A lean agent optimized for cheap models is also an agent with fewer guardrails, less orchestration, and less of the accumulated safety scaffolding that heavier tools like Codex and Claude Code have been bolting on all spring. That tradeoff lands at an awkward moment. This is the same month the industry is relearning, through a run of agent RCE bugs and prompt-injection disclosures, exactly why harness guardrails exist. A tool whose pitch is "less harness, more model" is swimming against that current, and the OS sandbox is doing a lot of the load-bearing work. Turn it off and you've removed the main thing standing between a confused open model and your filesystem.

The Rust rewrite is new, and "new" means the fork's real behavior is unproven at the scale the star count implies. The reputation is inherited from a Python project that no longer drives the main line. Judge the current code on your own runs, not on the history in the counter.

The central claim is also, so far, the project's own. That a matched harness meaningfully lifts open-model performance is plausible and matches how these models were trained, but I have not seen an independent benchmark quantifying the lift per harness. The design is a strong hypothesis with a clean way to test it, which is better than most, but until someone runs the numbers across models and tasks, "the harness closes the gap" is a bet you're validating on your own machine, not a settled result.

And the harness menu has a ceiling. Emulating Kimi CLI or Qwen Code is only as good as the emulation, and a harness that mimics another tool will drift from that tool as the original evolves. You're trusting Open Interpreter to keep six moving targets in sync, and the ones that fall behind will underperform the real thing they're imitating.

Where this leaves you

The interesting thing about Open Interpreter's relaunch is not that it's another terminal agent. It's the specific claim it's willing to stake its whole design on: that we've been blaming open models for failures that belong to the scaffolding around them. If that's right, a lot of the "open models aren't ready for real agent work" consensus is measuring the harness, not the model, and the cheap-inference future arrives sooner than the benchmark leaderboards suggest.

You can test that claim yourself this week, on your own code, for the price of ten minutes and a few cents of tokens. Run a task you actually care about on a cheap model, once with the wrong harness and once with the right one. If the matched harness turns a model you'd written off into one you'd ship, the project just proved its point on your machine. If it doesn't, you've learned that for your work the model was the bottleneck after all. Either answer is worth more than another argument about it.

Sources: openinterpreter/openinterpreter README (GitHub); Open Interpreter project site; Trendshift repository page.