Migrate to Verlon

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.

import OpenAI from 'openai';

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

import OpenAI from 'openai';

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

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 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:

import OpenAI from 'openai';

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

import OpenAI from 'openai';

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

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 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:

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

The platform docs 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, not just Claude. Details in the Anthropic guide.

Migrating off the Verlon SDK’s inference methods

@verlon-ai/sdk has deprecated all of its inference methods — complete(), chat(), chatStream(), image(), embeddings(), tts() (2.5), video(), ocr() (2.6), and the tracing-surface task.chat() / task.chatStream() (2.6.1). They keep working through every 2.x release and are removed in 3.0.0, scheduled December 1, 2026 — after which the SDK performs no inference at all.

Inference moved to the format you already know: call Verlon’s drop-in routes with the official provider SDKs. The Verlon SDK remains for agent tracing and the model registry, and plugs those same official SDKs into tracing via clientOptions().

Deprecated method	Replacement	Route
`chat()` / `chatStream()` / `complete()`	`openai` package, `chat.completions.create()`	`/v1/chat/completions`
`image()`	`openai` package, `images.generate()`	`/v1/images/generations`
`embeddings()`	`openai` package, `embeddings.create()`	`/v1/embeddings`
`tts()`	`openai` package, `audio.speech.create()`	`/v1/audio/speech`
`video()`	`openai` package, `videos.create()` / `retrieve()` / `downloadContent()`	`/v1/videos` (async job)
`ocr()`	`@mistralai/mistralai`, `ocr.process()`	`/mistral/v1/ocr`
`task.chat()` / `task.chatStream()`	official SDK via `task.clientOptions('openai' \| 'anthropic')` — same attribution, correlation, and dashboard model pins	any inference route

The gateway also serves /v1/responses (OpenAI Responses API) and /v1/messages (@anthropic-ai/sdk). Every drop-in route authenticates with your Verlon API key as the Bearer token. Address your gate any of three ways: a gateId body field, an X-Verlon-Gate-Id header, or the gate UUID in the model string (optionally <gate-uuid>/<task> to also name a task). Inside a trace scope, task.clientOptions('openai') handles all of it for you — see the SDK overview. Video is an async surface on the gateway, exactly like OpenAI’s: videos.create() returns a job, poll videos.retrieve() until completed, then videos.downloadContent() streams the bytes. OCR keeps Mistral’s own shape — a document in, markdown pages out. Before-and-after for the common case:

import { Verlon } from '@verlon-ai/sdk';

const verlon = new Verlon({ apiKey: process.env.VERLON_API_KEY });

const response = await verlon.chat({
  gateId: process.env.GATE_ID,
  data: { messages: [{ role: 'user', content: 'Hello!' }] },
});

import OpenAI from 'openai';

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

const response = await openai.chat.completions.create({
  model: process.env.GATE_ID, // gate UUID in the model slot
  messages: [{ role: 'user', content: 'Hello!' }],
});

Need a hand?

Migration walkthroughs are on the roadmap. In the meantime, email micah@verlon.ai — most migrations we’ve seen take under an hour on the customer side.

Getting Started

SDK Reference

Platform

Integrations

Provider Compatibility

From LiteLLM

From OpenRouter

From a hand-rolled gateway

Anthropic SDK users

Migrating off the Verlon SDK’s inference methods

Need a hand?

​From LiteLLM

​From OpenRouter

​From a hand-rolled gateway

​Anthropic SDK users

​Migrating off the Verlon SDK’s inference methods

​Need a hand?

From LiteLLM

From OpenRouter

From a hand-rolled gateway

Anthropic SDK users

Migrating off the Verlon SDK’s inference methods

Need a hand?