openinterpreter

The Problem

Developers using low‑cost LLMs (e.g., Kimi K3) need a locally runnable “coding agent” that mimics the OpenAI Codex harness while staying compatible with existing ACP/ACP‑compatible editors. The lack of a performant, open‑source bridge forces teams to either write ad‑hoc wrappers or rely on proprietary services.

What This Does

Open Interpreter supplies a Rust‑backed provider harness (codex-rs/) that talks the same exec protocol as Codex, exposing a CLI (scripts/codex_package/cli.py) and a Python SDK (sdk/python/). The Rust implementation (codex-rs/acp-server/src/lib.rs, codex-rs/agent‑graph‑store/src/lib.rs) delivers the heavy‑weight model I/O, while the SDK wraps it in idiomatic Python classes (sdk/python/src/openai_codex/client.py, async_client.py).

Skill bundles live under .codex/skills/ (e.g., babysit-pr, codex‑issue‑digest) and are invoked through the /harness command. The repository also ships a Docker devcontainer (.devcontainer/Dockerfile) and CI pipelines that build and test the Rust crates and Python package.

How It Is Wired

Execution begins at scripts/codex_package/cli.py:152 (main). The call graph shows:

• main → add (58×) and main → run_sbx (48×) – the latter spawns a subprocess (subprocess.run) that launches the Rust binary (interpreter).
• main → parse_args (24×) builds a CliArgs struct used by run_sbx.
• run_sbx eventually calls into codex-rs/acp-server which starts AppServerHarness (called from 33 places) and processes inbound /turn requests.

The most‑central hub functions are thread_start (37 callers), Codex (34 callers), and AppServerHarness (33 callers). Changing any of these propagates widely across the codebase.

External effects are concentrated in a few paths:

• Subprocess launch – main → run_sbx → Rust binary (interpreter).
• Network I/O – handler in scripts/mock_responses_websocket_server.py → send_event (WebSocket).
• File system – 154 functions read/write files; e.g., sdk/python/scripts/update_sdk_artifacts.py writes generated SDK artifacts.
• Crypto – 7 functions handle PEM certificates (codex-rs/http-client/tests/fixtures/*.pem).
• Model inference – a single function in the Rust crate calls the Kimi K3 backend.

Responsibility highlights (sorted by routing weight):

The internal call graph contains 1 993 resolved edges; cycles are limited to the harness bootstrap (e.g., thread_start ↔ Codex), meaning most changes stay localized unless they touch these hubs.

How To Use It

# Clone the repo
git clone https://github.com/moses-y/openinterpreter
cd openinterpreter

# Build the Rust interpreter (requires cargo)
cargo build --release -p interpreter   # defined in codex-rs/Cargo.toml

# Install the Python SDK in editable mode
pip install -e sdk/python

# Run the CLI (entry point)
python scripts/codex_package/cli.py   # starts the interpreter subprocess

Configuration files:

• codex-rs/Cargo.toml – selects the Kimi K3 provider (kimi-code harness).
• sdk/python/src/openai_codex/client.py – reads ~/.openinterpreter/config.toml for API keys.
• .devcontainer/Dockerfile – optional container with all build tools.

To switch harnesses at runtime, type /harness in the interactive session and choose kimi-code (the default for K3).

Real‑World Use

A CI system can invoke the CLI inside a Docker step to generate code patches:

python scripts/codex_package/cli.py <<'EOF'
/harness kimi-code
def add(a, b): return a + b
/add 2 3
EOF

The output is a diff that can be applied automatically, letting low‑cost models produce production‑ready changes without leaving the repository.

Code Health & Issues

• High – continue-on-error in .github/workflows/cargo-ci.yml masks test failures.
• Medium – No explicit permissions for GITHUB_TOKEN (potential over‑privilege).
• Medium – Dockerfile base image (ubuntu:24.04) not pinned by digest.
• Medium – No dependency‑vulnerability scan in CI.
• Medium – checkout step keeps credentials; missing persist-credentials: false.
• Low – No timeout-minutes on CI jobs (risk of hung runs).

Additional observations: PEM fixtures in codex-rs/http-client/tests/fixtures/ indicate committed secrets; the repo includes a license (Apache‑2.0) and lockfiles (Cargo.lock, pnpm-lock.yaml). Tests exist (1 799 files) and CI runs on GitHub Actions.

The Bottom Line

Open Interpreter delivers a functional, Rust‑backed bridge for low‑cost LLMs with a usable Python SDK and a clear exec protocol. It is modular but hinges on a few high‑traffic hub functions, so changes to those require careful impact analysis. The codebase is test‑rich but suffers from CI hygiene issues (masked failures, missing permission scoping). Teams comfortable with Rust and Python can adopt it quickly, provided they address the identified CI and secret‑handling concerns.