LiteLLM
One gateway and budget for every LLM call teams make.
Capability: llm-gateway · LLM gateway. This is a generic capability: every enabled instance receives the same one-way pushes, so several can be connected side by side.
Configure LiteLLM in Atrium → (admins only)
Setup
The master key Atrium uses to mint and revoke the per-product virtual keys on your LiteLLM proxy. Full admin scope — this must never be a chat/consumer key.
- Locate your LiteLLM proxy. Note the base URL of the proxy admin API (e.g. https://litellm.delphi-dialogue.com).
- Copy the proxy MASTER key. This is the LITELLM_MASTER_KEY the proxy was deployed with (starts with sk-). It has full admin rights over teams, keys, tags and budgets — keep it secret and rotate on the proxy if leaked.
- Paste URL + master key below. Atrium stores the key encrypted (AES-256-GCM) and uses it only server-side to broker product keys.
What you paste back into Atrium
In order, the values the steps above produce:
- Proxy URL
- Master key (sk-…)
How it works
Atrium is a key broker in front of your LiteLLM proxy. Products never hold the master key: they ask Atrium for a virtual key, Atrium mints one on the proxy scoped to a team and a budget, and hands back only that. Revoking access in Atrium revokes the virtual key, so the product loses model access without anyone editing the proxy by hand.
What Atrium does, and when
| When this happens | Atrium does this |
|---|---|
| A group is wired to the gateway | Creates the matching LiteLLM team, applies the configured budget, and tags it so spend is attributable back to that group. |
| A product asks Atrium to broker a key | Mints a virtual key on the proxy under that team and returns it to the product. The master key never leaves the server. |
| Access is revoked, or a product is retired | Deletes the virtual key on the proxy. Calls with it start failing immediately, independently of anything cached in the product. |
| Budgets or members change | Updates the team's per-member budget on the proxy so the limit is enforced at the gateway rather than trusted in the client. |
Guarantees and limits
- The credential here must be the proxy MASTER key. A consumer or chat key cannot mint or revoke, and pasting one produces a connector that authenticates for nothing useful. The separation is the point: a leak of a product's virtual key must not escalate to admin of the proxy.
- LLM gateway is a generic capability, so every enabled instance receives the same one-way pushes. Two proxies can be connected side by side.
- The master key is encrypted at rest (AES-256-GCM) and never returned to the browser.
What "Test connection" proves
Calls an authenticated admin endpoint on the proxy URL with the master key. A pass proves the URL is reachable and the key carries admin scope.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| Test connection returns 401. | The key is a virtual or consumer key rather than the master key, or the proxy was redeployed with a new LITELLM_MASTER_KEY. | Read the master key off the proxy deployment and paste it here. |
| Keys mint successfully but spend is not attributable to a team. | The team or tag was not created before the key was minted, so the key carries no team. | Re-run the group wiring so the team exists, then re-broker the product key. |
| A revoked product can still call models. | The product is holding a key minted out-of-band on the proxy, which Atrium did not create and therefore cannot revoke. | Delete it in the LiteLLM admin UI. Keys Atrium did not mint are outside its lifecycle. |
Required scopes
Grant the credential exactly these scopes; they are the least-privilege set the connector needs:
proxy master key (full admin — team/key/tag/budget)
Configuration fields
| Field | Type | Required | Notes |
|---|---|---|---|
urlProxy URL | text | yes | Base URL of the LiteLLM proxy admin API. Maps to LITELLM_URL. e.g. https://litellm.delphi-dialogue.com |
masterKeyMaster key | passwordsecret | yes | Proxy MASTER key (sk-…) with full admin scope — never the chat/consumer key. Maps to LITELLM_MASTER_KEY. e.g. sk-… |
Operating notes
- Secret fields are encrypted at rest (AES-256-GCM) and never returned to the client. Editing an instance and leaving a secret field masked keeps the stored value.
- Adding a connector from the marketplace creates a disabled, credential-less instance ("Added, not yet connected"); it does nothing until an admin opens it, pastes credentials, and enables it.
- Use Test connection on the instance page before enabling: it performs a read-only probe with the credentials you entered.
- Connector credentials live in the Atrium database, not in container env vars; changing them here takes effect without a redeploy (within the resolver's 30-second cache).