OpenRouter on Android, with the provider boundary left visible.
A unified model API can make switching providers easier, but it introduces an aggregator and an upstream inference provider into the request path.
At a glance
An OpenRouter mobile client sends Android chat requests to OpenRouter using an API key, and OpenRouter routes them to an upstream model provider. It is a BYOK-style online route, not offline inference. OpenRouter says it logs basic request metadata and does not log prompts or completions by default unless the user opts in, while upstream provider policies and routing preferences still matter. Phos can use a user-supplied key without requiring a Phos account.
How Phos handles it
Three clear routes
Local model
OpenRouter is not used when Phos runs a model on the phone.
Local server
A personal Ollama or LM Studio server bypasses OpenRouter and uses user-controlled infrastructure.
Bring your own key
The user's OpenRouter key authenticates a request that reaches OpenRouter and an eligible upstream provider.
Who this is for
Built for people with real private work to do.
Android users who want one API for multiple hosted model providers.
People comparing local mode with a flexible online fallback.
Users who need cost limits, key revocation, and explicit provider routing.
Privacy reviewers tracing aggregator metadata and upstream prompt handling.
Plain comparison
The point is control, not a louder chatbot.
These pages are for people comparing real options. Phos should win when someone wants privacy, local control, no account wall, and an assistant that still feels good to use.
| Feature | Phos | Typical cloud chatbot | Raw local app |
|---|---|---|---|
| Model choice | OpenRouter catalog through the user's key. | One vendor's catalog. | Downloaded models supported by the runtime. |
| Prompt path | Phone → OpenRouter → selected provider. | Phone → platform provider. | Stays on phone. |
| Cost control | User funds and monitors own OpenRouter account. | Subscription or platform allowance. | No per-token fee; hardware and energy remain. |
| Fallback | Can follow configured provider routing and privacy settings. | Vendor-controlled. | Manual model switch. |
Draw the complete request path
OpenRouter offers an OpenAI-compatible API and routes requests across model providers. That convenience means at least two service roles may be involved: OpenRouter handles authentication, routing, billing, and metadata; an upstream provider performs inference. Provider preferences can restrict routing, but the user must configure them and revisit policies as the catalog changes.
This is a different privacy boundary from direct-provider BYOK and from local inference. A Phos account is not added to the path, yet the OpenRouter account and key still identify usage. For sensitive prompts, reduce unnecessary context and use local mode when capability permits. For online work, choose providers intentionally instead of treating model labels as interchangeable destinations.
Use logging and training controls deliberately
OpenRouter's current FAQ states that it logs basic metadata such as timestamps, model, and token counts, while prompt and completion logging is off by default unless the user opts in. It also describes provider-routing privacy controls and says providers that log or have unconfirmed policies are excluded unless the relevant training setting is enabled. Those are platform statements, not a guarantee about every future provider or user configuration.
Review the privacy settings before the first sensitive request and after adding new models. Avoid opting into prompt logging merely for a small discount when the content is private. If a specific provider is required by policy, pin the routing order and disable fallbacks that could send the request elsewhere. Record the model and provider used when outputs need auditability.
Treat the key as spend authority
An OpenRouter key can authorize paid requests. Create a dedicated key for the mobile client, apply available limits, and monitor activity. Do not reuse a management key or paste the key into screenshots, issue reports, or chat prompts. Store the secret using an app-protected mechanism backed by Android Keystore cryptography where appropriate, and revoke it immediately if the device or backup is compromised.
Local encryption reduces casual extraction but cannot make a secret safe on a fully compromised or unlocked device. The provider account should support fast revocation and low limits so a stolen key has a small blast radius. Deleting the app's copy does not automatically revoke the server-side credential; both actions belong in the incident checklist.
Choose OpenRouter for flexibility, not for offline claims
OpenRouter is useful when a user wants many models, consistent API semantics, provider fallbacks, and consolidated usage. It can be a strong optional route for difficult tasks that exceed a phone model. It still depends on internet availability, account credits, service health, and the policies of intermediaries. The result should never carry an offline badge.
Phos keeps the distinction explicit: local model for on-device privacy and resilience, local server for user-controlled larger hardware, and OpenRouter BYOK for broad hosted choice. A task can move between these routes, but the user should know before sending, not discover the destination afterward from a billing dashboard.
Direct answers
Frequently asked questions
Is OpenRouter private by default?
OpenRouter states that prompts and completions are not logged by default, but request metadata is logged and upstream provider policies still apply. Review routing and privacy settings for the selected model.
Is OpenRouter an offline mode?
No. Requests go over the internet to OpenRouter and an upstream provider. Use a phone-local model for offline inference.
Should I use one OpenRouter key everywhere?
Prefer separate limited keys per client or purpose so one leak can be revoked and audited without disrupting every integration.