Privacy, plainly.

The short version

nokeep keeps no server-side conversation history. Your saved work stays in your browser, and model requests use Venice’s Private tier, with contractual protections against retaining prompt and response content after processing.

Conversations

Your saved conversations, images, and clips live in your browser on your own device. nokeep keeps no server copy of that history. Requests are processed by the model infrastructure described below. Your local history stays until you clear it — End now in the app erases every conversation and everything you have made, and clearing this site's data in your browser does the same.

The same is true of the workspace: projects and their files, the memory it keeps about you, and documents the model writes for you live in your browser. When you send a message, what the model needs to answer it travels with the request — the message, the conversation so far, your instructions, what it remembers about you, and any file passage the model reads. Temporary chats exclude saved memory and project context and are not persisted as chat history. Their messages, attachments, and enabled tools still use hosted processing.

We do not keep a server-side content archive or use your conversations, images, or videos to train models. Requests are processed in memory and proxied to the inference providers described below. Individual models and providers have their own behavior and limits.

Because this lives on the device, anyone with access to your unlocked browser profile can see it. If you are using a shared or borrowed machine, use End now when you finish, or a private window to limit local persistence. Downloads, screenshots, and backups are separate copies that these controls do not erase.

If you pay

Paying creates a token, not an account — no email, no name, no profile. But a credit system has to remember what it sold, so there is one record we do keep: what was bought, when, how much it cost, and each credit spent against it. It is tied to the token. Payment processors may be able to associate a payment with your identity.

Billing and usage records are separate from conversation content. The reference linking a token to the payment processor is encrypted at rest with a key held outside the database. An account key provides access; it is not a guarantee of anonymity.

What our servers do see

Like any web service, our servers momentarily see your IP address to deliver a response, and we use it to bound free allowances across visitor ids. The day’s free allowance is counted under a random id your browser makes up for itself and keeps in its own storage — so a phone whose carrier changes its address keeps one allowance rather than starting over. The id is not derived from your device, is sent only to our API, and disappears when you clear site data. Server-side, both the id and the address are stored only as a one-day hash and deleted the next day. These counters hold no conversation content. We do not run analytics trackers or advertising pixels. One narrow exception applies to the free tier: when a visitor without an account asks for a free picture or clip, the page computes a device check (a hash of browser characteristics, and whether it is a private window) and sends it only to our API, to stop one device claiming many free allowances. The server keeps it only as a one-day hash and deletes it the next day. It is never computed for accounts and never sent to a third party.

To understand product use we keep aggregate counters and coarse records of visits: referral category, device/browser/operating-system category, language and country, day and broad time band, feature-use ranges, and outcomes such as reaching a limit or paying. These records contain no prompt or response text. The server groups requests using a hash of the address and browser under a random key that rotates daily and is not persisted. The saved visit rows do not contain that identifier; small groups are suppressed in analytics queries. A browser-local visit counter supplies coarse visit-age and usage-frequency categories; clearing site data resets it.

Accounts and payments

The free tier requires no account — there is nothing to sign up for. Paid plans work through randomly generated access tokens rather than a nokeep email-and-password login. Card payments are handled by a payment processor, which necessarily sees your card details. The card form asks for a number, an expiry and a security code and nothing else — no name, no address, no phone number; an email is optional and only for a receipt. The processor is never given your token: a one-time claim code stands in for it. What we store against your token is the processor's subscription reference (without it we cannot tell whether your plan is still active), that subscription's status and renewal date, and a ledger of credits granted and spent. Never your name, your email, or anything about your card.

Inference providers

Chat, image generation, image editing, video, and voice use models on Venice’s Private tier. Inference runs on Venice-controlled GPUs or partner infrastructure covered by zero-data-retention commitments. Under that policy, prompts and responses are processed only to fulfill the request and are not retained after it completes. nokeep does not forward your IP address or browser-identifying headers to Venice.

These protections rely on provider contracts; nokeep does not currently provide end-to-end encrypted or hardware-attested inference. Operational metadata such as model names, token counts, and billing records is separate from conversation content. See Venice’s privacy documentation for the provider’s protections and retention details.

The mature filter

Before a message, image or video is made, its words are checked against our content rules by a safety model (gpt-oss-safeguard) reached through OpenRouter. Every check requires a zero-data-retention provider and refuses any that would collect data, so the text is processed only to return one label and is not kept. Finished images are checked by a model that runs on our own server; they are not sent anywhere for it.

We keep counts of what the checks decided, never the words or the pictures. With the filter on, an explicit picture comes back blurred and the real one is encrypted in your browser; we keep only its key, for one day.

Web search

Web search is off unless you switch it on, and the switch is remembered per browser. When it is on, the search runs from our infrastructure rather than your browser, so the search engine sees a request from us and never your IP address or anything about your device. It does, however, receive the text of the query itself — that is what a search is. Nothing else from the conversation is sent, and results come back through the same boundary. If a question is one you would not type into a search engine, leave the toggle off.

What we would hand over

We do not maintain a server-side conversation archive. Operational and billing records described above may exist and may be subject to legal process. Local files, exported copies, and records held by other parties are outside our history-storage controls. This design does not create legal privilege or immunity from legal obligations.

Changes

If this policy changes in any way that weakens the above, we will say so loudly on the site — not bury it in a diff.