Access
Auth
Swarm uses /auth to connect provider credentials to the local runtime. Auth decides whether a provider can run. Model metadata decides which models, context windows, output limits, and reasoning flags Swarm can show for that provider.
Use /auth to add, verify, and select credentials.
/auth/auth status/auth key <provider> <api_key>Credentials are local runtime secrets. Model catalog data is public metadata and does not replace provider auth.
Current provider auth support
codexCodex — model provider. Auth methods: API key; OAuth browser login; OAuth remote callback / code flow.anthropicAnthropic — model provider. Auth method: API key.fireworksFireworks — model provider. Auth method: API key.googleGoogle — model provider. Auth method: API key.openrouterOpenRouter — model provider. Auth method: API key.exaExa — search provider. Auth methods: API key; configured Exa MCP server.Swarm can seed a primary model and utility-agent model from the first runnable provider.
On first provider setup, Swarm uses the provider defaults below to set the global chat model and the built-in utility subagents such as explorer, memory, and parallel. Adding another provider later does not overwrite user-managed model or agent settings.
codexgpt-5.5 (thinking: high)Utility:
gpt-5.4-mini (thinking: medium)anthropicclaude-opus-4-7 (thinking: xhigh)Utility:
claude-sonnet-4-6 (thinking: xhigh)fireworksaccounts/fireworks/models/kimi-k2p6 (thinking: high)Utility:
accounts/fireworks/models/minimax-m2p7 (thinking: high)googlegemini-3.1-pro-preview (thinking: high)Utility:
gemini-3-flash-preview (thinking: high)openrouteropenai/gpt-5.5 (thinking: high)Utility:
google/gemini-3-flash-preview (thinking: high)Exa is not listed here because it is a search/tool provider, not a chat model runner.
Swarm gets model metadata from models.dev.
Swarm fetches model catalog metadata from models.dev using the public models.dev API JSON. That snapshot gives Swarm model IDs, context windows, output limits, and whether a model supports reasoning.
Swarm stores the fetched snapshot locally with cache metadata. If the catalog is unavailable, provider auth still
belongs to /auth; model metadata may fall back to built-in defaults or the last cached catalog.
openaimaps to Swarm provider codexfireworks-aimaps to Swarm provider fireworksopenroutermaps to Swarm provider openrouterCatalog lookup is metadata-only. Provider API keys, OAuth tokens, and local auth sessions are handled separately by Swarm auth.
API keys and Codex OAuth are separate paths.
API keyStored as a provider credential and used directly by the provider runner. Codex, Anthropic, Fireworks, OpenRouter, Exa, and Google use this path.Codex OAuthStarted from /auth. Browser login uses a local callback; remote login lets you copy/paste the callback when the browser is on another machine.Where secrets liveSaved provider credentials are written to the local secret Pebble store at $XDG_DATA_HOME/swarmd/swarmd-secrets.pebble, or ~/.local/share/swarmd/swarmd-secrets.pebble when XDG_DATA_HOME is unset. If Swarm is launched with --data-dir, the secret store lives in that data directory.Encryption at restSwarm seals saved credential records with XChaCha20-Poly1305 before writing them to Pebble. Without vault mode, the local data-encryption key is wrapped by a local key file next to that secret store.Vault password/vault is the stronger option: it wraps the data-encryption key with a password-derived key using Argon2id, so secrets stay encrypted at rest and require unlock before use.Bottom line: saved Swarm credentials are encrypted at rest. The vault password does not make encryption appear for the first time; it replaces the local key-file unlock path with a user password, which is better if someone can copy your local data directory.