Skip to content

Github · GitHub Repository Radar

openinterpreter openinterpreter

A coding agent for open models like Kimi K3

Stars

68,229

Popular Active

Forks

5,872

Watchers: 68,229

Language

Rust

License: Apache License 2.0

Repository Radar Score

60 / 100

Growth

7d
+0
30d
+0
%
0.0%

Not enough metric snapshots yet to chart growth for this repository.

Score breakdown

  • popularity 88
  • growth 0
  • activity 75
  • freshness 100
  • community 86

Need help integrating this stack?

Our team builds with modern open-source stacks. Tell us what you are shipping.

Get a quote →

Open Interpreter

A coding agent optimized for low-cost models. Blog post ↗

EnglishEspañol简体中文

Note

Today: Kimi K3 is here. We have reimplemented the provider-recommended Kimi Code harness in Rust, giving you maximum K3 performance with a Codex-like interface. Kimi Docs →


Open Interpreter running in a terminal

Installation

macOS and Linux:

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

Windows:

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

Then type i or interpreter in your terminal to start a session.

Harness Emulation

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.

Use /harness to switch the active harness:

> /harness

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

Read more in the harness docs and provider setup guides.

ACP compatible, Codex compatible

Open Interpreter works in ACP-compatible editors and clients. Configure the client to launch interpreter acp; see the ACP guide for examples.

Already building with OpenAI's Codex SDK? Keep the SDK and make a one-line binary override:

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

Open Interpreter speaks the same Codex exec protocol. See the SDK guide and run scripts/test-codex-sdk-compat.sh for a local, provider-free compatibility check.

Portable by default

Open Interpreter should fit into your existing agent setup instead of trapping it in an Open Interpreter-only format. The product goal is to prefer shared, tool-neutral standards and directories, keep user-authored data in readable files, and make moving to or from another compatible agent straightforward.

Today that includes repository AGENTS.md, shared .agents/skills directories, MCP, ACP, and the Codex exec protocol. Product-specific storage under ~/.openinterpreter is reserved for configuration and runtime state that does not yet have a practical shared standard. Legacy product-specific skill directories remain readable for compatibility, but new skills belong in .agents/skills or ~/.agents/skills.

See the portability guide for the current boundary and the rules for evolving it.

Computer Use

Open Interpreter ships with a QA skill that lets any model operate and test interfaces. It can drive web apps in a real browser with agent-browser, or operate and test native apps with trycua.

Features

  • Runs commands inside native sandboxing on macOS, Linux, and Windows.
  • Switches providers and models from the TUI with /model.
  • Inspects or switches Rust-native model harnesses with /harness.
  • Tests web and native apps through the built-in QA skill.
  • Runs as an Agent Client Protocol agent for editors with interpreter acp.
  • Reuses shared AGENTS.md instructions and .agents/skills directories.
  • Keeps product-only config and session state local under ~/.openinterpreter.
  • Supports exec, MCP, skills, hooks, permissions, and AGENTS.md.

Documentation

Provider and model membership is generated, not maintained as Rust lists. From codex-rs, refresh all hosted providers with python3 scripts/write_provider_catalog.py, or repeat --provider <provider-id> to update only selected provider entries. Live model sources require the provider credentials documented in the provider docs.

Note

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.

License

Apache-2.0

Created: Jul 14, 2023

Last push: Aug 20, 2026

Default branch: main

Latest release: rust-v0.0.40

Languages

Share of the codebase by language, based on repository metadata from the host.

  • Rust 96.3%
  • Python 2.8%
  • Starlark 0.2%
  • TypeScript 0.2%
  • Shell 0.2%
  • PowerShell 0.1%
  • JavaScript 0.1%
  • HTML 0.1%
  • CSS 0.0%
  • Jupyter Notebook 0.0%
  • Just 0.0%
  • Smarty 0.0%
  • MDX 0.0%
  • Nix 0.0%
  • Dockerfile 0.0%
  • C 0.0%

Repository Radar analysis

Deterministic insights derived from public metadata and our observations — not personal testing or reviews.

Why this repository is interesting

  • High absolute popularity (68,229 stars) signals broad adoption.

Who should use it

  • Developers working primarily with Rust
  • Teams exploring AI tooling, agents, or ML infrastructure

Potential use cases

  • Reference or evaluate Rust open-source approaches in this domain
  • Prototype AI/agent workflows or study reference architectures

Strengths

  • README present in our index
  • Declared license: Apache License 2.0
  • Substantial fork count (5,872) suggests reuse and contribution interest

Limitations / considerations

  • Insights are derived from public metadata and our observations — not a substitute for code review

What to watch

  • Re-check last push, issues, and releases on GitHub before production adoption

Strong signals: Strong community interest

Source: GitHub (public metadata) + Repository Radar analysis. We do not claim ownership of third-party repositories.

Ready to ship something that compounds?

Share your roadmap. We’ll come back with scope options, timeline ranges, and who from Shriram IT Ventures should be in the room.

Popular with product teams