Routing layer, not one model
OpenRouter accepts a request under a model identifier and selects an eligible provider endpoint. When several providers serve the same model, routing can respond to availability, price or performance. A roleplay client such as Chub AI, RisuAI or Agnai can therefore change backend behavior without changing its character UI.
Fallback and provider controls
Requests can set provider order or exclusions, maximum price, preferred quantization, and whether fallbacks are allowed. Fallbacks improve availability but can change latency, context support or moderation when a request moves to a different endpoint. Applications that require consistent behavior should pin or constrain providers rather than assuming a model name guarantees an identical serving stack.
Data-policy controls
The provider object can deny endpoints that collect data and require Zero Data Retention-eligible routes. These controls narrow routing; they do not turn hosted inference into local processing, and some models may become unavailable when a strict policy is required. Users should inspect both the model page and provider logging terms before sending intimate roleplay text.
Adult-roleplay limits
OpenRouter lists many open and proprietary models, including some used for creative roleplay, but it does not establish one uncensored-content rule across the catalog. A model author, serving provider or client may refuse adult prompts. Model removal and provider-policy changes can also break a saved character workflow, so portable prompts and a tested fallback are operationally useful.
Technical context
OpenRouter supplies hosted model routing rather than local execution; the dossier clarifies the client, template, model, and provider layers around it.