One API for All LLMs: GPT, Claude, Gemini and Open-Weight Models (2026)

Google released Gemini 4 Argon on October 13, 2026. Can you use it alongside GPT, Claude and open-weight models through one API? Yes. A unified LLM API accepts a model ID with each request, connects to the selected provider and translates supported formats. Your application uses a gateway key to access the models.

Call four model families with one key

The examples send the same prompt to GPT, Claude, Gemini and DeepSeek. Each tab makes up to four paid model calls. The OpenAI and Anthropic SDKs retry some errors automatically, and an unhandled SDK error stops its loop. The curl loop prints each HTTP status and continues to the next model.

1. 1
   Create a Requesty key

   Sign up, create an API key and top up your balance for the paid models. Keep the key on your server, out of browser code and source control.

2. 2
   Set the environment variable

   Shell

   Copy

   export REQUESTY_API_KEY='your-requesty-key'

3. 3
   Install a client and run a tab below

   For Python, install openai with pip install openai, or install anthropic with pip install anthropic for the Anthropic tab. For TypeScript, install the client and a runner with npm install openai and npm install -D tsx typescript, then run the saved file with npx tsx app.ts. The curl tab needs no SDK.

   Use Python 3.10 or newer for the Python tabs and Node.js 22 or newer for the TypeScript tab. See the OpenAI Python SDK, Anthropic Python SDK and OpenAI npm package metadata.

import os
from openai import OpenAI
 
client = OpenAI(
    api_key=os.environ["REQUESTY_API_KEY"],
    base_url="https://router.requesty.ai/v1",
)
 
for model in [
    "openai/gpt-6.1-sol",
    "anthropic/claude-sonnet-5-5",
    "vertex/gemini-3.8-flash",
    "deepinfra/deepseek-v4.1-flash-1017",
]:
    response = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": "Explain an API in one sentence."}],
    )
    print(model, response.choices[0].message.content)

import OpenAI from "openai";
 
const client = new OpenAI({
  apiKey: process.env.REQUESTY_API_KEY,
  baseURL: "https://router.requesty.ai/v1",
});
 
async function main() {
  for (const model of [
    "openai/gpt-6.1-sol",
    "anthropic/claude-sonnet-5-5",
    "vertex/gemini-3.8-flash",
    "deepinfra/deepseek-v4.1-flash-1017",
  ]) {
    const response = await client.chat.completions.create({
      model,
      messages: [{ role: "user", content: "Explain an API in one sentence." }],
    });
    console.log(model, response.choices[0].message.content);
  }
}
 
main();

for model in openai/gpt-6.1-sol anthropic/claude-sonnet-5-5 \
  vertex/gemini-3.8-flash deepinfra/deepseek-v4.1-flash-1017; do
  printf '\nModel: %s\n' "$model"
  curl -sS -w '\nHTTP %{http_code}\n' \
    https://router.requesty.ai/v1/chat/completions \
    -H "Authorization: Bearer $REQUESTY_API_KEY" \
    -H "Content-Type: application/json" \
    -d "{\"model\":\"$model\",\"messages\":[{\"role\":\"user\",\"content\":\"Explain an API in one sentence.\"}]}"
done

import os
from anthropic import Anthropic
 
client = Anthropic(
    api_key=os.environ["REQUESTY_API_KEY"],
    base_url="https://router.requesty.ai",
)
 
for model in [
    "openai/gpt-6.1-sol",
    "anthropic/claude-sonnet-5-5",
    "vertex/gemini-3.8-flash",
    "deepinfra/deepseek-v4.1-flash-1017",
]:
    message = client.messages.create(
        model=model,
        max_tokens=256,
        messages=[{"role": "user", "content": "Explain an API in one sentence."}],
    )
    print(model, " ".join(block.text for block in message.content if block.type == "text"))

The OpenAI SDK integration uses https://router.requesty.ai/v1 as its base URL. The Anthropic Messages endpoint uses the host https://router.requesty.ai as the SDK base URL: the Anthropic SDK adds /v1/messages. Messages requires max_tokens and returns content blocks; Chat Completions returns choices. Both accept the same Requesty key.

These direct model IDs each pick one deployment, with no fallback chain behind them.

How a unified LLM API works

An LLM API aggregator provides one interface to multiple model providers. A gateway can also apply routing policies, spend controls and logs.

Your application sends a request to the gateway with a key, a model ID and a prompt. The gateway authenticates the key, identifies the serving endpoint, maps supported fields into the provider's format and sends the request upstream. It maps the response back into the API format your client expects. A routing policy can add another decision, such as which fallback to try after an error.

A gateway can use its own upstream credentials or let you bring your own provider keys (BYOK). In the latter case, the app still sends its gateway key; the provider credentials live in the gateway. Provider billing continues separately when you use your own keys. See Requesty's BYOK guide.

The model lab and host can differ

Take deepinfra/deepseek-v4.1-flash-1017 as an example. DeepSeek released the model weights; DeepInfra serves the deployment in this ID. Another host can serve the same weights under a different ID, price and set of terms. Likewise, vertex/gemini-3.8-flash is a Google Vertex route, not a Google AI Studio route.

Open-weight means you can get the model's weights under its license. That is not the same as every part of the model being open source. Calling a hosted open-weight model sends the request to a provider's infrastructure; it does not run the model on your machine. Review the model license and hosting terms before choosing either deployment.

Current models and prices

As of October 2026, these are selected Requesty catalog IDs and upstream rates in US dollars per million tokens. They include larger models and the four routes used above. The input column is ordinary, uncached input; the output column is generated tokens. Cache rates, prompt-length thresholds and other charges affect the final bill.

Both Vertex Gemini entries and the DeepInfra DeepSeek entry include current endpoint discounts. DeepInfra's model page rounds its displayed rates; the table uses the exact rates from the Requesty models API. The model library lists available routes.

What does that mean for a bill? Assume a workload totals 1 million uncached input tokens and 1 million output tokens across multiple GPT-6.1 Sol requests, each with no more than 272,000 input tokens and no other charges. Longer GPT-6.1 Sol prompts have higher rates. At the rates in the table, model usage is $2 + $10 = $12 in credits. Assuming USD payment, no promotion and all purchased credits spent on this usage, buying $12 in credits costs $12 x 1.05 = $12.60. The $0.60 is the top-up fee, not a second deduction from the $12 in credits. Existing balances, taxes and other charges can change cash paid in a given period.

Requesty's pricing lists a free tier for free models with 200 requests per day. Price per token is only the starting point. A model that needs more output tokens, tool calls or retries to finish the same task can cost more per accepted result. Run the same representative workload through each candidate and record total cost, task success and latency.

For non-streaming Chat Completions, record usage.cost with the selected model and your task result. Assign each task a unique trace_id and send it with every related call using request metadata. In the OpenAI Python SDK, pass extra_body={"requesty": {"trace_id": task_id}}, where task_id is your task's identifier. View those calls in request logs and traces. Sum the costs of calls and retries across the evaluation, including failed tasks, then divide by the number of accepted results. Compare that cost with task success and end-to-end latency.

What changes when you switch models?

Chat Completions, Responses and Messages are distinct API contracts. Now, the not so great news: a shared request shape does not make the models behave alike.

Tools and structured output

Some provider-native features are translated. Requesty's web search guide documents a common web_search tool definition for Chat Completions and Responses, mapped to supported provider formats. Messages uses its own web_search_20250305 definition. Search support and citation formats depend on the selected model and endpoint.

JSON mode and JSON Schema are two different features. Requesty's structured output documentation says its Anthropic adapter moves unsupported numeric, string and array constraints into descriptions. A description guides the model but does not enforce the constraint. Validate values in your application, even when the response parses as JSON.

For an agent, test the entire tool round trip: the model proposes a call, your code validates and authorizes it, the tool returns a result, and the model handles that result.

Reasoning, caching and streaming

Every provider handles reasoning controls a little differently. Requesty's reasoning guide documents how it maps effort levels and budgets. On its OpenAI routes, max is mapped to high, while xhigh is passed through only for models that support it. The Messages interface cannot reach that xhigh setting.

Auto caching concerns provider-side prompt prefixes, not stored answers. For providers that need explicit breakpoints, Requesty can add them; other providers handle eligible prefixes implicitly. You still send the conversation history. Cache read and write charges, minimum prefix sizes and cache hits affect the cost of a route.

When streaming Chat Completions, request usage with stream_options={"include_usage": True}. The final usage chunk has an empty choices array, so handle it separately from text chunks. See the streaming guide.

For more detail on interface differences, see our guide to OpenAI-compatible APIs and the guide to provider-native tools.

Which unified LLM API should you use?

We make Requesty, one of the products in this comparison. Choose based on who should run the gateway, how you want to pay for inference and which controls your application needs. The terms below are as of October 2026.

Compare each product's full bill, including payment processing, provider charges and optional features.

If you use BYOK, Vercel documents fallback to system credentials when your provider credentials fail. Cloudflare can fall back to Unified Billing when no applicable request or stored provider credentials are found, unless provider credentials are required.

You can also skip the gateway and use a client library. Mozilla's any-llm gives Python a shared interface and connects to providers without an intermediary proxy. You manage the upstream credentials yourself.

Put the API into production

The demo uses one key to show the interface. For production, issue separate keys to applications or teams and restrict model access. Requesty supports monthly spend limits and access lists; use them to attribute usage and limit exposure if a key is compromised.

Next, create a fallback policy with models you have tested for the same workload. In the Requesty console, choose the Fallback strategy, name it and order the models. Then replace the direct model ID in your request with policy/your-policy-name, using the name you created. The policy tries the configured chain on failures; if every model fails, the request returns an error. A fallback model also needs the right context length, tools and data-handling terms. Our guide to routing policies for agents covers the available strategies. Requesty also maintains managed policies, which you call by name without creating a custom policy.

Data location takes two checks, not one. Requesty's EU gateway processes the gateway request in Frankfurt, but the selected model endpoint determines where inference runs. Pick and verify an EU inference endpoint as well if the workload requires it.

Find models and diagnose errors

The authenticated model list shows chat models approved for your organization and allowed by the key's access list:

curl -sS -w '\nHTTP %{http_code}\n' https://router.requesty.ai/v1/models \
  -H "Authorization: Bearer $REQUESTY_API_KEY"

The models API reference documents /v1/models/all for other modalities. For an HTTP error, read the JSON error body and its error.origin field before retrying. Requesty's error reference distinguishes router and provider errors.

Requesty's limit documentation distinguishes upstream provider rate limits from gateway in-flight limits. For retries and interrupted streams, make application-side tool actions safe to repeat before replaying a request.

Pick OpenRouter if you want to explore a free-model catalog. Pick LiteLLM if your team needs to run its own gateway. Pick Requesty for managed team access with spend caps and an EU gateway. This week, choose one workload and two models, create a Requesty key, and run the same prompts through both before setting your fallback policy.