# What Changes When Migrating OpenRouter Requests to Another OpenAI-Compatible API? > Changing the base URL and API key is only the first step when leaving OpenRouter. Standard chat fields often transfer, but model IDs, OpenRouter headers and routing extensions, fallback behavior, streaming details, usage accounting, multimodal inputs, errors, and rate limits must be tested behind a provider adapter. # What Changes When Migrating OpenRouter Requests to Another OpenAI-Compatible API? For a basic chat completion, migration may begin with a new base URL, API key, and model ID. Production behavior is broader than that request shape. OpenRouter-specific routing, headers, model slugs, fallbacks, metadata, and provider selection need deliberate replacements, while streaming and tool calls need contract tests. Treat OpenAI compatibility as a common transport dialect, not a promise that catalogs, extensions, billing, or operational behavior are identical. ## Inventory the contract you actually use Search code, configuration, and logs for every field sent to OpenRouter. Its documented OpenAI SDK setup uses `https://openrouter.ai/api/v1`, bearer authentication, and optional attribution headers. Applications may also use routing and fallback extensions. Create an inventory before changing anything: | Surface | Often portable | Usually needs review | |---|---|---| | Chat request | `messages`, temperature, output limit | Unsupported parameters and defaults | | Models | Application intent | Provider-specific model slug | | Tools | Function name and JSON schema | Parallel calls, strictness, argument streaming | | Routing | None | Provider preferences, fallbacks, transforms | | Headers | Authorization pattern | OpenRouter attribution and metadata headers | | Usage | Token counts | Cost fields, cache fields, request lookup | | Operations | HTTP status families | Rate limits, retries, timeouts, error bodies | ## Introduce a provider adapter first Do not scatter a new URL and model slug across the codebase. Put provider differences behind one adapter and expose application-level aliases. ```python from openai import OpenAI def make_client(base_url: str, api_key: str) -> OpenAI: return OpenAI(base_url=base_url, api_key=api_key) MODEL_MAP = { "coding_default": { "openrouter": "provider/model-slug", "target": "target-model-id", } } ``` The adapter should also translate optional fields, normalize errors, and emit a common event schema. ## Replace model and routing semantics Model IDs are not standardized by OpenAI compatibility. Map each application alias to a target model and verify context length, tool support, structured output, modalities, and pricing from the target's current catalog. OpenRouter supports routing and fallback behavior that another gateway may express differently or not at all. Decide whether to recreate those policies in your orchestration layer, adopt the target's router, or intentionally remove them. Silent fallback changes can alter cost and output quality. ## Remove or translate OpenRouter extensions Review OpenRouter-specific headers and body fields. Optional attribution headers can normally be removed when leaving OpenRouter. Provider preferences, fallback arrays, plugins, transforms, and metadata controls need explicit mapping. Reject unknown extensions during migration testing. Silently dropping a field makes a request appear successful while changing behavior. ## Contract-test tools and streaming Tool calling is where nominally compatible APIs often diverge. Test: * function-name and JSON-schema acceptance; * tool-choice modes and parallel calls; * incremental tool-argument events; * finish reasons and refusal fields; * malformed arguments and retries. For streaming, compare parsed event sequences instead of raw chunks. Include cancellation, mid-stream errors, final usage, empty deltas, and connection retries. ## Rebuild usage and cost accounting OpenRouter documents generation metadata with fields such as model, provider, token usage, and total cost. Another gateway may return usage in the completion, expose a separate lookup endpoint, or require client-side pricing. Normalize these into your own ledger: ```json { "request_id": "internal_123", "provider_request_id": "external_456", "gateway": "target", "model": "resolved-model-id", "input_tokens": 1200, "output_tokens": 340, "cost_usd": 0.0123 } ``` Keep estimates and reconciled charges separate. Recheck budget enforcement before moving production agents. ## Verify multimodal request shapes Image, audio, and video support is model- and endpoint-specific. Even when two gateways support a modality, they may differ in content-part schemas, file upload, URL access, asynchronous jobs, or output objects. Build fixtures for every modality you use. Do not infer media compatibility from a successful text request. ## Test operational behavior Measure rate-limit headers, retryable status codes, timeouts, queueing, regional controls, idempotency, logging, and support procedures. Use current provider documentation rather than copying OpenRouter defaults. A practical rollout has four gates: 1. Replay a golden request set offline. 2. Shadow safe traffic without user-visible effects. 3. Canary a small low-risk percentage. 4. Expand only while error, latency, cost, and output assertions remain inside thresholds. Keep a one-switch rollback until the new path survives representative load. ## Decide whether consolidation is worth it OpenRouter remains a strong fit when its broad LLM catalog and routing controls match the product. A full-modal gateway such as Atlas Cloud may be attractive when one OpenAI-compatible relationship for text, image, and video simplifies the stack. Neither advantage removes the need for model and feature testing. Choose based on measured workload requirements, not the smallest code diff. ## The bottom line When migrating OpenRouter traffic, change the client configuration, then audit every nonstandard assumption around models, routing, tools, streaming, usage, and operations. A provider adapter plus golden tests makes the migration reversible and prevents a syntactically successful request from hiding a semantic regression. ## FAQ ### Can I migrate from OpenRouter by changing only base_url and api_key? Sometimes for a simple chat request, but production integrations usually depend on model slugs, routing options, headers, streaming behavior, usage fields, or fallback semantics that also need changes. ### Which OpenRouter fields are most likely to be nonportable? Provider-routing preferences, model fallback arrays, OpenRouter attribution headers, transforms, plugins, and OpenRouter-specific metadata are common migration points. Keep them outside your core request model. ### Do OpenAI-compatible APIs use the same model names? No. Compatibility normally covers request shape, not catalog identity. Build an explicit mapping from application model aliases to each gateway's current model IDs. ### How should I test streaming after migration? Record event sequences for text deltas, tool-call arguments, finish reasons, usage, cancellation, and errors. Compare parsed events rather than raw byte chunks because framing can differ. ### What is the safest migration rollout? Use an adapter, replay a golden request set, shadow a small sample without user-visible effects, then canary low-risk traffic with rollback thresholds for errors, latency, cost, and output assertions. ### When should a team stay on OpenRouter? Stay when its broad LLM catalog, routing controls, and existing operational tooling are more valuable than consolidation elsewhere. Migration should be driven by measured requirements, not compatibility claims alone.