OpenRouter Private Endpoints: when dedicated capacity wins

What Private Endpoints actually are

OpenRouter announced Private Endpoints on 14 October 2026. You register a fine-tuned model, a dedicated deployment of a public model, or capacity you have reserved with a provider, and your team calls it through the same API and model slug as the public catalog.¹ The feature is an add-on to the Enterprise plan, enabled through your account representative.¹

The mechanism matters more than the framing. OpenRouter "adds your deployment to that model's provider list instead of creating a new model".² Two requirements follow from that. The deployment must be hosted by a provider OpenRouter supports for BYOK, because requests are authenticated with your own provider key. And it must serve a model that already exists in the OpenRouter catalog, with the same request and response shape; the endpoint inherits that model's slug and capabilities.²

So this is not a way to publish an arbitrary custom model. It is a way to put your capacity for a catalog model in front of the public providers of that same model. A fine-tune of a catalog base model that keeps the base model's API shape fits. A model with no catalog entry does not.

Setup runs in four steps: blueprint, connect, test and activate. The test sends one real request through your saved provider key to check that the key is accepted, the response is OpenAI-compatible, streaming works, usage fields come back and the model ID matches.² Each organization gets 10 private endpoints by default, and unfinished drafts count toward that limit.²

The cost question: fixed capacity against per-token capacity

Shared routed capacity is billed per token. A dedicated deployment is billed for being there, whether or not you use it. The break-even is the monthly token volume at which the fixed cost equals what the same traffic would cost per token:

def break_even_mtok(fixed_monthly, shared_per_mtok, dedicated_per_mtok=0.0):
    """Million tokens per month above which dedicated capacity costs less.

    fixed_monthly      what the dedicated deployment costs per month, replicas included
    shared_per_mtok    blended rate per million tokens on the shared alternative
    dedicated_per_mtok per-token charges on the dedicated path (a platform fee, if any)
    """
    margin = shared_per_mtok - dedicated_per_mtok
    if margin <= 0:
        return float("inf")  # dedicated can never win on cost
    return fixed_monthly / margin

The dedicated_per_mtok term is there because the sources I read do not say whether OpenRouter's BYOK fee applies to private-endpoint traffic. The BYOK page states a fee of 5% of what the same model and provider would cost on OpenRouter, after a monthly allowance, with $25,000 included on pay-as-you-go and custom allowances on Enterprise.³ Private Endpoints rely on BYOK keys, but the add-on's own price and its fee treatment are not published on the pages I read. Ask for both in writing before you model it.

Three corrections make the arithmetic honest.

• Peak, not average. Average volume sets the break-even; peak volume sets the replica count. Traffic with a 4x peak-to-average ratio needs capacity for the peak or an overflow path for it. If the overflow is shared capacity, you are paying for both.
• N+1 is part of the fixed cost. A single replica has no failover. Price the second one, or accept that its failure becomes an incident.
• The shared alternative may not exist. If quality needs your fine-tuned weights, there may be no per-token public equivalent, and the comparison is dedicated against your provider's own fine-tune hosting terms. Run the same formula there.

Failover: what the overflow path serves

OpenRouter moves a private endpoint to the front of the provider list for your organization by default. When it is rate-limited or unavailable, it can send overflow to public providers, within the provider preferences and BYOK fallback settings you have set.¹ Public fallback candidates remain available if you list them.²

Read that with the mechanism in mind. Your deployment and the public providers share one slug, so overflow lands on the public model. If your deployment is a fine-tune, the fallback answers come from the base model. That may be acceptable for a summarizer and wrong for a classifier you tuned to emit a specific label set. It is a quality change with no error attached.

The controls to use are OpenRouter's provider preferences. allow_fallbacks defaults to true, only restricts the provider set and order sets the sequence.⁴ For a fine-tune that must never be answered by a different model, restrict the request to the private endpoint's provider and disable fallbacks. Then a 429 from your own capacity is an error your application handles, not a silent swap.

BYOK adds a second layer. Each prioritized BYOK key has a shared-capacity fallback setting: by default OpenRouter tries your key and then falls back to its own endpoints, and two stricter settings stop that for the key's models or for the whole provider.³ Private endpoints depend on a BYOK key saved in every workspace that calls them, so these settings apply to the same keys.² Decide them deliberately, and test the failure path with a drill rather than reading the settings and trusting them.

The data path

A private endpoint changes who can see the deployment, not how data flows. OpenRouter is explicit: marking an endpoint private does not make it a Zero Data Retention endpoint, your provider handles prompts as it did before, and OpenRouter records the data policy you declare at registration.¹ Your request still travels from your application to OpenRouter and on to your provider with your key. That is three parties instead of two.

Two further points for a data review:

• Region. A private endpoint can use in-region routing if OpenRouter can derive a region from its address or you declare one at setup; requests to the us. or eu. hosts then route to your deployment in that region.¹
• Screening. OpenRouter's ZDR page announces that from 27 October 2026 it screens all inference requests, including ZDR traffic, for child sexual abuse material in flight, and may retain flagged content for review and legal reporting.⁵ That is a narrow exception, but it is retention at the router, and your data-flow diagram should show it.

If the reason for a dedicated deployment is that prompts must not leave a contractual boundary, count every hop that touches them, including any gateway you run in front.

How a BYOK gateway treats a dedicated deployment

A gateway that only runs on accounts you hold does not need a "private endpoint" concept, because the deployment already is a connection. INFRO's connections cover Azure OpenAI deployments, AWS Bedrock, OpenRouter and any OpenAI-compatible endpoint, with your provider billing you directly.⁶ A fine-tuned deployment on your own Azure resource, or a self-hosted vLLM server behind an OpenAI-compatible URL, is connected the way any other credential is.

The routing logic then lives in a named route. INFRO routes resolve a stable name to an ordered list of your connections and the model each should serve, with priority or weighted strategies and up to 20 if-rules in front of the targets.⁷ A reasonable shape for a fine-tune is: dedicated deployment in region A, dedicated deployment in region B, and nothing else. Failover moves a request to the next connection only before the first token, and INFRO separates same-model connection failover from opt-in cross-model fallbacks.⁸ Failure rules can decide per failure kind whether to retry, move on or stop, so you can let a timeout move to the second replica while a 429 from a saturated deployment stops instead of reaching a different model.

For cost, estimated provider cost per request is recorded, and negotiated rates can be entered per model and provider. A fixed-fee deployment has no natural per-token rate, so enter your effective rate and track the contract against its forecast through commitment tracking. Whether INFRO can address a private-endpoint slug through an OpenRouter connection is something I have not confirmed, since the slug exists only inside your OpenRouter organization; test it before designing around it. INFRO's own comparison of the two routers is in OpenRouter vs LiteLLM.⁹

A decision checklist

• The fine-tune needs a catalog base model with the same API shape, hosted by a BYOK-supported provider.
• Steady volume exceeds break-even at peak-sized capacity, including the second replica.
• You have the add-on price and have asked whether the BYOK fee applies to this traffic.
• Fallbacks are either disabled or limited to models whose answers you have evaluated against the fine-tune.
• The shared-capacity fallback setting on the BYOK key matches that decision.
• Your declared retention policy matches your provider contract, and the screening exception is in your data review.
• You have run a failover drill that exhausts the dedicated capacity and checked which model answered.

If most of those hold, dedicated capacity earns its fixed cost. If volume is spiky or modest, shared per-token capacity with a tested fallback is simpler and usually the lower-risk default.