Can you use Whizi offline?

The short answer

No. Whizi has no offline mode. To generate a response Whizi sends the information reasonably needed for the request to OpenRouter and a routed model provider, or to another provider used by the selected feature, so an answer is always a network round trip to a company other than Whizi. Hosting, synchronized chats, media, account state, usage limits, reports, and security and operational processing all run on Cloudflare Workers, D1, R2 and Durable Objects, which means the conversation you are typing into lives on the server too.

The model list is server-side for the same reason. The picker is served by the Whizi backend at GET /api/models, and the model lists hardcoded into the web and mobile clients are offline fallbacks only, used when that call cannot be reached. A fallback list is a list, not a model: seeing a name in the picker when the network is gone does not mean anything behind it can answer.

What needs a connection	What happens on your device
Every model reply, on every plan	The theme you chose, saved to local storage and restored on your next visit
Loading your chat list and any conversation	Parsing a ChatGPT or Claude export file, which the browser reads before anything is posted
Sending a message, editing one, switching versions	Building the .xlsx or .docx from a file card in an answer
Web search, voice, image generation	The mobile app cache of recent conversations, described below
Uploading a file, and viewing stored media through its signed URL

What the mobile app keeps on the device

The privacy policy is specific about this. The mobile app may keep a local cache of up to 40 recent conversations on a signed-in or guest device, and that cache is not a separate cloud backup. How it is cleared, and where everything else on the account sits, is in where Whizi stores data.

A cache of recent conversations is not an offline reading mode, and it changes nothing about where the work happens. Conversations and messages are kept on the account until you delete them or delete the account, and a new reply still has to reach a provider over the network.

Your plan is resolved on the server too. Billing is per individual account, with tier derived in exactly one place from that account's own subscription. See Whizi on mobile for how the two platforms share one account.

A connection that drops in the middle of a reply

Generation runs in a per-conversation Durable Object on the server, so closing the tab mid-stream does not kill the answer and the reply is still persisted. A reopened tab or a second device can reattach to a generation already in flight through GET /api/conversations/:id/generate/active. Come back, reload the conversation, and read what was saved.

There is one narrow window at the very start where that does not apply. If the client disconnects before the upstream connect completes, the server records Generation aborted before it started. and answers HTTP 408 with an empty body, so nothing reached a model.

Stopping is server authoritative rather than client side: the coordinator cancels the provider read, saves the partial answer, releases the lock and refunds an undelivered turn. The full set of mid-stream strings and what each one means is in a message will not send.

The strings you see when the call cannot complete

Whizi surfaces the failure of whichever call was in flight rather than one generic message, so the string you get depends on what you were doing. Each is quoted verbatim, with the condition it is documented for.

String	Documented condition	Where it is covered
Failed to send message.	The website fallback toast when a send fails and the backend supplied no message	message not sending
Could not load your chats. Please refresh to try again.	The toast shown when the chat list fails to load	message not sending
Failed to retrieve session token.	Thrown whenever the token fetch returns nothing before a chat list, chat load, delete, rename or upload call	login and account access
The import could not be finished. Check your connection and try again.	Any other upload failure during an import run	chat import errors
Something went wrong. Please close and try again.	The share dialog generic error, shown only when the failure carries no message of its own, such as a dropped connection or an HTML error page	share a conversation
The realtime voice connection failed.	Shown on a websocket error event	voice mode not working
The realtime voice connection was closed.	Shown when the websocket closes after setup completed	voice mode not working
Connection error	The voice overlay state label for a failed voice session	voice mode not working
That didn't send. Check your connection and try again.	The feedback fallback for every other failure	troubleshooting

Voice deserves one clarification, because its architecture reads like independence and is not. The worker mints a short-lived token and the browser opens a WebSocket straight to Google, so no audio ever passes through Whizi backend servers. That is a privacy property, not an offline one: the socket to Google is still a socket, and the session token that opens it is minted by the worker.

What to do before you lose signal

None of these give you a working model without a connection. They are about not being stuck without your content.

Take your data with you. GET /api/account/export returns the account data as one downloadable JSON file, reachable as Export Data in Settings under Account. The caveat that matters offline: media is exported as metadata plus a signed URL rather than inlined bytes, so the JSON keeps the record while the image itself still needs fetching. What the account holds is laid out in where Whizi stores data.

Get an answer out as a file while you still have signal. A chat answer can emit a fenced block that the website renders as a file card and turns into a real .xlsx or .docx in the browser. The build is local, the answer that produced it was not.

Import when you land, not on the way. Picking the export file is local work and the upload is not, though a connection that drops during one costs nothing, since every conversation is keyed by account plus source plus source id and lands once. The failure strings are in chat import errors.