Leaving OpenRouter: a practical gateway migration checklist

Moving an application from OpenRouter to Meldport should begin with an API contract comparison, not a base URL replacement. Check the request protocol, exact model IDs, streaming events, tool round trips, and billing assumptions your application actually uses. Then decide whether the available models and controls meet those requirements. A migration can be a poor fit even when a selected token rate is lower.

Meldport's standard models use prepaid credit. Eligible :free aliases share a monthly account token pool, with quota and wallet fallback conditions. OpenRouter offers free model variants and a wider public model inventory. Those are meaningful reasons to keep an application on OpenRouter when they matter to your workload. This guide describes a decision process and a proposed validation sequence. It does not claim that we migrated a customer application, measured either provider's latency, or completed paid compatibility tests for every client.

Cutover checklist

Run one bounded request per check using non-sensitive inputs. Record the result beside the model ID and client version before increasing traffic.

Keep already dispatched work on the original gateway. Preserve its request or job ID and reconcile the original outcome before submitting the same task again. Switch new traffic in a small batch once the required checks pass, and keep the original route available for rollback.

Inventory the features your application depends on

Start by writing down endpoint paths from your application configuration and code. Include the API shape, streaming mode, model ID, required parameters, response fields, tool message structure, and error handling. Look for provider-specific options as well as the usual messages and output limits. A setting that your current provider accepts may be required for correct behavior, silently ignored elsewhere, or rejected by another gateway.

OpenRouter's API reference documents both Responses and Chat Completions endpoints. Meldport's current public documentation and repository API contract document Chat Completions. That difference is directly relevant to a client configured for Responses. Verify an endpoint before supplying a paid key; changing the hostname does not convert a request from one protocol into another.

Match model identity before comparing rates

Do not match models only by a friendly name shown in a dropdown. Record the exact model ID and any variant, then compare the destination's published identity and capabilities. A batch variant, a free variant, or an alias may have a different contract from the entry you meant to move. Treat an ambiguous mapping as unresolved rather than choosing whichever row produces the largest advertised saving.

The Meldport publisher directory lists supported third-party model publishers. Those pages are a way to inspect published models and rates, not a claim of official partnership or a guarantee that requests travel directly to the named vendor. For each proposed model, inspect context limits and capability labels, then validate your own request shape. Presence in a catalog is a prerequisite for evaluation, not proof of behavioral equivalence.

Decide what you would lose by moving

OpenRouter's free-variant documentation describes its own free model access rules. Meldport gives each verified, active account 3 million combined input and output tokens per UTC calendar month, shared across its published :free models. Only models published with that tag can use the allowance; the paid versions remain separate. Once the allowance is exhausted, a request stops unless the account's wallet fallback is enabled, the API key permits fallback where applicable, and sufficient wallet balance is available. Wallet requests use the model's published input and output prices. Compare these limits and the currently available free models before treating either service as a replacement for the other.

Routing controls are another decision point. OpenRouter documents provider selection and routing preferences. If your application depends on a particular routing option, list the behavior you need and check whether the destination exposes it. Do not assume that an identically named model preserves upstream selection, cache reuse, geography, or provider policy. Where there is no verified equivalent, record the loss and let that requirement influence the decision.

Compare a workload, including the unfavorable cases

Use the OpenRouter comparison for the dated matched-model view and the workload calculator for Meldport's published rates, cache assumptions, minimum charges and request rounding. The comparison deliberately includes models where OpenRouter has a lower listed input or output rate. An incomplete comparison that removes those exceptions may look attractive, but it cannot answer which provider has the lower bill for your own token mix.

For each candidate, calculate input tokens multiplied by the input rate plus output tokens multiplied by the output rate, using a consistent denominator. Then add applicable minimums and separately documented fees. Run an uncached scenario as well as any cache scenario you can justify. If one side is cheaper for input and the other for output, calculate the crossover rather than compressing the result into a single discount percentage.

An illustrative migration budget. The dollar values are hypothetical planning assumptions, not live offers or measured performance.

The examples show why a lower input rate alone is insufficient. They do not assume equal completion quality. For the arithmetic in more detail, use the input-to-output ratio guide.

Isolate credentials and configuration changes

Prepare a separate configuration for the destination instead of overwriting the working source configuration immediately. Give the evaluation its own key and an explicit spending limit where supported. Keep secrets out of code, screenshots, shared documents, and shell histories. The evaluator needs enough access to run the agreed test, not an unrelated production credential with a wider scope.

Record which account owns the key and where usage should appear. A successful request through an unintended account is not a successful migration check. Before running tests, confirm the hostname and model ID together. Keep the original configuration available for rollback, while ensuring that a switch between providers cannot accidentally send the same paid task twice. A deployment flag should select a route deliberately rather than silently duplicating requests.

Validate behavior with bounded tasks

Begin with a short non-sensitive prompt and a small output cap. Then test the streaming parser, one tool call and result, an invalid model ID, and a request that the client can cancel. For each check, record the expected behavior and the observed response. This is a suggested test plan, not a report that these cases have already passed against Meldport in your environment.

Next, run a small task set with acceptance criteria independent of the provider. Keep the same source inputs and judge the results using the same rules. Record request counts, confirmed charges, unresolved requests, and accepted outcomes. A response that parses successfully may still be unsuitable for the task. A timeout with unknown settlement requires reconciliation before anyone can claim a complete cost comparison.

A proposed staged cutover. The rollback conditions below are examples to adapt to your own operational requirements.

Check the details that a text-only smoke test misses

A streaming response can look successful in a terminal while the application mishandles it. Check the sequence your client expects: initial metadata, content fragments, tool arguments if present, completion signals, and usage. Test a tool result that requires a continuation request, because a single successful tool-call response proves only half of the interaction. Record the exact client and adapter versions so another developer can reproduce the same request path.

Treat structured output as a separate requirement when your application consumes machine-readable records. Validate the result against the schema your application actually uses, including required fields and invalid values. Do not infer schema enforcement from a prompt that happens to return valid JSON once. Similarly, a large context-limit label does not show that a particular task remains accurate near that limit. Run a representative bounded case with the input length that matters to your application.

Inspect provider-specific fields before forwarding an existing request unchanged. The OpenRouter routing guide documents controls such as provider preferences and fallback behavior. Preserve the intent of each control in your migration inventory. If the destination has no verified equivalent, remove the unsupported option only after deciding whether its original purpose is still required. Silently deleting it can change availability, privacy, or cost behavior while leaving the first text response apparently healthy.

Keep the free allowance separate from the rollout budget

Meldport's monthly free-token balance is shared across published free models. It is not a separate allowance for each alias and it does not make the paid version of a model free. Plan the evaluation using the account's remaining allowance and the exact selected ID. If a teammate has already used part of the pool, a previously successful free test does not prove that another test will have enough quota to finish.

Choose the fallback behavior deliberately before the evaluation. With wallet fallback disabled, exhausted free quota stops further eligible calls. With the required account and API-key permissions enabled, sufficient wallet credit can fund later requests at the applicable published rates. That is a billing decision, so record it in the test configuration alongside the model ID. A test intended to demonstrate a quota stop should not quietly leave wallet fallback on.

Finally, decide what rollback means for work already dispatched. Switching the next request back to the original gateway does not cancel or settle a request that is still unresolved at the destination. Keep its identity and reconcile it separately. This distinction is especially useful when testing cancellation or network failures: restoring availability and closing the billing record are two different checks, and both belong in the cutover evidence before a wider rollout.

Make the final decision auditable

Assign an owner to each unresolved requirement. A protocol question belongs with the integration check; an uncertain charge belongs with reconciliation; an unclear model mapping belongs with the catalog comparison. Keeping these questions separate prevents a successful text response from closing every issue at once. Record the next evidence needed and leave the migration on hold when that evidence is essential to the application's behavior.

Summarize the decision in terms of requirements met, requirements lost, comparable token costs, and unresolved evidence. Include the observation date and the client version used in any real test. If you have not run a paid evaluation, say so. If a feature only appears in vendor documentation, label it as documentation-based. This prevents a configuration example from becoming an unsupported production-readiness claim.

Keeping OpenRouter can be the right result when free variants, model breadth, or a documented routing control is essential. Choosing Meldport can be reasonable when its published models and contract fit your client and the workload calculation supports the cost. Neither conclusion follows from a generic cheapest-provider slogan. Check the coding-agent compatibility pages, inspect current evidence, and make the move only after the specific requirements of your application are understood.