Bring your own API key without losing sight of where prompts go.
BYOK changes who owns billing and provider choice. It does not make a hosted model local, remove the provider from the data path, or eliminate key-security work.
At a glance
A bring-your-own-key AI app lets the user supply a provider credential rather than using inference paid for and controlled by the app company. The app should store that key with device-protected cryptography, never log or export it, support deletion, and clearly identify the provider receiving each prompt. Phos uses BYOK as an optional online route alongside local and user-run server modes, with no company-hosted Phos inference in V1.
How Phos handles it
Three clear routes
Local model
No API key is needed for compatible on-device inference.
Local server
A personal server may use its own authentication token, separate from hosted-provider credentials.
Bring your own key
The app sends the prompt and key-authenticated request to the chosen provider; provider terms and logs apply.
Who this is for
Built for people with real private work to do.
People who already have provider accounts and want direct cost ownership.
Users who need model choice without an additional Phos subscription.
Security-conscious teams defining key rotation and incident response.
Android users deciding when a remote model is worth the disclosure.
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 |
|---|---|---|---|
| Billing owner | User's provider account. | App subscription or vendor account. | No token billing. |
| Credential storage | App-private, device-protected handling and explicit removal. | Platform manages its own backend credentials. | Usually no provider key. |
| Prompt recipient | Provider selected by user. | Platform and its inference partners. | On-device runtime. |
| Revocation | Delete locally and revoke in provider dashboard. | Sign out or close platform account. | Remove local server token if configured. |
BYOK is a commercial boundary
The user creates the provider account, accepts its terms, funds usage, chooses models, and receives provider-side logs or invoices. The client app does not need to resell tokens or operate a shared inference credential. This can reduce lock-in and make costs more transparent, especially for users who already maintain keys. It also means the app cannot guarantee provider availability, price, regional access, or data policy.
Phos's V1 economics follow that boundary: the company does not pay for hosted inference. Local models use the phone, personal servers use user-owned hardware, and BYOK uses the user's provider relationship. The interface should explain this before a request, including when a model aggregator can route to an upstream provider.
Protect the key in layers
Android's Keystore can generate non-exportable cryptographic keys and restrict how they are used. An application can use those keys to protect stored provider secrets, keeping raw material out of source code and ordinary preferences. Android's security checklist recommends defense in depth and calls API key storage a critical privacy concern. The app must also prevent keys from entering logs, crash reports, screenshots, clipboard history, exports, and diagnostics.
Keystore protection is not magic. Malware with broad device access, an unlocked compromised phone, accessibility abuse, or a vulnerable app process can still create risk. Pair local protection with provider-side controls: dedicated credentials, low spend limits, restricted scopes where supported, monitoring, and immediate revocation. The safest long-lived key is one with the least authority.
Minimize every remote request
A key grants access; the prompt carries the sensitive data. Before switching from local mode, remove unrelated names, secrets, customer identifiers, and memory. Do not attach an entire notebook when one paragraph is enough. Review whether the provider uses content for training, retains error payloads, routes through subcontractors, or offers a no-retention setting. Current policy should be checked at the time of use, not copied forever from an old comparison.
If the application uses local memory, retrieve only the items needed for the task. A database can remain on the phone while selected notes still enter a provider request. The product should show that the active route has changed and avoid automatic silent fallbacks from a failed local model into paid cloud inference.
Prepare a two-sided deletion plan
Removing a provider profile from the phone should delete the app's stored credential and stop future use. It cannot revoke a key that still exists in the provider account. Conversely, revoking the key server-side does not necessarily remove a local copy or prior chat history. Incident response must perform both actions and review recent provider usage for unexpected calls.
When a phone is lost, revoke first, then use device-management tools and rotate any related credentials. When selling or resetting a device, clear app data and verify provider profiles independently. For ordinary hygiene, rotate keys periodically when the provider supports it, use separate keys for development and personal chat, and never place a production credential in screenshots or sample configuration.
Direct answers
Frequently asked questions
Does BYOK mean prompts stay private from the provider?
No. The chosen provider receives the request. BYOK gives the user control over the credential and provider relationship, not local inference.
Where should an Android app store API keys?
Use app-private storage protected by cryptographic keys backed by Android Keystore where appropriate, exclude secrets from logs and backups, and rely on provider limits and revocation as additional layers.
Is deleting the key inside the app enough?
No. Also revoke or delete the credential in the provider dashboard and review usage. Local deletion prevents the app from using its copy; provider revocation invalidates the key itself.