Configuring LLM Providers
Configure Anthropic, OpenAI, Groq, and GitHub Copilot keys, discover their models, and assign each provider to a model group.
Cremind talks to language models through providers. A provider is a
named integration — anthropic, openai, groq, copilot — that
holds the credentials and the list of models Cremind discovered for it.
You configure providers once, then assign their models to the
high / low / default model groups the agent
reaches for.
Everything on this page has a control on the Settings -> LLM
Providers page in the web UI, and a one-to-one counterpart in the
cremind llm CLI. Anything you change in one shows up in the other.
API keys and OAuth tokens are stored server-side and are never read
back to the CLI or UI. After you save a key, a provider only reports a
configured: yes flag — the secret itself is never surfaced again.
In the web UI
Sidebar -> Settings -> LLM Providers
The page lists each provider as a card showing whether it is configured, its active auth method, and its model count. The card's Configure panel sets the key and auth method, and the Model groups section at the top of the page assigns models to groups.
Configuring a key-based provider
Anthropic, OpenAI, and Groq authenticate with an API key. In the UI, open the provider's card, paste the key, and save. From the CLI:
cremind llm providers configure anthropic --api-key sk-ant-...You can also switch the active auth method or pass extra provider fields (such as an organization id or a custom base URL) as JSON:
# Extra fields via JSON, merged into the body
cremind llm providers configure openai \
--json '{"organization":"org-...","base_url":"https://api.openai.com/v1"}'At least one of --api-key, --auth-method, or --json must be
supplied. Validation is server-side: if the provider does not accept a
field, the call returns an error and nothing is changed.
Listing providers and their status
cremind llm providers listNAME DISPLAY CONFIGURED MODELS ACTIVE_AUTH
anthropic Anthropic yes 8 anthropic
openai OpenAI no 0
copilot GitHub Copilot yes 12 oauth_personal| Column | Meaning |
|---|---|
NAME | Internal provider id (anthropic, openai, groq, copilot). |
DISPLAY | Human-friendly name shown in the UI. |
CONFIGURED | yes once any config has been written for the provider. |
MODELS | Number of models discovered for the provider. |
ACTIVE_AUTH | The auth method currently selected. |
Model discovery
Once a provider is configured, Cremind enumerates the models it exposes. List them for a single provider:
cremind llm providers models anthropicID NAME
claude-opus-4-7 Claude Opus 4.7
claude-sonnet-4-6 Claude Sonnet 4.6
claude-haiku-4-5-20251001 Claude Haiku 4.5Provider configured but MODELS is 0?
The server knows the provider but could not enumerate its models —
usually a wrong key or an unreachable provider when discovery last ran.
Re-run cremind llm providers configure with a known-good key, then
list again.
GitHub Copilot via device-code sign-in
GitHub Copilot does not use a pasted API key. Instead it uses a device-code OAuth flow: Cremind hands you a short code and a URL, you authorize in the browser, and the token is stored server-side. In the UI this is the Sign in with GitHub Copilot button; from the CLI it is two commands.
# 1. Start the flow — note the URL, the user code, and the device code
cremind llm device-code startverification_uri https://github.com/login/device
user_code ABCD-1234
device_code 4fe...e8c
expires_in 900
interval 5Open the verification_uri, enter the user_code, then poll with the
device_code. The poll command blocks until you finish authorizing in
the browser:
cremind llm device-code poll 4fe...e8ccomplete (token stored server-side)The device code is short-lived (expires_in seconds, typically around
15 minutes). If it expires before you authorize, run
cremind llm device-code start again for a fresh code. Pressing Ctrl-C
during the poll is safe and does not invalidate the code.
Assigning providers to model groups
Configuring a provider is only half the job — the agent does not use a model until it is assigned to a model group. Groups are the indirection that lets the agent reach for a heavyweight model when it plans and a cheaper model for routine tool calls.
# See the current high/low/default assignments
cremind llm model-groups get{
"default_provider": "anthropic",
"model_groups": {
"high": "anthropic/claude-opus-4-7",
"low": "anthropic/claude-haiku-4-5-20251001"
}
}# Point the high group at a stronger reasoning model
cremind llm model-groups set --high anthropic/claude-opus-4-7Model groups have their own page that explains the high / low split and why it lowers token cost — read it next.
Model groups
Assign models to the high and low groups, and learn why the split matters.
Model groups (concept)
The architectural reasoning behind the two-group design.
Removing a provider's configuration
To clear every stored field for a provider — API key, OAuth tokens, base URL, everything:
cremind llm providers delete-config openaiThe provider stays known (it still appears in providers list), but
its configured flag flips back to no and any models that depended on
the config become unavailable.
First-Run Setup Wizard
Walk through the browser-based wizard that bootstraps a fresh Cremind server — LLM provider, deployment choices, per-service storage, and the first admin profile.
Assigning Model Groups
Map providers and models to the high and low model groups so the agent reasons with a strong model and runs tool calls with a cheaper one.