> ## Documentation Index
> Fetch the complete documentation index at: https://docs.verlon.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Migrate to Verlon

> Drop-in migration from LiteLLM, OpenRouter, or a hand-rolled LLM gateway — usually one config change on your side.

Verlon is designed to sit exactly where LiteLLM, OpenRouter, or your own LLM proxy sits today. The migration is a **config change**, not a rewrite — pointing your existing SDK client at Verlon's base URL and swapping the API key.

## From LiteLLM

If you're already using the OpenAI SDK to talk to a LiteLLM proxy, you can drop that proxy and point straight at Verlon. The SDK stays exactly the same.

<CodeGroup>
  ```typescript Before (LiteLLM proxy) theme={null}
  import OpenAI from 'openai';

  const openai = new OpenAI({
    baseURL: 'https://your-litellm-proxy.example.com',
    apiKey: process.env.LITELLM_KEY,
  });
  ```

  ```typescript After (Verlon) theme={null}
  import OpenAI from 'openai';

  const openai = new OpenAI({
    baseURL: 'https://api.verlon.ai/v1',
    apiKey: process.env.VERLON_API_KEY,
  });
  ```
</CodeGroup>

Every LiteLLM-style feature you were using — routing, fallbacks, retries, cost tracking, budgets — is either configured through Verlon's dashboard or served by default. Your call sites don't change. See the full [OpenAI guide](/provider-compatibility/openai) for the exact base URL and header conventions.

## From OpenRouter

OpenRouter is drop-in for the OpenAI SDK too, so the swap is nearly identical:

<CodeGroup>
  ```typescript Before (OpenRouter) theme={null}
  import OpenAI from 'openai';

  const openai = new OpenAI({
    baseURL: 'https://openrouter.ai/api/v1',
    apiKey: process.env.OPENROUTER_KEY,
  });
  ```

  ```typescript After (Verlon) theme={null}
  import OpenAI from 'openai';

  const openai = new OpenAI({
    baseURL: 'https://api.verlon.ai/v1',
    apiKey: process.env.VERLON_API_KEY,
  });
  ```
</CodeGroup>

Verlon's model IDs map to the same public model names OpenRouter surfaces (`gpt-4o`, `claude-sonnet-4-5`, `gemini-2.0-flash`, etc.) — see the [supported LLMs list](/provider-compatibility/models) for the full inventory. Routing rules, spend caps, and quality monitoring live in the Verlon dashboard.

## From a hand-rolled gateway

If you built your own proxy that forwards to provider APIs, the win is bigger than a config swap — you're deleting code, not just re-pointing it. The pattern:

1. **Keep your existing SDK client code exactly as-is.** No call-site changes.
2. **Point it at `https://api.verlon.ai/v1`** and use a Verlon API key.
3. **Delete your routing / retry / fallback / cost-tracking code.** Verlon handles them.
4. **Configure any custom routing rules** in the dashboard once, not per-service.

The [platform docs](/platform/gates) cover the model picker, routing rules, budgets, and experiments — every knob you rolled by hand.

## Anthropic SDK users

Same story on the other side. If your app talks to Anthropic-hosted Claude via the Anthropic SDK, point it at Verlon and get routing, failover, and quality monitoring — with access to every other model in the [registry](/provider-compatibility/models), not just Claude. Details in the [Anthropic guide](/provider-compatibility/anthropic).

## Need a hand?

Migration walkthroughs are on the roadmap. In the meantime, email [micah@verlon.ai](mailto:micah@verlon.ai) — most migrations we've seen take under an hour on the customer side.