When should a firm introduce or change routing?

A firm should introduce routing machinery when choosing between approved AI destinations solves a demonstrated problem worth the extra maintenance. It should change an existing route when evidence shows that its authorisation, task performance, reliability or cost no longer fits the work—or that a tested alternative offers a worthwhile improvement.

Neither decision starts with the largest model catalogue or the lowest advertised token price. Start with the task, its permitted destinations and the standard an acceptable result must meet.

One fixed approved route may be enough. Multiple providers are not a maturity requirement, and route choice alone cannot make a workflow safe.

Start here

• Keep it simple: establish whether one fixed route meets the workload’s quality, data, timing and budget requirements.
• Authorise before comparing: admit exact model-and-provider candidates before ranking their performance or price.
• Own the change: name the person responsible for policy, monitoring, stop decisions and eventual exit.

Decide whether routing machinery is warranted

A fixed route sends an approved workload to a specified model through a specified provider or runtime. It still needs limits, monitoring and a failure disposition; “simple” does not mean uncontrolled.

Stay with that arrangement when it meets the agreed acceptance standard, its data path remains authorised, its delays and interruptions are tolerable, and its full operating cost is within budget. An approved manual process or a visible hold may be more proportionate than automatic fallback for infrequent work.

Introduce multi-candidate policy machinery only when all four conditions are satisfied:

1. There is a defined need: observed failures, materially different task requirements, repeated manual selection or measured cost pressure justify considering alternatives.
2. There are eligible alternatives: at least two exact candidates are approved for the relevant work, not merely technically reachable.
3. The policy adds demonstrable value: a bounded comparison supports better control, resilience or economics without weakening acceptance or data requirements.
4. Someone can operate it: ownership, monitoring, maintenance effort, stop conditions and an exit path are funded and assigned.

There is no universal request-volume or percentage-saving threshold. Set the firm’s decision tolerance before testing, including the cost of integrating and maintaining the policy.

A change to a single fixed route does not necessarily require a router. If the current model is being retired, for example, evaluating and approving one replacement may be sufficient. Conversely, if the current route loses authorisation, stop affected dispatch even when no replacement is ready.

Separate model choice from provider choice

Model selection asks which model has demonstrated acceptable behaviour for a task. Provider selection asks where that model may run. Different providers serving the same model can have different terms, settings, availability and prices.

Distinguish three actions: retrying the same model and provider, changing provider for that model, and changing model. The last can change output quality, context capacity, tool behaviour and parameter support—not just availability.

The surrounding components have separate responsibilities:

Component	Responsibility to establish
Model	Produces an output suitable for the task
Provider or inference runtime	Supplies or executes inference under acceptable conditions
Router	Selects only among eligible destinations
Interface	Gives people or applications access
Workflow harness	Manages state, tools, approvals, retries and external effects

One product may perform several roles. Document the boundaries anyway: a router retry and a harness replay must not independently multiply attempts or repeat an action.

OpenRouter’s Provider Selection and Model Fallbacks documentation illustrate separate provider-routing and model-fallback mechanisms. These are product examples, not features established for every router.

Authorise candidates before ranking them

Do not begin with every reachable model and ask which is cheapest. First remove destinations the firm has not approved for this task and information.

For each candidate, record the exact model/version, provider or runtime, account and endpoint, permitted workload and data class, required context and tool support, applicable contractual conditions, price limits and review date. Keep the approval evidence accessible to the responsible owner.

Then check the full data path: application, router, provider, tracing service and internal storage. Establish content logging, retained metadata, deletion and retention arrangements, training or improvement use, and relevant processing locations. Repeat this for fallbacks.

OpenRouter’s Data Collection page describes opt-in prompt-and-response retention for its listed logging and product-improvement options, alongside stored metadata and multiple data touchpoints. That statement does not verify an account’s settings or every downstream provider’s policy.

OpenRouter documents request-level provider controls: only lists permitted provider slugs for that request, ignore lists providers to skip, and allow_fallbacks controls whether backup providers may be used when the primary is unavailable. It also documents data_collection: "deny" for providers that do not collect user data and zdr: true for endpoints with a Zero Data Retention policy. Its max_price field is described as a maximum pricing preference for the request; the retained passage does not establish a total-spend cap or its detailed enforcement. These documented controls do not prove the configuration or behaviour of an actual account. Authorise destinations before optimising price or availability.

Only after eligibility checks should candidates be ranked. If none qualifies, hold with an understandable reason. Do not silently broaden destinations, relax data rules or increase spending authority.

Begin with static rules

A static policy follows predetermined rules: a defined task uses a specified candidate, with an approved alternative and a hold if neither qualifies. It is comparatively straightforward to inspect and reproduce.

A dynamic policy selects at request time using signals such as task category, predicted complexity, latency or remaining budget. Its classifier or optimisation process becomes another component to evaluate.

An ordered fallback list is not automatically dynamic task selection. Nor does a “dynamic” product label prove that business rules are enforced.

Begin with a small authorised set and deterministic rules. Add dynamic selection only when a representative comparison shows a worthwhile benefit over that simpler baseline. Test misclassification, missing signals and stale measurements, not just successful selections. Dynamic ranking must remain inside the same eligibility boundary.

Test the work before changing the route

Define acceptance before running comparisons. Use approved representative material, including difficult and malformed inputs, with a fixed scoring method.

The rubric should cover factual support, required fields, output format, unsupported assertions, latency, exception volume and review effort. Where tools are involved, test tool selection, argument validity and external effects separately from prose quality. Fluent text cannot compensate for an unsafe action.

Run each authorised model-and-provider combination against comparable work. Record identifiers, configuration, dates, repetitions, results and uncertainty. Separate transport failures from output-quality failures; an available service can still produce unacceptable work.

Pin evaluated identifiers where supported. An alias moving to a new version is a review trigger, not proof that the original evaluation still applies.

Before an authorised rollout, define its scope, duration, budget, success criteria and rollback or hold conditions. Preserve a valid baseline. A technically successful test informs approval; it does not itself authorise production traffic or client data.

Set failure boundaries before enabling fallback

Decide in advance which failures permit another attempt, which alternatives may be used and when work stops. Set maximum attempts, elapsed time and accumulated cost, and assign one component ownership of retries.

Provider fallback and model fallback need separate permission. A substitute must preserve the task’s information boundary and acceptance standard, even if it restores availability.

OpenRouter documents an ordered model list with next-model attempts after errors, including default triggers involving context validation, moderation, rate limits and downtime. It also returns the final model identity. Those mechanisms do not authorise bypassing a refusal or establish equivalent quality.

A timeout does not prove that nothing happened downstream. If a write, booking or message may already have occurred, reconcile its state before replay. Idempotency or durable deduplication must be established in the component performing the action; a router cannot supply it by changing models.

For the live-response checks and stop conditions, read When an AI route fails live: what must a fallback preserve? It addresses operational recovery, rather than candidate admission or permanent migration.

Compare costs without weakening acceptance

A low unit price is useful only for eligible candidates delivering acceptable work. Count retries, fallbacks, other services and review effort rather than treating a successful model call as a completed business outcome.

Read What does an accepted AI result cost? for the workflow-level method. It connects all incurred attempts and review effort to accepted task outputs, while making exclusions and unresolved outcomes visible. Router integration, maintenance and governance also belong in the broader adoption decision.

Keep route-price filters separate from spending caps. A permitted unit price does not cap a long request or a month’s traffic. Use appropriate request limits, period budgets, alerts and a hard hold at exhaustion; reconcile estimates against billing.

Caching deserves its own evidence. Routing changes may alter the conditions under which reuse occurs, so do not carry assumed savings from one configuration into another. Read When does prompt caching save money? to assess observed prefix reuse, writes, reads and misses—not response caching or a universal discount.

A price announcement is also a review trigger, not an instruction to migrate. Read A model price-change notice arrived. What should you change? to establish effective terms, compare equivalent work and check billing before deciding.

Assign ownership and monitor change

Name an accountable route owner before activation. This person maintains the policy record, coordinates candidate admission, reviews evidence and ensures that holds and changes reach the right authority. Ownership does not confer permission to approve every privacy, security or spending decision.

Allocate the supporting responsibilities explicitly:

Responsibility	Assigned decision
Workload owner	Defines acceptance and confirms whether results remain useful
Privacy/security authority	Approves relevant destinations and data conditions
Operational maintainer	Implements authorised policy and maintains monitoring and recovery
Budget owner	Sets financial limits and reviews reconciled costs
Route owner	Coordinates reviews, proposes changes and maintains the exit plan

Roles may be combined in a small firm, but decisions should remain distinguishable.

Retain privacy-minimised traces: workload category, policy version, requested and actual model/provider, exclusion reasons, attempts, latency, error class, usage, estimated charges and final disposition. Link controlled quality evidence rather than copying client prompts into general analytics.

Set a review cadence suited to the workload, plus event-driven checks for model or alias changes, provider terms, retention settings, pricing, retirement notices, repeated failures and declining acceptance. Watch review burden as well as response speed.

Record thresholds and actions in advance. An unauthorised destination or unclear data path should trigger a hold and escalation; a cost trend may justify investigation or a bounded test. Missing telemetry is a gap, not evidence of healthy operation.

Keep an exit plan covering configuration, interface dependencies, retained evidence, pending tasks and the approved destination or manual process. Returning to a simpler arrangement is valid when policy machinery no longer earns its maintenance cost.

Record a decision, including the option to stay

A useful decision states the workload, evidence period, authorised destinations, acceptance standard, failure limits, cost boundary, owner and next review.

Choose among keeping the fixed route, testing an alternative, introducing static policy, trialling dynamic selection, changing an authorised route or holding for missing evidence. State who must approve the next step.

The objective is not maximum choice. It is the simplest maintainable arrangement that sends approved work to eligible destinations, produces acceptable results and stops visibly when it cannot.

Source and scope note

Selected retained sections of the linked official OpenRouter provider-selection, model-fallback and data-collection documentation were compared with this guide on 9 October 2026. These living pages do not establish a tested Digital Sanctum route or account configuration.

Documentation is living and requires rechecking before a real routing decision. No account configuration, billing, production route, benchmark or client result was verified. No Sanctum Router catalogue, scope, adapter, dispatch behaviour or commercial capability is claimed.

Use the related guides below for the next decision. These checks do not establish that any route is approved or configured.