- What we keep
- Your account, what you pay and how much you use, plus site usage stats you can turn off.
- What we don’t keep
- Your messages, the replies, your files or your IP address.
- Who can see your chats
- Our server and our model host handle each message only while answering it. We don’t save a copy of your messages or the replies.
- How to delete your data
- Delete saved chats in the playground, then close your account on the Account page. We still keep payment and security records, and the email, phone number or Google account you signed in with.
In detailYour messages
Your browser sends each message over an encrypted connection to our gateway, a server on Google Cloud in the US. The gateway passes it to the model, on Modal or, for Flagship, on an inference partner’s servers, and streams the reply back. None of them keeps it. There is no conversation database, and the gateway and its web server don’t log request bodies, replies or IP addresses.
This isn’t end-to-end encryption. The gateway and the model host’s machines (Modal’s, or our inference partner’s) handle your text unencrypted while they work. We don’t claim that memory is wiped afterwards, that a provider can’t inspect it, or that using decuff makes you anonymous.
Safety check
The gateway also sends each conversation, and the reply as it streams, to a small classifier model on our Modal deployment. It returns category scores and nothing else. Only child sexual abuse material is blocked: the request is refused or the reply is cut off, and the account’s hit count goes up. We keep the category, the time, which key sent it and whether it was your message or the reply, never the text. Three hits within 24 hours put the account in front of a person for review. If the check is down, requests are refused rather than sent unchecked.
What we keep, and for how long
| Record | Kept |
|---|
| Account: a random ID, when it was made, your balance | While the account exists. The ID and balance history stay after it closes. |
| Sign-in details, only the ones you choose: an email with a hashed password, a phone number, or your Google email, name and Google account ID | While the account exists, and after it closes. |
| Keys: hashes of your account, recovery and API keys, their first few characters and their labels | Until the account closes. A revoked key stops working at once. |
| Each signed-in device: a hash of its key and when it signed in. No device name, browser or IP address | Until it signs out, 90 days pass or your keys are replaced. |
| Each request: when, which model, token counts and the charge | No end date set yet. Kept after the account closes. |
| Payments: amounts, times, the Stripe or invoice reference, a one-way digest of the card, referrals | No end date set yet. Kept after the account closes. |
| Safety hits: the category, the time, which key sent it and whether it was in your message or the reply | No end date set yet. |
| Abuse reports about an account: the category, the account ID, a hash of the evidence and the time. Never the reported content | 90 days. One we act on is kept with the security events. |
| Security events: key revocations, recoveries, sign-in changes, closure | No end date set yet. Kept after the account closes. |
| A phone number you ask for a code, with the time | Until the code is used. If it never is, no end date set yet. |
| Rate-limit counters, keyed by a scrambled form of your network address or phone number | In memory only, for minutes up to a day. Gone when the gateway restarts. |
| A Breach call request: your name, work email, phone, company and answers | Not stored by the site. Sent to us as a text message so we can call you; the text stays on our phones until we delete it. |
| Free tokens used each day, by account ID | About 3 days. |
| Encrypted backups of the records above | Deleted after 30 days. Separate encrypted copies of security and payment history, kept to restore the database, have no expiry yet. |
| Analytics events, described below | PostHog’s retention setting, including after the account closes. |
Never kept: your messages, replies, reasoning, files, chat titles or IP addresses. You can download your records from the Account page.
On this device
Signed out or on the free trial, your chats are saved in this browser as you go, and the trial’s account stays signed in here until you sign out, which offers to delete them. Signed in, a chat starts in this tab’s session storage: it’s still there after a reload and gone when you close the tab or sign out, unless you save it. A saved chat stays in this browser until you delete it. Saved chats never reach our servers, and anyone who can open this browser profile can read them. Encrypted exports are for your own backups.
With “Keep me signed in on this device”, your sign-in, the email or phone number you used and the playground’s key stay in this browser until you sign out, at most 90 days for email, phone and Google. Without it, reloading signs you out. Over the onion service, sign-ins are never kept.
This browser also keeps your theme, playground settings, whether you turned analytics off, the last sign-in method you used and a note that you’ve signed in or made an account here before. When you leave the playground to sign in, to add Google or a phone to your account, or to add credits after a message couldn’t be sent, the message you were writing waits in this tab’s session storage until you’re back; signing out removes it. If you sign in with Google, Google’s code holds that sign-in in this tab only until decuff has it, then signs out of Google, so your Google account isn’t kept in this browser. It leaves a note of when it ran, with no account data; a later sign-out deletes that and anything an earlier version left.
On a shared computer, use a private window, or sign out and clear this site’s data in your browser when you’re done.
Who else is involved
| Provider | What it handles |
|---|
| Vercel | Delivers the website and relays analytics and Breach call requests. Sees connection details, such as your IP address, under its own policies. |
| Google Cloud | Runs our gateway and account database in the US, plus our payment services and encrypted backups. |
| Modal | Runs every model except Flagship, and the safety check. Handles your messages in memory while answering, and says it doesn’t store them. |
| An inference partner, only if you use Flagship | Runs Flagship. Handles your messages while answering, and has agreed not to store them. |
| Google, only if you choose Google sign-in | Google’s sign-in code loads only when you pick Google or move to a Google button. If you sign in with Google, Google confirms who you are and shares your email and name with us. |
| Twilio, only if you use a phone number or request a Breach call | Sends your verification code and sees your number. For a Breach call request, carries your request to us as a text. |
| Stripe, only if you pay by card | Handles your card and billing details. A card payment can identify you. |
| PostHog | Product analytics, masked recordings of public pages and survey answers, described below. Never messages, replies, keys, email addresses, phone numbers or IP addresses. |
| Daytona (or E2B, our fallback), only if you start a cloud computer in the playground | Runs that computer and sees the files and commands you send to it. The machine is deleted when it stops. |
Modal’s security and retention statement is the provider’s own statement, not our audit. Bitcoin and stablecoin payments are public and can link activity to a person: crypto is a way to pay, not a promise of anonymity.
Product analytics
We use PostHog to see how the site, playground and API are used. The site sends events to its own address, which drops your IP address, adds only the country Vercel has already looked up, and forwards the rest to PostHog. No PostHog or other analytics script runs in your browser. decuff sets no cookies and uses no advertising pixels, and analytics is never used for advertising.
Site events cover pages viewed, time on page and scroll depth, clicks on site controls (including repeated clicks and clicks that got no response), which main buttons came into view, where on a page clicks land and the pointer rests (page coordinates only, never on the account page or in the playground), playground actions (a message was sent, with which model and whether it used the file tools, how long the reply took and how many tokens it used), the sign-in method you picked, which sign-in and checkout steps you reached and which of their fields you focused or left invalid (never what you typed), how long before your first click, tap, scroll or key press on a page and which of those it was (never which key), page-load performance, and error reports with quoted text removed. Each event also carries the page address without most of its query string, the browser and system name, device type, screen and window size, language and theme. Events never include prompts, replies, reasoning, file contents, chat titles, key labels, keys, email addresses or phone numbers. In the playground and on the account page, a click is recorded only by the control’s fixed name, never by what it displays.
Before you sign in, events carry a random session id. It lives in this tab’s session storage and ends when you close the tab, after 30 idle minutes or after 24 hours. Events in a session also carry the domain of the site that sent you and the campaign tags of the link you followed (tags that look like an email address, a phone number or a token are dropped). After you sign in, events carry a one-way hash of your random account id. The session id doesn’t change when you sign in, so the pages you viewed earlier in that tab are linked to the account. The gateway sends the same hashed id with metadata for each API request: model, token counts, cost, latency, status and the kind of client (for example Codex, Claude Code or curl), along with account events such as sign-ups, new keys and purchases.
This tab’s session storage also remembers how you arrived: the campaign tags on the link you followed (tags that look like an email address, a phone number or a token are dropped), the domain of the site that sent you, which page you landed on and whether the link was a referral (never the referral code). A later link with a referral or different campaign tags replaces it. It stays until you close the tab, sign out or turn analytics off, even after the session id ends. If you create an account in that tab, these values stay on the account’s analytics profile, under its hashed id, so purchases can be credited to the channel that brought you.
To test changes to the site, a page may ask the site’s own address which version to show you. That request carries only the same session id or account hash and the country Vercel has looked up.
On public pages, such as the home, models and docs pages, we may record how the page is used so we can improve it: layout, scrolling, clicks and pointer movement, with every word and every input masked before it leaves your browser. We don’t record in the playground, on the account page or while you’re signed in, and never in the EU, the EEA, the UK or Switzerland.
Now and then we ask an optional multiple-choice question, with no free text, at most once every 30 days. This browser keeps only the date we last asked.
This browser sends no analytics, recordings or survey answers, and makes no such requests, when Global Privacy Control or Do Not Track is on, or when you turn it off below. The setting covers this browser; it doesn’t change the request metadata the gateway records for API usage.
If we’re legally required to hand over data
Datost Inc. is a US company, so US courts and authorities can order us to hand over data. We can only hand over what exists: the records in the table above, and what providers such as Stripe hold for us. We don’t have your chats, so we can’t hand them over, and chats saved in your browser never reach us.
An account made with an account key has no name, email or phone number attached. A card payment can be traced through Stripe. Because the gateway reads each request to answer it, an order could in principle require us to start recording an account’s future requests. Nothing in the published source records request text.
Tor onion service
Over our onion service, your connection reaches the gateway host through Tor and never touches Vercel: the gateway host fetches the site’s files itself. We see a Tor circuit, not your address, and rate limits apply per circuit. The onion service’s own server location is public, so it uses Tor’s single-hop service mode; that doesn’t weaken your side of the connection. The onion site sends no browser analytics; the gateway still records the request metadata described above. See the docs for what works over Tor.
Cache isolation
The gateway derives a different prefix-cache salt for each account and doesn’t accept one from the caller. This scopes cache reuse when the model’s engine enables and enforces prefix caching. A model’s qualification record must verify that; current tests don’t establish resistance to provider-wide side channels.
Evidence and limits
Canary checks, encrypted recovery drills and protocol tests are published on the status page, with the source code. Each has a stated scope. No independent security audit or attestation is claimed, and published source doesn’t prove what an operator or provider runs.
Your controls
On the Account page: revoke keys, sign out other devices, download your records (an unencrypted file) and close the account. Closing revokes all access and deletes keys and key labels; what stays is in the table above. In the playground: delete saved chats, or export them encrypted.