Private AI assistant for thoughts that need a quieter place.
Privacy is not a single switch. A useful private assistant should show where inference happens, what it stores, which network receives a prompt, and how the user can erase the result.
At a glance
A private AI assistant minimizes unnecessary accounts and tracking, offers an on-device route for sensitive work, and clearly labels every mode that sends data elsewhere. Phos is designed around three visible boundaries: a local model on the Android phone, a user-run local server, or a provider chosen with the user's own API key. Local mode is the strongest offline boundary; BYOK is still an online provider request.
How Phos handles it
Three clear routes
Local model
The selected model runs on the Android device. Prompts do not need an inference provider, although model download and optional online features still require a network.
Local server
The phone sends the prompt to an Ollama- or LM Studio-compatible endpoint selected by the user. Privacy depends on who controls that server and network.
Bring your own key
The request goes to the chosen API provider using the user's key. Phos does not turn a remote provider request into offline processing.
Who this is for
Built for people with real private work to do.
People comparing privacy claims instead of accepting a generic 'secure AI' label.
Founders, students, and writers handling unfinished or commercially sensitive ideas.
Android users who want local inference without giving up a usable assistant interface.
Anyone who wants memory, export, deletion, and app-lock controls to remain understandable.
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 |
|---|---|---|---|
| Where inference happens | Visible local, local-server, or BYOK route. | Vendor infrastructure, often tied to an account. | On device, but setup and state may be technical. |
| Identity requirement | No Phos account is required. | Usually email, phone, or platform identity. | Usually none. |
| Memory ownership | Local controls for view, edit, delete, export, and reset. | Controlled through vendor account settings. | Depends on the client; often chat files only. |
| Best fit | Private everyday assistance with explicit route choices. | Maximum hosted capability and cross-device convenience. | Experimentation and direct model control. |
Start with a threat model, not a privacy adjective
A privacy claim is only useful when it names the thing being protected. A person journaling may care most about prompts leaving the phone. A founder may care about an idea reaching a third-party provider. A student may care about account history and analytics. Those are different threats, so no single badge can settle all of them.
For each mode, ask four questions: where does the prompt travel, where is the conversation stored, who can operate the inference system, and what can the user delete? In Phos local mode, inference and chat state can remain on the device. In local-server mode, the server operator and local network become part of the boundary. In BYOK mode, the provider's current policy still applies. This model is less catchy than '100% private,' but it is much more actionable.
- Map the prompt path before entering sensitive context.
- Separate local storage protection from network privacy.
- Check deletion, export, and reset paths before relying on memory.
Local inference changes exposure, not model fallibility
Running a model on a phone can remove an inference provider from the prompt path, which is meaningful. It does not make the model accurate, confidential against an unlocked device, or suitable for high-stakes medical, legal, or financial decisions. The phone can still be lost, malware can still target app data, and generated answers can still be wrong.
A defensible local setup therefore combines inference location with ordinary device security: a supported Android version, screen lock, restricted backups where appropriate, careful attachment handling, and an app lock for casual access. It also uses smaller local models for tasks they can handle—drafting, classification, reflection, summarization—without pretending they match every large cloud model on complex reasoning. Privacy is valuable even when capability is intentionally bounded.
Memory needs a lifecycle
An assistant that remembers preferences can be more useful than a stateless chat, but memory is also a curated summary of the user. Good memory design distinguishes the current conversation, explicitly saved facts, app settings, attachments, and generated exports. Each category needs a visible retention rule rather than one vague 'clear history' button.
Phos treats memory as something the user should be able to inspect and change. The important test is not whether the interface says 'personalized'; it is whether a user can identify what was saved, correct a mistaken note, remove a sensitive item, export useful data, and reset the local state. Cloud sync is not automatically bad, but it changes the boundary and should never be implied by a local-first claim.
A practical selection checklist
Choose local mode when the task is sensitive, the phone can run an appropriate model, and offline availability matters. Choose a user-run server when a computer has better hardware and both devices are on a network you control. Choose BYOK when model quality or a specialized provider matters more than keeping the prompt entirely local. Switching routes should be a deliberate decision, not a silent fallback.
Before trusting any assistant, turn off connectivity and test the claimed offline path. Review Android's network usage, confirm whether an account is required, inspect the memory controls, and read the provider policy for every remote route. Open-source code can improve inspectability, but it does not by itself prove that a store build matches the repository or that every dependency is harmless. Privacy comes from verifiable boundaries plus restrained product behavior.
Direct answers
Frequently asked questions
Is a private AI assistant always fully offline?
No. 'Private' can describe local storage, limited tracking, user-controlled keys, or on-device inference. Only a functioning on-device model path is fully offline for inference; BYOK and local-server routes have different network boundaries.
Does no login mean no data leaves the phone?
No. No login removes a product account requirement, but an online API request can still send the prompt to a provider. Check the active inference route separately from account creation.
Does open source guarantee privacy?
Open source makes inspection and independent verification easier. It does not guarantee a safe build, secure dependencies, correct configuration, or good data handling on its own.