Model Providers

Providers connect Open Interpreter to model services. A provider decides where requests are sent and how you authenticate; a model is the model ID you run; a harness controls the agent-facing prompt, tools, and message behavior.

For most providers, start Open Interpreter and use /model:

> /model

Choose the provider, authenticate or set the requested environment variable, then choose a model. Open Interpreter automatically selects a provider-specific harness when one is configured for that model family. You can inspect or override it with /harness.

Provider Guides

These guides cover the provider IDs, current model-selection path, API or subscription setup, harness behavior, direct CLI use, and common mistakes.

Provider, Model, and Harness

Keep the three layers separate when troubleshooting:

The provider's wire_api must support the selected harness. See Harness for the compatibility matrix.

Provider Reference

The active provider decides where requests are sent, how credentials are attached, which wire API is used, and which bundled model metadata seeds the picker.

The source of truth is code, not this table:

• Built-in runtime providers: codex-rs/model-provider-info/src/lib.rs
• Generated hosted-provider catalog: codex-rs/model-provider-info/provider_catalog.json
• Hosted-provider generator inputs: codex-rs/scripts/write_provider_catalog.py and codex-rs/model-provider-info/provider_catalog_overrides.json
• Model metadata: codex-rs/codex-api/model_compatibility_catalog.json and codex-rs/models-manager/src/provider_catalog_models.rs

Built-In Runtime Providers

These providers exist even before the generated hosted-provider catalog is consulted.

OpenAI also has an onboarding preset named openai_api_key. That preset writes an OpenAI-compatible provider using OPENAI_API_KEY; it is a setup shortcut, not a separate built-in provider id in the runtime provider map.

Wire APIs

wire_api controls the HTTP request shape.

For custom providers:

[model_providers.example]
name = "Example"
base_url = "https://api.example.com/v1"
env_key = "EXAMPLE_API_KEY"
wire_api = "chat"

Use wire_api = "responses" for OpenAI Responses-compatible providers, wire_api = "chat" for OpenAI-compatible chat-completions providers, and wire_api = "messages" only for Anthropic Messages-compatible providers.

Authentication

Provider auth can come from:

• env_key, which reads a bearer token from an environment variable.
• experimental_bearer_token, when embedding a token is unavoidable.
• command-backed auth, which runs a local command and caches the returned bearer token.
• aws, only for amazon-bedrock.
• OpenAI auth manager state for providers that set requires_openai_auth.

Anthropic-style API-key auth uses the x-api-key header and automatically adds anthropic-version: 2023-06-01. Other API-key providers use Authorization: Bearer ....

Kimi has two distinct provider paths:

• kimi-for-coding uses https://api.kimi.com/coding/v1 and supports the built-in Kimi sign-in flow for an eligible Kimi Code subscription. It can also read a compatible token from KIMI_API_KEY.
• moonshotai uses https://api.moonshot.ai/v1 with a Moonshot Platform API key from MOONSHOT_API_KEY. A Moonshot Platform key is not a Kimi Code subscription token.

Command-backed auth example:

[model_providers.example.auth]
command = "example-token"
args = ["print"]
timeout_ms = 5000
refresh_interval_ms = 300000

Generated Hosted Providers

The generated catalog is built from https://models.dev/api.json, plus live provider model endpoints configured in codex-rs/model-provider-info/provider_catalog_overrides.json. The generator includes providers backed by supported AI SDK packages, excludes unsupported or local-only entries, requires a usable base URL, and keeps only models that advertise tool calling and text output. Some provider entries are further filtered against live model IDs so decommissioned upstream models do not remain visible.

Common generated providers include:

Model Picker Behavior

The picker uses provider metadata in two passes:

1. It asks the active provider's /models endpoint when possible.
2. It seeds or supplements results from the bundled provider catalog when the provider matches by Anthropic identity, base URL, provider name, or auth env var.

Generated model entries carry display name, description, context window, reasoning control, input modalities, and priority. The generator does not invent reasoning levels from a boolean reasoning flag; those controls come from compatibility metadata or explicit overrides.

Default Harness Selection

When no harness is explicitly configured, Open Interpreter may choose a native harness mode from the provider/model family:

You can override this with harness = "..." in config. See Harness for route compatibility.

Regenerating The Catalog

Run this from codex-rs when provider source data changes:

python3 scripts/write_provider_catalog.py
python3 scripts/write_model_compatibility_catalog.py

To refresh only selected hosted providers while preserving every other generated entry, repeat --provider as needed:

python3 scripts/write_provider_catalog.py \
  --provider moonshotai \
  --provider kimi-for-coding

Live sources require their documented provider auth environment variables. For example, Moonshot requires MOONSHOT_API_KEY or KIMI_API_KEY, Z.AI requires ZAI_API_KEY or ZHIPU_API_KEY, and Groq requires GROQ_API_KEY. Missing auth is a generator failure, not a reason to silently keep stale data.