Provider keys let you use your own model provider accounts instead of Coroid-routed models. Usage is then billed by that provider directly to you, at whatever rates you have negotiated.
Manage them under Settings → Provider keys.
When to bring your own
BYOK is worth it when you already have provider agreements, committed spend, or a procurement requirement that the model vendor be a direct supplier.
If none of those apply, Coroid-routed models with prepaid credits are simpler, and Coroid adds no markup to provider token rates either way. The choice is about contracting, not price.
How keys are handled
- Encrypted at rest.
- Never returned. Once saved, a key cannot be read back through the interface or the API. You can replace it; you cannot retrieve it.
- Never exported. Settings export bundles carry a placeholder, not the secret. See Export and import settings.
The write-only property is deliberate. A credential that can be read back is a credential that can be exfiltrated by anything with read access.
Rotating
Replace the key with the new value. In-flight work continues on the connection it started with; new work uses the new key.
Rotate on your provider's schedule, and whenever someone with admin access leaves. There is no way to determine from Coroid whether a key has been used elsewhere — that is what your provider's own audit log is for.
Scoping
Where your provider supports scoped or restricted keys, use one. A key limited to the models and spend limit you intend for Coroid is a much smaller problem if it is ever exposed.
Set a spend limit at the provider. It is the only hard ceiling that exists — Coroid's own limits govern capacity, not your provider bill.
Falling back
If a key is invalid, expired or over its provider limit, model calls using it fail. Work does not silently continue on a different provider — that would be a surprising thing to do with someone else's money.
Fix the key, and queued work resumes.