Choosing and configuring model providers

Authenticate a provider, switch models mid-session, and write an opencode.json that pins the right model to the right job.

Authenticating a provider

OpenCode is model-agnostic: the provider layer is a list of adapters, and any adapter that speaks a compatible API can carry a model. Credentials are stored outside your repository, in OpenCode's own data directory, so nothing sensitive lands in the project.

# interactive provider picker; stores credentials outside the repo
opencode auth login

# see what is configured, without printing the keys
opencode auth list

# remove one
opencode auth logout

Inside a session, /connect adds a provider and /models lists every model available across configured providers.
Environment variables work too - ANTHROPIC_API_KEY, OPENAI_API_KEY, OPENROUTER_API_KEY and the rest - and take effect on the next launch.
Prefer environment variables in CI, where an interactive login is not possible, and the stored credential file for local work.

⚠️

Never put an API key in a committed opencode.json. The file is designed to be shared with the team, and the moment a key is in it, the key is in your history. Keep credentials in the auth store or the environment, and reference nothing else.

The configuration file

{
  "$schema": "https://opencode.ai/config.json",
  "model": "anthropic/claude-sonnet-4-5",
  "small_model": "anthropic/claude-haiku-4-5",
  "autoupdate": true,
  "share": "manual"
}

Key	What it controls	Typical value
`model`	The default model for the build agent	`provider/model-id`
`small_model`	Cheap model for titles and summaries	A fast, inexpensive model
`instructions`	Extra context files always loaded	`["CONTRIBUTING.md"]`
`provider`	Per-provider options and custom models	Base URLs, model lists
`agent`	Per-agent model and prompt overrides	Per-task tuning
`permission`	What is allowed without asking	`edit`, `bash`, `webfetch`
`mcp`	External tool servers	Local and remote servers
`share`	Session link behaviour	`manual` or `disabled`

The same keys exist at three levels: global (~/.config/opencode/opencode.json) for your defaults, project (./opencode.json) for the repository, and per-agent for individual roles. Project settings win where they overlap, which is how a repository can require a specific model without breaking your personal setup.

Different models for different jobs

{
  "$schema": "https://opencode.ai/config.json",
  "model": "anthropic/claude-sonnet-4-5",
  "small_model": "anthropic/claude-haiku-4-5",
  "agent": {
    "plan": {
      "model": "anthropic/claude-opus-4-1",
      "temperature": 0.1
    },
    "build": {
      "model": "anthropic/claude-sonnet-4-5"
    }
  }
}

Planning benefits from the strongest model: one good plan saves many cheap edits.
Bulk mechanical edits are the place to economise - a smaller model with a narrow prompt usually suffices.
small_model handles the background work you never read, such as session titles and summaries.
Keep the model ids in one place. Rotating a model everywhere is then a one-line change rather than a search.

# override for a single non-interactive run
opencode run --model openrouter/deepseek/deepseek-chat "summarise the diff"

# switch inside the TUI
/models

FAQ

Where are my credentials stored?

In OpenCode's own data directory on your machine, written by opencode auth login, or in the environment variables you export. Either way they stay outside the repository, which is the property that matters when the project config is committed.

Can I use two providers at once?

Yes. Every configured provider contributes models to the /models list, and each agent can name a different one. That is how you run a strong hosted model for planning and a local model for bulk edits in the same session.

Running local models with Ollama and LM Studio Permissions, privacy and secret handling

Last refreshed 2026-09-18.

Choosing and configuring model providers

Authenticating a provider

The configuration file

Different models for different jobs

FAQ

Related