The gateway does a lot, but it has real limits. Knowing them saves you from expecting something that will not happen.
It cannot sync an agent’s local skills
LiteLLM has a skills endpoint, but it forwards requests to the provider — it is not a store of your local agent’s skills.
An agent like Claude Code reads skills from your own computer’s disk, not from the gateway or the provider. Putting a skill on a server does not make it appear in a CLI on another machine.
An API key does not change this. Paying for tokens does not make your local skills follow you to another computer.
It cannot make one key work in every browser
Some tools keep the API key in the browser’s local storage rather than on a server. The gateway cannot change how that tool stores keys; each browser needs the key entered once.
See How to connect Open Design for the tool-specific steps.
It cannot pause a key — only delete it
LiteLLM can block a key, but blocking needs the key’s plain text. The gateway stores only a hash of each key, so it cannot reconstruct the text to block with.
The practical result: a key either exists or it does not. There is no “pause”. To stop a key, delete it; to restore access, issue a new one.
It cannot reach OpenAI or Anthropic through OpenRouter
OpenRouter refuses to proxy these two providers. A request through OpenRouter for an OpenAI or Anthropic model fails with a terms-of-service refusal, even with a correct, funded key:
This is an OpenRouter account setting, not a gateway fault. Use those providers through their own routes instead.
Provider keys are single-purpose
A key issued for one provider capability (for example images) does not work for that provider’s other capabilities (for example text models). If a route fails with a provider error and the key is definitely correct, check what the key was issued for.