Models

Use /model to choose provider, model, harness, and model-specific controls. The footer shows the active selection.

Shell Overrides

interpreter -m gpt-6-sol "review this module"
interpreter -m gpt-6.1-sol "review this module"
interpreter --oss "use my local open source provider"

Config Defaults

model_provider = "openai"
model = "gpt-6-sol"
model_reasoning_effort = "medium"
model_reasoning_summary = "auto"
model_verbosity = "medium"

Easy Verified Choices

These are convenient starting points for common providers. The IDs below are either inherited from upstream model metadata or documented by the provider's current official sources. Availability still depends on the selected account, region, plan, and provider /models response. Use /model to discover what the active provider currently offers.

The OpenAI-style presets are based on upstream models-manager/models.json; the bundled copy includes gpt-6.1-sol, gpt-6-sol, and gpt-6-luna. Preset metadata does not guarantee that every provider accepts those IDs. Google's current official Gemini model list includes the listed stable Gemini 3 Flash text IDs and identifies gemini-3.8-flash as its most intelligent Flash model. Its OpenAI compatibility guide documents the compatible endpoint. DeepSeek's official model list and pricing documentation identify deepseek-flash and deepseek-v4-pro as current public IDs; deepseek-v4-flash is only a legacy alias routed to the current Flash model. Use the exact IDs returned by the selected service rather than guessing an alias. For Z.AI Coding Plan, the GLM-5.3 guide documents glm-5.3; its GLM-5.3-Flash guide documents glm-5.3-flash and glm-5.3-flashx (the latter may not be enabled for every plan). ZCode's GLM-5.1 guide and GLM-5-Turbo guide use its listed IDs; use the exact IDs returned for the selected service. Anthropic's current model overview lists claude-fable-5-1, claude-opus-5-5, claude-sonnet-5-5, and claude-haiku-4-5-20251001 as current API IDs.

Where Model Metadata Comes From

Open Interpreter does not keep one hand-written Rust list of every model. Metadata is layered:

The model manager asks the active provider for models, then uses bundled data when it can identify the provider by Anthropic identity, base URL, provider name, or auth env var. This lets proxy configurations still inherit useful metadata when they clearly point at a known provider.

Capability Metadata

Model metadata can control:

• picker visibility;
• display name and description;
• context window;
• input modalities such as text and image;
• whether the model is supported by the API;
• supported request parameters;
• reasoning control shape;
• web/search support;
• parallel tool-call support.

Reasoning is not a single boolean in the UI. The protocol has these control shapes:

Reasoning Effort

When a model exposes effort controls, Open Interpreter uses these values:

Harnesses may map these values to provider-specific fields. For example, kimi-cli maps minimal and low to low reasoning, medium to medium, and high or xhigh to high.

Unsupported models hide, ignore, or reject reasoning controls depending on provider behavior.

Input Modalities

The canonical input modality tags are:

Attach images:

interpreter -i screenshot.png "what is wrong here?"

Legacy payloads that omit modality metadata default conservatively to text and image support for compatibility, but generated provider entries should specify the real modalities when known.

Local Models

Open Interpreter has two built-in local OSS providers:

Start the local service before Open Interpreter, then launch the provider directly:

interpreter --oss --local-provider ollama
interpreter --oss --local-provider lmstudio

--oss without --local-provider uses your saved oss_provider or opens a picker that shows whether each default local endpoint is responding.

For a server on another host or port, set its full OpenAI-compatible /v1 base URL before launching Open Interpreter:

CODEX_OSS_BASE_URL=http://192.168.1.20:1234/v1 \
  interpreter --oss --local-provider lmstudio -m qwen/qwen3-coder-next

Use --local-provider ollama for a remote Ollama server. Do not create a separate model_providers entry just to change the address of either built-in local provider; CODEX_OSS_BASE_URL is the supported override.

Local model tool use

Agent prompts include instructions and tool schemas in addition to your text. Make sure the local server's active context window is large enough for that complete request. For example, a model trained for a 32K context can still run with Ollama's smaller server default unless you raise it before starting the server:

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

If the server truncates the beginning of the request, a model may answer from guesses, print a tool call as ordinary text, or ask you to run a command instead of invoking a tool. These are model/server compatibility symptoms, not evidence that the requested filesystem action happened.

The qwen-code harness uses the Chat Completions transport. For Qwen models on Ollama, select that transport explicitly so the inferred Qwen harness can use its native request shape:

interpreter exec --oss --local-provider ollama --chat-completions \
  -m qwen2.5-coder:7b "inspect this project"

For automated work, also verify the expected files or other side effects after the command exits. See Non-Interactive Mode.

Model metadata warnings

Model metadata for ... not found means the local server returned a model ID that is not in Open Interpreter's compatibility catalog. It does not by itself mean the server connection failed. Confirm the exact ID exposed by the server, pass that same value with -m, and update Open Interpreter so you have the latest catalog. Open Interpreter can continue with fallback metadata, but some model-specific controls or behavior may be unavailable.

Provider Families And Harness Defaults

Some model families get a default harness when no explicit harness is set:

See Harness for the wire-api compatibility matrix and Model providers for provider-specific setup guides.