Supported providers

RouteShift normalizes twelve LLM providers behind a single OpenAI-compatible API. You bring the credentials; the proxy handles auth shape, header conventions, and response decoding.

Catalog

Google Gemini: structured output and tool schemas

Gemini requests routed through RouteShift accept the full OpenAI-compatible response_format and tools shapes — you don't need to hand-craft Gemini-specific request bodies. The proxy translates the client JSON Schema onto Gemini's JSON-Schema-native generateContent fields:

• response_format: { type: 'json_object' } and response_format: { type: 'json_schema', json_schema: { schema } } are mapped to generationConfig.responseMimeType (application/json) plus generationConfig.responseJsonSchema.
• tools[].function.parameters is sent as functionDeclarations[].parametersJsonSchema — the lossless JSON Schema field — instead of Gemini's older OpenAPI-subset parameters.

The practical upshot: schemas that use additionalProperties, $ref, oneOf, and other JSON Schema features that Gemini's OpenAPI subset rejects now validate and run. Send the same request you'd send to OpenAI:

{
  "model": "gemini-2.5-pro",
  "messages": [{ "role": "user", "content": "Return a user object." }],
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "user",
      "schema": {
        "type": "object",
        "properties": { "id": { "type": "string" }, "email": { "type": "string" } },
        "required": ["id", "email"],
        "additionalProperties": false
      }
    }
  }
}

Applies to the Gemini Developer API surface (generativelanguage.googleapis.com/v1beta).

Moonshot (Kimi) model IDs

The Moonshot line-up on platform.kimi.ai moved off Kimi-K2-Thinking. RouteShift's registry now tracks the two current direct-API models — send these IDs in the model field:

Pricing tracks the official Moonshot pages; RouteShift's cost accounting and provider key-test both use these IDs. If you have code pinned to Kimi-K2-Thinking, update it — the old ID is deprecated upstream.

Provider keys

A provider key is the upstream credential. Add one at Settings → Providers → Add credential. RouteShift encrypts the secret with PROVIDER_KEY_SECRET (AES-GCM at rest) and never returns it after save.

For providers that need extra non-secret config (Bedrock and Azure), the form exposes structured fields that are stored in a metadata jsonb column. Edit them anytime without re-entering the secret.

Multiple keys per provider

You can attach N labeled provider keys for the same provider — one per region, one per OpenAI org, one per Bedrock account. Each key is an independent target for load balancing, with its own RPM/TPM, weight, and cooldown state.

Examples:

• Two Bedrock credentials in us-east-1 and us-west-2 for failover.
• A "paid" OpenAI key plus a "trial" key for cost arbitrage.
• Multiple Azure deployments fronting the same model for capacity scaling.

Adding a new provider

The provider abstraction lives in apps/proxy/src/providers/ — see OpenAICompatProvider and AnthropicCompatProvider for the two base shapes, and BedrockProvider / AzureProvider for examples that need richer config. Most regional providers are 50–150 LOC of glue.

If you'd like a provider added that isn't in the catalog above, open an issue at github.com/smynkr/RouteShift or email support@routeshift.io.