Roadmap

August 6, 2026 · View on GitHub

Plan

This repository (endolith/open-interpreter) is the community-maintained home of OI Classic, the Python edition of Open Interpreter. The upstream openinterpreter/openinterpreter repo was rewritten as an unrelated Rust project, so OI Classic now evolves independently.

Work is organized in phases so that each step makes the next one more trustworthy.

Phase 1: CI and test foundation (in progress)

Automation so that pull requests can be reviewed and merged with confidence. Much of this is already in place on main:

Phase 2: Port features from `classic/develop` into `main`

classic/develop is the maintainer's daily driver: it contains most recent features and is what most users should install for now. Its features are scattered across one long linear history, so each one is ported to main as its own isolated PR. As features land, main gradually becomes the better (and eventually the recommended) install for everyone.

Ports are prioritized: proven daily-use features first, uncertain or shaky ones last.

Priority 1 — LLM API quality (definitely want):

reasoning_content streaming with cyan "Thinking" panels, plus include_reasoning / reasoning_effort and OpenRouter extra_body reasoning support
DeepSeek API support (--model deepseek/deepseek-v4-flash, DEEPSEEK_API_KEY, optional DEEPSEEK_API_BASE)
Split the ambiguous shell language into explicit bash and cmd languages, and clarify REPL semantics in the tool schema
OpenRouter support (--model openrouter/... with OPENROUTER_API_KEY)
DashScope / Qwen support with vision for Qwen 3.5 models
Mistral compatibility fixes (tool ID length, image role mapping)
API error handling: styled error panels, retry prompts, auto-retry on temporary provider errors, clean exits
%usage command with token statistics

Priority 2 — Proven daily tools:

view_image tool with approval flow (working well)
Web tools (web.search / web.answer / web.fetch) with multi-backend fallbacks and result classes (working well)

Priority 3 — General improvements:

Priority 4 — Uncertain, merge later:

File-edit tools (sed, gawk, jq, yq, comby, patch) with dry-run previews — works inconsistently
ai2 module for task delegation — rarely used, needs explicit prompting
computer → toolbox rename — breaking API change, uncertain benefit
Telemetry removal / opt-out — undecided
TextFileReader convenience class — unverified

Phase 3: Pythonic refactor

Once the develop features are in, refactor the codebase to be more Pythonic and better written in general. This must wait until after Phase 2, because classic/develop is based on the older, less Pythonic main code.

Phase 4: Mine the abandoned OI 1.0 rewrite (maybe)

The development branch (and its continuation develop_1.0) was meant to become Open Interpreter 1.0, but depends on Anthropic computer-use APIs that are now obsolete and was never feature-complete. After the earlier phases, consider cherry-picking any worthwhile ideas from it.

Documentation

Work with Mintlify to translate docs. How does Mintlify let us translate our documentation automatically? I know there's a way.
Better comments throughout the package (they're like docs for contributors)
Show how to replace interpreter.llm so you can use a custom llm

New features

Future-proofing

What's in our scope?

This repository (endolith/open-interpreter) is the Python edition of Open Interpreter. The upstream openinterpreter/openinterpreter repo is a separate Rust rewrite (default branch oix).

Branches

main — merge target; PRs and CI land here. Default branch and CI badge. As features are ported over from classic/develop (see the Plan), this becomes the recommended install for everyone.
classic/develop — the maintainer's daily driver and currently the best install for most users. Features are ported to main as isolated PRs, not merged wholesale (see the Plan Phase 2).
development — abandoned attempt at Open Interpreter 1.0 (see the Plan Phase 4); not maintained and not becoming main.
develop_1.0 — experimental continuation of development (the maintainer's work on it before it was abandoned); also abandoned.

Open Interpreter contains two projects which support each other, whose scopes are as follows:

core, which is dedicated to figuring out how to get LLMs to safely control a computer. Right now, this means creating a real-time code execution environment that language models can operate.
terminal_interface, a text-only way for users to direct the code-running LLM running inside core. This includes functions for connecting the core to various local and hosted LLMs (which the core itself should not know about).

What's not in our scope?

Our guiding philosophy is minimalism, so we have also decided to explicitly consider the following as out of scope:

Additional functions in core beyond running code.
More complex interactions with the LLM in terminal_interface beyond text (but file paths to more complex inputs, like images or video, can be included in that text).

This roadmap gets pretty rough from here. More like working notes.

Working Notes

* Roughly, how to build `computer.browser`:

First I think we should have a part, like computer.browser.ask(query) which just hits up perplexity for fast answers to questions.

Then we want these sorts of things:

browser.open(url)
browser.screenshot()
browser.click()

It should actually be based closely on Selenium. Copy their API so the LLM knows it.

Other than that, basically should be = to the computer module itself, at least the IO / keyboard and mouse parts.

However, for non vision models, browser.screenshot() can return the accessibility tree, not an image. And for browser.click(some text) we can use the HTML to find that text.

Here's how GPT suggests we implement the first steps of this:

Creating a Python script that automates the opening of Chrome with the necessary flags and then interacts with it to navigate to a URL and retrieve the accessibility tree involves a few steps. Here's a comprehensive approach:

Script to Launch Chrome with Remote Debugging:
- This script will start Chrome with the --remote-debugging-port=9222 flag.
- It will handle different platforms (Windows, macOS, Linux).
Python Script for Automation:
- This script uses pychrome to connect to the Chrome instance, navigate to a URL, and retrieve the accessibility tree.

Step 1: Launching Chrome with Remote Debugging

You'll need a script to launch Chrome. This script varies based on the operating system. Below is an example for Windows. You can adapt it for macOS or Linux by changing the path and command to start Chrome.

import subprocess
import sys
import os

def launch_chrome():
    chrome_path = "C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe"  # Update this path for your system
    url = "http://localhost:9222/json/version"
    subprocess.Popen([chrome_path, '--remote-debugging-port=9222'], shell=True)
    print("Chrome launched with remote debugging on port 9222.")

if __name__ == "__main__":
    launch_chrome()

Step 2: Python Script to Navigate and Retrieve Accessibility Tree

Next, you'll use pychrome to connect to this Chrome instance. Ensure you've installed pychrome:

pip install pychrome

Here's the Python script:

import pychrome
import time

def get_accessibility_tree(tab):
    # Enable the Accessibility domain
    tab.call_method("Accessibility.enable")

    # Get the accessibility tree
    tree = tab.call_method("Accessibility.getFullAXTree")
    return tree

def main():
    # Create a browser instance
    browser = pychrome.Browser(url="http://127.0.0.1:9222")

    # Create a new tab
    tab = browser.new_tab()

    # Start the tab
    tab.start()

    # Navigate to a URL
    tab.set_url("https://www.example.com")
    time.sleep(3)  # Wait for page to load

    # Retrieve the accessibility tree
    accessibility_tree = get_accessibility_tree(tab)
    print(accessibility_tree)

    # Stop the tab (closes it)
    tab.stop()

    # Close the browser
    browser.close()

if __name__ == "__main__":
    main()

This script will launch Chrome, connect to it, navigate to "https://www.example.com", and then print the accessibility tree to the console.

Note: The script to launch Chrome assumes a typical installation path on Windows. You will need to modify this path according to your Chrome installation location and operating system. Additionally, handling different operating systems requires conditional checks and respective commands for each OS.