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?”. Platform (dn/*) models are supplied by your deployment and follow your organization’s access rules. This surface also manages 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

Your BYOK additions are separate from platform dn/* models. Platform models come from admin-configured deployments and are scoped 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 the platform models available to your account and nothing else. A fresh self-hosted deployment may not have platform models yet.

Model namespaces

Namespace	Where it runs	What you need
dn/<model>	Platform-configured inference	An active admin-managed deployment; SaaS usage consumes 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.

When an admin adds or removes a dn/* deployment, Chat models updates automatically.

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 gives the member access to every configured platform model
• Turning that toggle off lets owners pick an explicit per-member dn/* allowlist
• Saving with no models selected denies access to platform-hosted models for that member

Owners always keep access to all configured 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; organization owners manage member access to them.

Reset to defaults clears your BYOK list entirely, returning you to the configured platform set.

Adding a model validates the ID against the catalog, so typos and unrecognized IDs are rejected. Ad-hoc IDs that aren’t in the catalog must pass the compatibility check in the model 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)