Enterprise feature

Govern LLM API access
at the proxy layer.

Enterprise admins can issue team-scoped gateway keys, restrict provider access, and log LLM API calls under the right organization and team.

Control point

A hosted gateway for governed team traffic.

Team-scoped gateway keys

Issue a key to a backend team, data team, or product service without exposing the upstream provider secret.

Provider and model policy

Allow a team to use all configured providers, or narrow access to one provider and a small model set.

Central provider credentials

Keep OpenAI, Azure OpenAI, Anthropic, and Gemini credentials controlled by the organization.

Proxy session logging

Store request metadata, response status, model, duration, token counts, and gateway key metadata as proxy sessions.

How it is used

From provider credentials to auditable team calls.

01

Configure

An enterprise admin stores provider credentials once for the organization.

02

Scope

The admin creates gateway keys for teams and chooses which providers or models each key can use.

03

Route

Applications call https://proxy.reclaimllm.com/<org-slug>/v1 with the team gateway key instead of a provider key.

04

Review

Gateway calls are logged under the organization and team for enterprise admins and team leads.

Setup path

Admins configure policy. Teams use one gateway key.

The team key is not an OpenAI, Anthropic, Gemini, or Azure OpenAI key. It is a ReclaimLLM gateway key that authorizes access according to the organization's configured provider policy.

That keeps provider credentials server-side while still giving developers and services a normal API-shaped integration path.

1. Open the gateway pageEnterprise admin goes to the organization's LLM Gateway/API keys page.
2. Add provider credentialsStore the provider credentials the organization wants teams to use.
3. Create a team keyChoose a team, name the key, and select allowed providers or model patterns.
4. Model naming contractRequests must use a LiteLLM provider prefix (openai/gpt-5.6-luna, not gpt-5.6-luna). Org/key allowlists store the bare name after the prefix (gpt-5.6-luna, kimi-k2.6).
5. Update the app base URLPoint the app or SDK at https://proxy.reclaimllm.com/<org-slug>/v1 and use the team gateway key as bearer auth.
6. Review trafficAdmins and team leads inspect logged proxy requests in enterprise reporting and session views.

Model naming contract

Prefixed on the wire. Bare in the allowlist.

Clients must send LiteLLM-prefixed model IDs. gpt-5.6-luna alone returns 422; use openai/gpt-5.6-luna. The org catalog and key allowlist store the bare name after the prefix.

Error responses use FastAPI's {"detail":"..."} body.

Request modelMust include a supported LiteLLM prefix: openai/, azure/, azure_openai/, anthropic/, gemini/, moonshot/, deepseek/, or local/. Exception: bare text-embedding-* is treated as OpenAI.
Allowlist / org catalogStored and matched as the bare name after stripping the provider prefix. openai/gpt-5.6-luna → gpt-5.6-luna; moonshot/kimi-k2.6 → kimi-k2.6.
422 body{"detail":"Model must include a supported LiteLLM provider prefix"}
403 bodies"Provider is not allowed for this key" · "Model is not configured for this org" · "Model is disabled for this org" · "Model is not allowed for this key" · "Organization is not active" · "Gateway key is not valid for this org"
501 body{"detail":"LiteLLM responses API is not available in this runtime"} — only on /v1/responses when LiteLLM aresponses is missing

Request examples

Use it like an OpenAI-compatible proxy.

OpenAI-compatible chat

Use the gateway like an OpenAI-compatible endpoint. The model string must carry the LiteLLM provider prefix — gpt-5.6-luna alone is rejected; use openai/gpt-5.6-luna.

curl https://proxy.reclaimllm.com/acme/v1/chat/completions \
  -H "Authorization: Bearer rclm-gw-your-team-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-5.6-luna",
    "messages": [
      { "role": "user", "content": "Summarize this incident report." }
    ]
  }'

Moonshot / Kimi chat

Same contract for Moonshot: request moonshot/kimi-k2.6 while the org allowlist stores bare kimi-k2.6.

curl https://proxy.reclaimllm.com/reclaim/v1/chat/completions \
  -H "Authorization: Bearer rclm-gw-your-team-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshot/kimi-k2.6",
    "messages": [
      { "role": "user", "content": "Compare FCF of amazon and microsoft?" }
    ]
  }'

Embedding request

Embedding traffic can use the same team gateway key, so retrieval and search pipelines follow the same org policy.

curl https://proxy.reclaimllm.com/acme/v1/embeddings \
  -H "Authorization: Bearer rclm-gw-your-team-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "azure/text-embedding-small",
    "input": ["Searchable context from an LLM session."]
  }'

Logging

Every gateway call becomes enterprise context.

The gateway is not only a pass-through. It creates proxy session records that enterprise admins and team leads can use for review, investigation, and usage analysis.

IdentityOrganization, team, attributed team lead, and gateway key metadata
RequestEndpoint, method, model, streaming flag, and sanitized request payload metadata
ResponseStatus, duration, input tokens, output tokens, and provider response metadata when available
AccessEnterprise admins and team leads can review proxy requests for their organization context

Current limits

Built for governed access first, with sharper controls coming next.

Organization-level provider credentials

Team-owned provider credentials and separate provider billing by team are not part of the first version.

Gateway reliability is in the request path

The gateway becomes part of customer LLM traffic, so uptime and retry behavior matter more than passive capture paths.

Provider compatibility still needs real traffic

Provider APIs differ around streaming, token reporting, responses, and embeddings. Feedback from production edge cases will shape the next pass.

Route team LLM traffic through a governed gateway.

Use team-scoped keys for provider access, then keep request history visible in the same enterprise workspace as the rest of your captured AI activity.