An AI assistant without another identity trail.
Removing signup makes first use simpler and avoids tying every private thought to a new product identity, but accountless design must still disclose storage and network behavior.
At a glance
An AI assistant without login can be opened and used without creating a vendor account. That reduces identity linkage, password risk, and account-retention concerns, but it does not automatically make inference local. Phos requires no Phos account and offers on-device, local-server, and BYOK routes; only the selected local route keeps model inference on the phone.
How Phos handles it
Three clear routes
Local model
No account and no provider request are needed once a compatible local model is available.
Local server
The app remains accountless, while the user-controlled server receives the prompt.
Bring your own key
Phos needs no account, but the API provider associates usage with the supplied key or provider account.
Who this is for
Built for people with real private work to do.
People who do not want a new email, phone number, or social login attached to chat history.
Users who want to try a private assistant before deciding whether to configure a provider.
Families sharing devices who need clear local access controls rather than cloud profiles.
Privacy reviewers separating identity collection from inference location.
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 |
|---|---|---|---|
| Signup before first chat | None. | Commonly required. | Usually none. |
| Cross-device sync | Not part of the local-first V1 boundary. | Usually included through the account. | Rare unless manually configured. |
| Recovery after device loss | Local data may be unrecoverable without a user export. | Account recovery can restore server data. | Depends on files and backups. |
| Provider identity | None in local mode; BYOK provider still knows the key. | Bound to platform account. | None for on-device inference. |
No login removes one data relationship
A product account can enable syncing, billing, support, abuse prevention, and recovery. It can also connect conversations, devices, IP addresses, subscription records, and profile information under one durable identifier. An accountless assistant chooses a different default: the user can begin without establishing that relationship. This is particularly valuable for tentative questions where the person wants help before deciding whether the topic belongs in any online profile.
That benefit should be described precisely. The operating system still identifies the app installation, a provider can still identify an API key, and a network can still observe connections. Phos's no-login promise is about not requiring a Phos identity. It is not a claim that every optional route is anonymous or that Android itself stops managing the application.
Accountless and offline are separate properties
A web chatbot can allow anonymous access while sending every prompt to its servers. Conversely, a local app can require a license account while running inference on the phone. Evaluate login and inference as separate rows: who authenticates the user, and who processes the prompt? Only then can a person match the product to the threat they actually care about.
Phos local mode combines no Phos login with on-device inference. Its local-server route also needs no Phos account, but the selected computer receives the prompt. A BYOK request reaches the chosen provider and will normally be associated with the user's provider credential. The interface should make this mode transition visible because an unchanged chat layout can otherwise imply an unchanged privacy boundary.
The tradeoff is user-owned continuity
Without a cloud account, the product cannot quietly promise universal sync and recovery. Local conversation history can disappear if the app is deleted, local data is reset, the device fails, or the user clears storage. That is not automatically a defect; it is the consequence of avoiding company-controlled cloud storage. The design response is honest export and reset tools rather than pretending local data is immortal.
Users should decide which conversations deserve an encrypted personal backup or an explicit export. An assistant should not auto-upload private history merely to make migration convenient. If future sync is introduced, it should be opt-in, separately explained, and designed so the user knows the destination and retention rule. In V1, Phos favors a simpler local boundary.
How to verify an accountless claim
Install the app without using a federated identity, begin a chat, and check whether core features work before providing an API key. Review the app's privacy policy and Android data-safety disclosure, but also observe the actual mode: a no-login UI can still invoke a public inference endpoint. For local mode, repeat the chat in airplane mode after the model is downloaded.
Then check what happens at deletion. Can the user remove one memory, clear chats, reset local data, and uninstall without contacting support? Look for advertising identifiers, analytics disclosures, or background sync that contradict the product's positioning. Source availability helps reviewers trace these behaviors, while reproducible release information and store disclosures help connect reviewed code to a distributed build.
Direct answers
Frequently asked questions
Can I use Phos without creating an account?
Yes. Phos does not require a Phos login. Local models, a user-run server, or a user-supplied provider key are configured as separate routes.
Does accountless use make BYOK anonymous?
No. The provider can associate requests and billing with the API key or provider account, even though Phos itself does not require an account.
How do I move accountless chat history to another phone?
Use explicit export or backup controls where supported. A local-first app cannot guarantee cloud recovery unless the user deliberately chooses a backup destination.