Skip to main content
LLMRegistry
Access and cost boundaries

LLM API keys with limits that act before spend

One shared key gives every service the same power. LLMRegistry lets you issue separate keys, limit what each one can do, and stop a request before it reaches a provider when a rule is broken.

Secret display
Shown once at creation
Spend periods
Hourly through lifetime
Rotation grace
Optional 15 minutes

Give each application only the access it needs

A key can have its own environment, model list, network rules, expiration, and spending limit. A test key stays separate from live traffic.

01 / MODELS

Limit the model list

Allow all currently eligible models or choose up to 100 exact model and route names. Requests outside that list are rejected before provider work.

02 / NETWORK

Limit where a key works

Add up to 25 IPv4 addresses or CIDR ranges. This creates another check for server-side keys that should run only from known networks.

03 / MONEY

Set a hard spend ceiling

Choose an hourly, daily, weekly, monthly, or lifetime limit. The gateway reserves expected cost before it calls a provider.

How a key is checked

These controls are part of the request path, not a report that arrives after money is spent.

  1. Match the stored secret safely

    The raw key is shown once. LLMRegistry stores a SHA-256 digest and a short visible prefix, so lists and logs cannot reveal the original secret.

  2. Check status, time, model, and address

    The gateway rejects revoked or expired keys, the wrong environment, a blocked model, or a request from outside the allowed network.

  3. Reserve the budget

    Available key quota and organization funds are held before provider input and then settled against the request’s actual result.

  4. Record one result

    Usage is recorded once whether the provider succeeds, fails, falls back, races another model, or returns a cache hit.

Change access without a surprise outage

Keys should be easy to replace and hard to forget.

Day-to-day controls

  • Name keys for the service or team that owns them.
  • Use optional 30-day or 90-day expiration.
  • Receive threshold events at 75%, 90%, and 100% of the spend limit.
  • Revoke a key when its job ends.

Safer rotation

  • Create a new secret without changing the key’s policy.
  • Keep the old secret valid for 15 minutes when needed.
  • End the grace period immediately after the application moves.
  • Audit creation, rotation, policy changes, and revocation.

Replace one powerful key with clear boundaries

Give each service the models, budget, network, and lifetime it needs—and nothing more.

Get started