Which one to pick
Pick Keylayer if what you need is the key layer: provider keys locked away, and a key for each app, agent or teammate with its own spend caps, rate limits, expiry and IP rules, with no proxy, database or cache to operate. Your code keeps the provider's own SDK; only the base URL and the key change.
Pick LiteLLM if you want one API in front of many providers, with load balancing, fallbacks and retries, and you're glad to run it. It routes by shuffle, least busy, latency or cost, falls back on content policy and context window errors, and covers 100+ LLMs. It's MIT licensed outside its enterprise folder, and the whole stack stays in your infrastructure.
Keylayer and LiteLLM, side by side
| Feature | Keylayer | LiteLLM |
|---|---|---|
| Hosting | Hosted, nothing to run | You run the proxy and Postgres, plus Redis past one instance |
| Providers | 11 built in | 100+ LLMs |
| Per-key spend cap | Dollars per UTC hour, day, week or month, hard or estimated | max_budget with a budget_duration |
| Checked before the call | Yes, the worst case is reserved first | Yes, budget reservation is on by default |
| Per-key rate limits | Requests a minute, requests at once and request caps | rpm_limit, tpm_limit and max_parallel_requests |
| Key expiry | 1 hour by default, up to 365 days | Optional duration; keys don't expire by default |
| Scope per key | Paths and methods | Allowed models and routes |
| IP allowlists | Per key, on every plan | Enterprise feature |
| Price | Free plan; Pro $19 a month | Free to self-host; Enterprise through sales |
What LiteLLM's budgets take to run
LiteLLM's virtual keys need a Postgres database. Its docs call Redis "Required once you run more than one instance", because without it, "Spend is reserved and counted per worker, so concurrent requests on different workers can overshoot a hard budget before the database catches up." Rate limits without Redis are likewise multiplied by the number of workers.
That's the part Keylayer takes off your plate. Keylayer checks all of a provider key's limits in one region, which you can pick, so requests running at the same time count against the same cap.
Moving virtual keys to Keylayer
Most LiteLLM key settings have a Keylayer limit to match:
max_budgetwithbudget_durationbecomes Spend in dollars per UTC hour, day, week or monthrpm_limitbecomes Requests a minute, andmax_parallel_requestsbecomes Requests at oncedurationbecomes the key's lifetime, up to 365 daysallowed_routesbecomes Only paths, with * for one path segment and ** for the rest
Two have no match: tpm_limit, since Keylayer limits requests and dollars rather than tokens, and a per-key model list. The limits docs list every field.
Questions
Is there a hosted version of LiteLLM?
Keylayer is the hosted way to get LiteLLM-style virtual keys. LiteLLM itself has no hosted version: the open-source gateway is self-hosted, LiteLLM Enterprise, sold through its sales team, runs in your own cloud or air-gapped, and the free hosted proxy behind its old community keys is no longer available.
Does LiteLLM check budgets before sending a request?
Yes, and so does Keylayer. LiteLLM's budget reservation is on by default: it estimates a request's maximum cost, reserves it, and rejects the request before sending it if the budget would be exceeded, but with more than one instance it needs Redis to do that reliably. Keylayer reserves each request's worst case in one region per provider key, with nothing for you to run.
Do Keylayer keys expire on their own?
Yes. A Keylayer key lasts 1 hour by default, anywhere from 1 minute to 365 days, and nothing can extend it. LiteLLM virtual keys don't expire unless you set a duration.
How does the cost compare?
Keylayer's free plan covers 10 provider keys and 5,000 requests a day on each, and Pro is $19 a month or $190 a year, with nothing to run. LiteLLM's open-source proxy costs nothing beyond the servers, Postgres and Redis you run it on. Neither adds a markup on tokens.