If you or your team already has an OpenAI, Anthropic, or OpenRouter subscription, you can now use it directly in Dawn. Add your API key to the workspace, pick the models you want available, and those runs go through your own provider account instead of consuming Dawn credits.
OpenAI, Anthropic, and OpenRouter are the first three providers available for Bring Your Own Key, with more on the way.
Adding a Provider
Open Workspace settings as the workspace owner, go to the AI Providers tab, and add a provider row for OpenAI, Anthropic, or OpenRouter. Paste the API key, choose the models you want that workspace to use, and save. Dawn validates the connection on save so you know immediately if the key works or if something needs fixing.
If the key is invalid, expired, or does not have access to the models you selected, Dawn tells you at validation time rather than failing silently the first time an agent tries to use it. That saves the back-and-forth of wondering why an agent is not returning results from a provider you thought was configured.
Each provider gets its own row with its own allowed-model list. A workspace can have all three providers active at the same time, each with different model selections.
Once a provider is saved and validated, the models you selected become available in agent settings. Open any agent profile, and the provider and model combinations you allowed are there as options alongside Dawn’s managed models. There is no separate activation step — the models show up as soon as the provider row is valid.
If you later need to change which models are available, update the provider row. Add new ones, remove old ones, or swap the API key entirely. The change takes effect immediately for any agent configured to use that provider. There is no need to reconfigure each agent individually — updating the provider row updates the available options everywhere that provider is used.
Choosing Which Models Are Available
The allowed-model list is not a suggestion — it is the workspace policy for what agents can pick from that provider. If a model is not on the list, agents in that workspace cannot use it.
That gives workspace owners real control over what runs in their workspace. A team running production support agents might lock them to a single proven model they trust. A team doing exploratory work might open the list to several options and let agent builders choose. The point is that the workspace owner decides, not each individual agent configuration.
Dawn suggests models it knows about for each provider, but the list is not closed. For providers that support it, teams can add custom model IDs — useful when your provider account has access to a model that Dawn’s built-in catalog has not picked up yet. Type in the model identifier, and Dawn treats it like any other allowed model for that provider. That means teams are never waiting on Dawn to update a catalog before they can use a new model their provider already offers.
This matters more than it sounds. Provider catalogs move fast. New model versions, fine-tuned variants, preview releases — they appear on provider dashboards regularly. Custom model IDs mean teams can adopt them in Dawn on their own schedule.
How Billing Works
The billing rule is straightforward. Runs backed by Dawn-managed credentials consume Dawn credits as usual. Runs backed by workspace API keys do not — those runs are billed to whatever provider account the key belongs to.
That cost shows up in your OpenAI, Anthropic, or OpenRouter dashboard, not in Dawn. Dawn does not track or display provider-side usage for BYOK runs. Your provider’s own billing page remains the source of truth for that spend.
This also means teams can mix both paths in the same workspace. Some agents can run on Dawn credits — convenient for teams that do not want to manage provider accounts at all — while others use the team’s own keys. A workspace might use Dawn-managed credits for lighter tasks and route heavier workloads through the team’s own Anthropic key. The split is per-agent, so each agent profile can use whichever path makes sense for what it does.
For teams that care about cost attribution, this is useful in another way. BYOK runs are visible in the provider’s own usage dashboard, which usually offers breakdowns by API key, time period, and model. That gives finance and ops teams a familiar place to track AI spend without needing Dawn to build a separate billing view.
Multiple Providers in One Workspace
A workspace is not limited to a single BYOK provider. You can have an OpenAI row, an Anthropic row, and an OpenRouter row all active at the same time. Each has its own key, its own allowed-model list, and its own validation status.
That means different agents in the same workspace can use different providers. A customer-facing agent might use one provider while an internal research agent uses another. The workspace owner controls which providers and models are available, and agent builders pick from that approved set.
This also works alongside Dawn-managed credentials. An agent does not have to use BYOK at all — the workspace can have provider keys configured without every agent being required to use them. The BYOK providers are additional options, not replacements.
Key Rotation and Maintenance
API keys do not last forever. Provider accounts get rotated, credentials expire, teams move to new accounts. When that happens, the workspace owner updates the key in the provider row and re-validates. There is no need to tear down the provider and start over — the row stays in place, the allowed-model list stays as it was, and agents keep their configuration. Only the key changes.
If a key stops working between rotations — the provider revokes it, the account is suspended, or the key hits a spend limit — Dawn surfaces the validation failure in the provider row. The workspace owner can see that something is wrong without waiting for an agent to start failing in conversations.
What Happens When You Remove a Provider
Removing a BYOK provider row from a workspace does not break agents that were using it. The agent profile still exists, but the provider and model combination it was configured with is no longer available. The next time that agent runs, it falls back to Dawn-managed credentials or another available provider, depending on how the agent is configured.
That means teams can experiment with BYOK without worrying about locking themselves in. Add a provider, try it out, and remove it if it is not the right fit. The workspace does not end up in a broken state.
Getting Started
The full setup and configuration details are in the docs: