How It Works
LLM API is a gateway, not a model
LLM API doesn't run any models itself. It sits between your application and the actual upstream providers (OpenAI, Anthropic, AWS Bedrock, Google, and others), speaking a single OpenAI/Anthropic-compatible protocol on the front end and forwarding each request to the real provider on the back end.
One key + one URL = access to every model from every vendor. Your code never needs to know which provider actually served a given model.
curl -X POST https://api.llmapi.ai/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $LLM_API_KEY" \
-d '{
"model": "gpt-4o",
"messages": [
{"role": "user", "content": "Hello, how are you?"}
]
}'
That request never touches OpenAI's servers directly — LLM API receives it, resolves gpt-4o to an upstream provider, forwards it, and streams the provider's response straight back to you.
Request path
Your app → LLM API (auth, routing, usage tracking) → Upstream provider (OpenAI, Anthropic, …)
There's exactly one extra hop. LLM API doesn't queue, batch, or re-process requests by default — it authenticates the call, decides which provider/region to send it to, tracks usage for billing, and proxies the request through.
Model naming and prefixes
Models are addressed by the same names/IDs the upstream providers use (e.g. gpt-4o, claude-sonnet-4-6). Optionally prefixing a model name with a provider slug (e.g. aws-bedrock/claude-sonnet-4-6) pins that specific call to one upstream provider instead of letting LLM API choose — see Intelligent routing below.
Related concepts
These are already documented as standalone Feature pages — start here, then go deeper: