In this article
only restricts eligible providers, while order expresses a preference; credential source remains a separate BYOK decision.
OpenRouter provider.only and provider.order answer different questions. The first restricts the eligible provider set; the second expresses a preferred sequence. If certain routes must be excluded, a preference list alone is insufficient without checking the remaining selection rules. Save the actual routing configuration and test its boundary.
Separate permission from preference
Read provider settings as distinct controls rather than alternative spellings for one list. Required model features, fallback policy and price constraints may also influence which destinations remain eligible. A simple successful text request does not prove that the intended restrictions were applied.
| Setting | Main question |
|---|---|
only | Who may handle this request at all? |
order | Who should be tried preferentially, and in what order? |
allow_fallbacks | Are backup providers allowed under the route rules? |
require_parameters | Must the destination support all supplied parameters? |
Use the current documented interaction of these fields. Do not assume a preferred provider becomes mandatory merely because it appears first in a list.
Use exact provider identifiers
Take identifiers from the supported catalog or routing documentation. A marketing brand, endpoint name and accepted routing value may differ. Record the model alongside the provider selection because an identifier meaningful for one route does not establish every model is served there.
Inspect the payload the application actually sends. An interface may retain an old alias or a gateway may rewrite provider fields. Keep a small control request so you can test the same configuration after a client update without resubmitting an entire private dataset.
Check BYOK as its own dimension
Choosing a provider and choosing your own credentials are related but separate decisions. A response associated with the desired provider brand does not itself establish that your upstream account handled the call. Review the BYOK configuration, preference interaction and observed usage.
For a practical test, use one model and one intended provider with a short input and output allowance. Save the accepted route and compare the applicable upstream record. If shared capacity is allowed as fallback, document that possibility and its different accounting instead of presenting every success as BYOK verification.
Test rejection as well as success
Use a controlled case where the permitted set cannot satisfy a required feature or target. Confirm that the application fails clearly rather than silently relaxing a mandatory condition. Do not probe prohibited access; the negative case should remain within the authorized test environment.
Record the routing decision as a team requirement, with an owner and review date. For infrastructure planning, this keeps provider policy separate from GPU acceptance. A planned distribution route should be evaluated on its actual terms without assuming universal eligibility or guaranteed demand.
Official references: openrouter.ai — provider selection, openrouter.ai — byok.
Related guides: OpenRouter fallback with a price cap: limiting backup routes, OpenRouter BYOK not working: credentials, region and fallback.