Add providers & keys

There are two different kinds of credential in merido. Keeping them straight is the key to a correct setup.

Two kinds of credential

1. Client / gateway keys — what callers use to authenticate to merido. Your coding CLIs put one of these in their Authorization: Bearer … header. They never leave your control. In the dashboard these are branded Gateway keys.
2. Upstream provider credentials — what merido uses to call the providers on your behalf: either a provider API key or an OAuth connection (for subscription accounts). These are stored encrypted at rest.

A request flows: your tool → (gateway key) → merido → (provider credential) → the upstream model.

Client (gateway) keys

Create one from the CLI:

merido keys create --name "my-laptop"
# optional expiry:
merido keys create --name "ci" --ttl-seconds 86400

The key is shown once — store it immediately. Or create and manage them in the dashboard under Gateway keys (rotate, rename, revoke).

Upstream providers — API key

Add a provider connection with an API key:

merido providers add --provider openai --api-key sk-...

• --provider is the provider key, e.g. openai, anthropic, openrouter, deepseek.
• --base-url is optional — it defaults to the provider's known endpoint from merido's registry.
• --label is an optional human-readable name.

The upstream key is encrypted at rest with your master key (data_dir/master.key, or MERIDO_MASTER_KEY). You can also add connections from the dashboard Providers page, which unifies API-key and OAuth providers in one place.

Upstream providers — OAuth (subscription accounts)

For providers that authenticate via OAuth (e.g. Claude, Codex, xAI, GitHub Copilot, Kiro), sign in interactively:

merido login claude

This runs the OAuth flow locally — a browser PKCE flow for most providers, or a device-code flow for CLI providers (it prints a code and a URL). On success the tokens are stored encrypted at rest. merido refreshes them in the background.

List and remove connected OAuth accounts:

merido accounts list
merido accounts remove <id>

Connecting an account to a remote gateway

To attach an OAuth account to a remote (e.g. Fly.io / multi-tenant) deployment, run the login locally but upload the captured tokens to the gateway, authenticated by a gateway key:

merido login claude --server https://your-gateway.example --token <gateway-key>

The OAuth dance still happens on your machine (the provider redirect can only land locally); the tokens are then sealed on the gateway, scoped to your org.

Browse model capabilities

Once a provider is connected, merido discovers the models it serves and what each one can do. The dashboard surfaces this two ways under Models (/app/models):

• The Models tab is a searchable, sortable table of every model across all connected providers — context and output window, input modalities (text / image / video / audio / PDF), reasoning, tool-calling, structured output, temperature, and extras like prompt caching and web search.
• Each connected provider in the Providers tab can be expanded to reveal just its own models with the same capability chips.

The capability data is synced from the open models.dev / LiteLLM rate cards and a curated table, and is exposed over the API at GET /api/model-catalog (grouped by account), GET /v1/models (per-model capabilities), and GET /v1/model_group/info (aggregated per virtual model). The router uses the same data for capability-aware routing.

Where to go next

• Connect a coding CLI — point your tools at merido.
• Virtual models & fallback — combine targets across providers/accounts.
• Media backends — turn a connected provider into an image/TTS/STT backend.
• Payload rules — normalize per-provider request quirks (or let merido strip an unsupported field automatically).
• Credential policy, vault & proxy pools — secure and route provider credentials.
• TLS interception (MITM) — capture a coding CLI's traffic into the gateway.