Providers

Choose the route that fitsCopy Anchor Link

A provider is the account or backend, such as anthropic, openai-codex, or ollama. A model is selected as provider/model-id.

For most people, the shortest path is:

1. Start omp.
2. Run /model.
3. Choose a provider. Providers without credentials appear as not configured; select one and press Enter to start its login flow when available.
4. Choose a model after login finishes.

Use this table if you already know how you want to authenticate:

Account subscriptions and developer APIs are often separate products. For example, ChatGPT credentials use openai-codex; openai expects OPENAI_API_KEY. Google and xAI have similar splits. See Provider-specific caveats before guessing an ID.

Get one route workingCopy Anchor Link

/login openai-codex

omp models openai-codex
omp --model openai-codex/gpt-5.5

How models become availableCopy Anchor Link

At startup, omp assembles the model registry in this order:

1. bundled providers and known models;
2. provider overrides and custom models from ~/.omp/agent/models.yml or models.yaml;
3. cached or live discovery for supported providers and local engines;
4. providers and models registered by loaded extensions.

A custom model with the same provider and id replaces the bundled entry. Runtime discovery can update the models exposed by a provider; model overrides are reapplied afterward.

A model is selectable only when:

• its provider is not in the effective disabledProviders list; and
• the provider is keyless or has a credential omp can resolve.

Useful checks:

omp models                    # all currently available models
omp models find sonnet        # search provider, ID, selector, or display name
omp models refresh            # force fresh online discovery, then list

Inside the TUI, /model includes available models and shows catalog providers without credentials as locked. Selecting a login-capable locked provider starts its setup. Disabled providers are omitted.

For initial selection, an explicit --model wins. Without it, omp considers the active model scope, a saved default, known provider defaults, and finally the first available model. Prefer an exact provider/model-id when the same model ID exists through several routes; bare IDs and fuzzy --model patterns depend on the available catalog and configured provider order. See Model roles for persistent defaults and task-specific model choices.

Credential precedenceCopy Anchor Link

When several credentials exist for the same provider, omp uses the first applicable source:

1. runtime --api-key for this process;
2. models.yml providers.<id>.apiKey;
3. stored OAuth credentials, refreshed when needed;
4. an API key stored by /login;
5. the provider environment variable, including values loaded from .env;
6. another stored API key, such as a broker-migrated key;
7. a custom-provider fallback resolver.

Local credentials normally live in ~/.omp/agent/agent.db. With an auth broker configured, login, logout, refresh, and credential reads use the remote store instead. See Secrets and auth for storage, multiple accounts, the auth broker, and the provider-compatible auth gateway.

Current provider matrixCopy Anchor Link

The live catalog is authoritative: run omp models after authenticating. The groups below cover the current built-in model-provider IDs and the normal setup route.

Exact environment-variable names are intentionally centralized in Environment variables, because some providers accept more than one credential source.

Provider-specific caveatsCopy Anchor Link

TroubleshootingCopy Anchor Link

RelatedCopy Anchor Link

Source: omp.sh — MIT, Stencil Labs. Initially imported on 2026-10-03; updates via automatic sync.