Tool overview

Open Interpreter lets a language model run code and interact with your computer through a terminal-style interface. It can inspect files, write scripts, run commands, and automate local tasks.

That is exactly why local setup deserves care. Open Interpreter is not just a chat app. It is an execution harness. If you connect it to a weak model or allow broad system access, it can make poor decisions quickly.

Step-by-step setup

Quick requirements

Prepare:

  • macOS, Linux, or Windows
  • Python if you use the Python package path
  • A local model provider such as Ollama or LM Studio
  • Git if you want repository-related workflows
  • A test folder that does not contain sensitive files

If you use Ollama:

ollama pull codestral
curl http://localhost:11434/api/tags

If you use LM Studio, load a model in LM Studio and start the local server. The OpenAI-compatible base URL is usually:

http://localhost:1234/v1

Step 1: Install Open Interpreter

The simplest path is the platform installer.

macOS or Linux:

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

Windows PowerShell:

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

Restart your shell and check:

interpreter --version

If you prefer a Python environment, use:

python -m venv .venv
source .venv/bin/activate
pip install open-interpreter

On Windows PowerShell:

python -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install open-interpreter

For local model helper dependencies:

pip install "open-interpreter[local]"

Step 2: Start a local model provider

Open Interpreter does not magically run a model by itself. It needs a local or remote model backend.

For Ollama:

ollama pull codestral
ollama run codestral

In another terminal, confirm the API:

curl http://localhost:11434/api/tags

For LM Studio:

  1. Open LM Studio.
  2. Download a coding-capable model.
  3. Load the model.
  4. Open the local server or developer server tab.
  5. Start the server.
  6. Use http://localhost:1234/v1 as the OpenAI-compatible base URL.

Step 3: Launch Open Interpreter locally

Use the local model explorer:

interpreter --local

Choose your local provider from the menu and follow the provider-specific prompts.

For a direct Ollama command:

interpreter --api_base "http://localhost:11434" --model ollama/codestral

For LM Studio, use an OpenAI-compatible model configuration. The exact model name should match the model loaded in LM Studio:

interpreter --api_base "http://localhost:1234/v1" --model openai/local-model

If the model responds but struggles to follow execution instructions, switch to a stronger coding model or reduce task complexity.

Step 4: Use offline mode in Python

For scripted use, configure Open Interpreter explicitly:

from interpreter import interpreter

interpreter.offline = True
interpreter.llm.model = "ollama/codestral"
interpreter.llm.api_base = "http://localhost:11434"

interpreter.chat("List the files in the current directory.")

offline = True disables online features such as open procedures. It does not make unsafe code safe, and it does not prevent a local model from asking to run destructive commands. It simply keeps the workflow local when paired with a local model.

Step 5: Use safer local execution habits

Start inside a test folder:

mkdir oi-test
cd oi-test
interpreter --local

Use prompts that require confirmation:

Inspect this folder and explain what you would change. Do not modify files yet.

Avoid prompts like:

Fix everything automatically.

For local automation, a safer workflow is:

  1. Ask Open Interpreter to inspect.
  2. Ask for a plan.
  3. Approve one small action.
  4. Review the result.
  5. Continue in small steps.

This is slower than giving full control, but it is much less likely to damage files.

Step 6: Sandboxing options

For stronger isolation, run Open Interpreter inside a container, virtual machine, or disposable development environment. Docker-based sandboxing can reduce the blast radius of generated code, but it does not remove all risk.

Use sandboxing when:

  • The task involves untrusted files.
  • The model may run shell commands.
  • You are testing generated code.
  • You do not want the agent to see your home directory.
  • You need a repeatable disposable environment.

Even in a sandbox, read commands before approval. A sandbox is a boundary, not a judgment system.

Common problems

interpreter is not found

Restart your terminal after using the installer. If you installed with pip, activate the virtual environment first.

source .venv/bin/activate
interpreter --version

On Windows:

.\.venv\Scripts\Activate.ps1
interpreter --version

Ollama connection fails

Confirm Ollama is running:

curl http://localhost:11434/api/tags

Then check that your model name matches:

ollama list

LM Studio responds but Open Interpreter fails

Make sure the LM Studio server is running, a model is loaded, and your base URL includes /v1:

http://localhost:1234/v1

The model loops or writes bad code

Use a stronger coding model, reduce the task size, add a clearer instruction, and avoid allowing automatic execution. Local models can be useful but are not equally reliable for code execution.

Security notes

Open Interpreter can run code on your machine. Treat it like a junior automation assistant with shell access.

Use these rules:

  • Start in a test directory.
  • Keep backups of important files.
  • Do not expose credentials in the working folder.
  • Review commands before running them.
  • Use offline mode with local models when privacy matters.
  • Use a sandbox for risky or unknown code.
  • Avoid broad filesystem access for vague tasks.

Questions to answer before installing

  • Do you need script execution on your machine or read-only local automation?
  • Which model providers and tools do you need to support on day one?
  • Which folders are safe for automatic file writes?
  • Should command execution default to manual confirmation?
  • Do you want cloud fallback, managed API access, or strictly local inference?

Approximate U.S. planning cost

  • Software and install cost: open-source package and local install path with optional one-line installers; no mandatory per-install fees.
  • Local hardware cost: higher memory/storage requirements for larger coding models; keep backups and recovery for workspace-safe testing.
  • API-token spend: only when using hosted endpoints instead of local providers.
  • Paid plans: many external providers are metered or subscription-based.
  • VPS/managed service option: remote execution via container or VPS can centralize use across teams, usually with added compute and maintenance cost.

For current provider pricing and local-mode notes:

  • OpenAI pricing: https://platform.openai.com/docs/pricing
  • Anthropic pricing: https://www.anthropic.com/pricing
  • Open Interpreter local providers and local mode: https://docs.openinterpreter.com/guides/running-locally
  • Open Interpreter installation details: https://docs.openinterpreter.com/getting-started/setup

Cost breakdown

  • One-time cost: model downloads, interpreter setup, optional virtual environment time.
  • Recurring cost: external model usage if not fully local, hosted server uptime if remote.
  • Support cost: ongoing review time and command-diff inspection.

Trust boundaries

  • Execution boundary: interpreter can run shell commands; keep command approval and workspace scope tight.
  • Data boundary: local mode helps keep prompts on device, but task output and side effects stay in local logs and files.
  • Provider boundary: confirm each model endpoint explicitly before each major workflow.

Workspace and file-system permissions

  • Start with a folder like oi-test for early tests.
  • Expose only known directories for file reads/writes.
  • Keep git repos, credential stores, and cloud sync folders out of open command range.
  • Require manual review before destructive commands (delete, move, permission changes).

Key and secret management

  • Keep provider keys out of command history and markdown files.
  • Use environment variables or vault-style secret stores.
  • Scope keys to least privilege and remove unused keys after testing.
  • If running both local and remote providers, separate credentials by environment.

Red flags

  • A single broad workspace with no isolation.
  • interpreter --auto behavior in unknown environments.
  • Repeated model loops with destructive commands.
  • Missing explicit provider URL checks (/v1) and model identifiers.
  • No backup before first writes.

Rollback and update guidance

Rollback:

  1. Exit any active interpreter session.
  2. Restore project files from Git or snapshot.
  3. Stop remote/local server sessions if running.
  4. Restart from a clean virtual environment if package behavior is inconsistent.

Update guidance:

  • Update open-interpreter with pip after checking release notes.
  • Upgrade providers (Ollama/LM Studio) separately.
  • Re-run local smoke tests after every update.

Bottom line

Install Open Interpreter with the platform installer or pip, connect it to Ollama or LM Studio, and use interpreter --local for the simplest local start. For Python scripts, set interpreter.offline = True. The main setup challenge is not installation; it is controlling what the agent can execute.