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 under your organization's own key. Each organization's provider keys are encrypted with a data key of its own. A key management service (OVHcloud KMS) encrypts that data key in turn.
- Decrypted in one place. Only Coroid's credential broker can decrypt a provider key. The broker makes the model calls itself, so the key is never handed to agents or to Coroid's other services.
- 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.
- Every use is recorded. Coroid records each call it makes with your key. The key's row shows when Coroid last used it and which task made the call. If you suspect a leak, Coroid support can tell you which tasks used the key and when.
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. Only organization owners and admins can add, replace or remove a key, and every change is recorded in the organization audit log.
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.