OpenRouter fallback with a price cap: limiting backup routes

To limit OpenRouter fallback cost, control eligible provider rates and the total application-task budget separately. A route price setting does not automatically bound conversation length, retry count or every additional feature. Preserve both kinds of limits, then verify the actual execution and charges in a small test.

Confirm the price unit

The documented provider.max_price setting includes maximum prompt and completion rates per million corresponding tokens, with other fields for other components. Verify the unit before copying a number from a budget into configuration.

This illustrative object shows rate limits, not the price of one request or a recommended model tariff:

{
  "provider": {
    "max_price": { "prompt": 1, "completion": 2 }
  }
}

A long input and output can incur more total usage than a short call under the same accepted rates. Keep the model’s applicable pricing and task lengths alongside the configuration.

Review every backup target

A backup must meet quality, context, tool and data-handling requirements as well as price. Record why each target is eligible and what functionality must remain intact. Do not allow fallback to silently relax a mandatory schema or handling restriction just to obtain any successful response.

Other service limits still apply around the routing rule. An empty eligible set should produce an understandable failure, not an unrestricted second attempt. Save the actual answering model and route so a successful result can be checked against the intended restrictions.

Bound rates and workload independently

Control	What it constrains
max_price	Eligible rate for the relevant route component
Input and output limits	Potential work in one operation
Step and attempt limits	Work across the whole application task
Key or workspace budget	Applicable aggregate usage allowance

Agent loops make this distinction especially important. A low-rate model can still create substantial expense when it repeats unsuccessful tools or continues indefinitely. Assign a total deadline and keep each attempt linked to the original task.

Test success and an excluded route

Prepare one ordinary request with an eligible endpoint and another for which the allowed choices cannot meet the restrictions. Verify the actual executor in the first case and clear failure handling in the second. Merely seeing the JSON field in a log does not prove it affected selection.

Test an unavailable primary target in an authorized setup, then reconcile usage and charges before increasing load. A controlled routing estimate supports that discussion without promising utilization or returns.

Official references: openrouter.ai — provider selection, openrouter.ai — limits.

Related guides: OpenRouter provider routing: the difference between only and order, OpenRouter Zero Data Retention: restricting eligible routes.