Chat models

Chat models shows everything you can pick in the assistant picker, the TUI model switcher, and any other surface that asks “which model do you want to run this on?”. Dreadnode-hosted (dn/*) models are always available — what you see is governed by your organization’s access rules, not by this surface. Its job is your account-scoped BYOK list: models from other providers that you add and run with your own API keys.

Account Settings → Chat Models

Platform models
┃ Model                           ┃ Provider   ┃
┇ dn/claude-opus-4-6              ┇ Dreadnode  ┇
┇ dn/gpt-5.2                      ┇ Dreadnode  ┇

Your models
┃ Model ID                        ┃ Provider   ┃ API Key                                                  ┃
┇ anthropic/claude-opus-4-6       ┇ Anthropic  ┇ Set ANTHROPIC_API_KEY in the shell where you run the TUI ┇

Note

Chat models is per-user. Manage it from Account Settings — click your profile at the bottom of the sidebar, then pick Chat Models. Your BYOK list is yours — teammates configure their own.

What the preference controls

The durable state is a list of enabled_model_ids — your BYOK additions. Platform dn/* models are never part of this list: they’re available to every member by default, scoped only by the organization member allowlist. Every surface that picks a model shows the platform set plus your BYOK additions:

• The web assistant picker and the TUI’s Ctrl+K picker group platform models first, then your BYOK models.
• The TUI’s /models command can search the broader catalog for one-offs outside your list.

An empty BYOK list is the default — you get all platform models and nothing else.

Model namespaces

Namespace	Where it runs	What you need
dn/<model>	Dreadnode-hosted inference	Nothing extra — billed against your credits.
openai/<model>, anthropic/<model>, openrouter/<model>, etc.	The provider’s API, using your key (BYOK)	The provider’s API key available where your session runs.

The dn/* list is sourced from currently deployed LiteLLM model aliases. When an admin adds or removes a dn/* deployment, it appears in Chat models without a platform redeploy.

BYOK models resolve their provider key from the environment your chat session runs in — for TUI chat that’s your local shell (e.g. export ANTHROPIC_API_KEY=...). The settings surface tells you which key each BYOK model needs; it can’t verify your local environment. It does show whether the key is saved in Secrets for remote agent runs — keys stored there never reach local chat sessions; they’re injected only into the remote runs you select them for (secret_ids). If a remote agent run uses one of your BYOK models, add the provider key as a Secret (each row links straight there) and select it when provisioning.

Organization member model access (owners)

Organization owners can optionally restrict which dn/* models specific members can run from:

Settings → Members → Model access

• Allow all platform models = unrestricted (allowed_model_ids = null)
• Turning that toggle off lets owners pick an explicit per-member dn/* allowlist
• Saving with an empty list ([]) denies all platform-hosted models for that member

Owners always keep access to all platform models and cannot be restricted from the member table.

When restrictions are active for your account, the TUI /models browser shows:

Your org has restricted available models. Contact your org owner for changes.

Add, remove, or reset

Use the model browser in the Chat Models section of Account Settings to search the full catalog server-side — typing runs the query against all published models, not a local slice. Enable the ones you want; remove a model from Your models when you stop using it. Platform models can’t be removed here — that’s the org allowlist’s job.

Reset to defaults clears your BYOK list entirely, returning you to the platform-only default.

Adding a model validates the ID against the catalog — typos and unrecognized IDs are rejected before they reach the preference store. Ad-hoc IDs that aren’t in the catalog can still be validated through the LiteLLM compatibility check on the browser.

When a model is missing upstream metadata, Dreadnode generates a readable name from the ID and preserves dotted version segments (for example, claude-opus-4-5 displays as Claude Opus 4.5).

Chat models vs the registry

These are different resources that share a noun:

Surface	Scope	What it manages
Chat models (this page)	User preference	Which BYOK inference model IDs appear in your picker alongside dn/*.
Models registry	Org registry	Versioned weight artifacts published from training or curation.

A registry push (dn model push ./support-assistant) doesn’t automatically make the artifact available as a chat model — those are stored weights, not hosted inference endpoints. Serve an artifact yourself (vLLM, Ray Serve, a managed endpoint) before it becomes a --model target.

Chat models vs session picking

Chat models sets what’s available. Session-time picking chooses from it:

• Agent & model covers Ctrl+K, /model, per-agent overrides, and thinking-effort tuning.
• Evaluation and runtime launches pass --model <id> and select from the available set.
• The TUI’s /models command can still search the broader catalog for one-off testing outside your list.

Related

• Secrets — provider keys for remote agent runs
• Agent & model — picking a model for the session in front of you
• Models — versioned artifact registry (distinct from inference)