Privacy Policy

For individual accounts, Ache AI is the data controller. For team and organisation workspaces where your administrator controls membership and data, we act as a data processor on your organisation's instructions; your organisation is the controller for team content and member data. A standard Data Processing Addendum (DPA) is available on request — see Data Processing Addendum below.

We store account records in encrypted, access-controlled infrastructure on self-operated application servers in the United States. Uploads are kept in isolated per-account storage. Active Code mode workspaces and their archives are stored on a dedicated runner host. We do not sell, rent, or share your personal data with advertisers or data brokers.

• Your account. Email address, an optional display name, and a bcrypt hash of your password. The plaintext password is never written down — not in the database, not in logs.
• Marketing attribution. If you open Ache from a campaign link, we may store first-touch UTM parameters (source, medium, campaign, and content) in your browser's local storage and, when you create an account, on your user record. We may also record that a landing visit carried those parameters for first-party measurement. This data is not sold, rented, or used to build advertising profiles for third parties.
• Sessions. When you sign in, the server creates a random session token, stores only its hash, and sets the original token as a cookie. The session row also keeps the browser user-agent string and the IP address you signed in from, so you can tell a real session from a stolen one. Sessions expire after 30 days.
• Chats. Conversation titles, every message you send, every reply Ache generates, which tools ran, the web sources cited, token counts, and response times. This is what makes chat history and follow-up questions work.
• Memory. The facts you or Ache save to memory, exactly as written. You can read, delete, or wipe all of them from the Memory tab of your dashboard.
• Uploads. Images you attach (PNG, JPEG, WebP, GIF, up to 5 MB) are written to disk under your user ID and served only to you. Text files are read into the message rather than kept as separate files, which means the text lives in your chat history instead.
• API keys. Keys for the OpenAI-compatible /v1 endpoint are stored hashed, alongside a short visible prefix, a name you choose, and counters for requests, tokens, and searches. The full key is shown once, at creation, and never again.
• Usage records. Per-request rows with token counts, search counts, latency, and whether the request errored. No message text is copied into these. That includes API web-research calls: search counts only, not the query.
• Error logs. When something breaks, the server may record the error message, stack trace, request path, and your user ID if you were signed in. We design logging to avoid message content where possible.
• IP addresses. Used in memory as the key for rate limiting, and stored on session rows as described above.
• Teams and projects. Team names, membership and role records, invitations, audit events, budgets, shared API-key metadata, team memory, notification preferences, and any webhook URL that a team administrator configures.
• Code mode. Project metadata, task and collaboration activity, repository references, and workspace/archive metadata needed to operate Code mode. Repository files are processed inside the isolated code workspace while a project is active.
• Connected-service credentials. GitHub and Vercel access tokens and Supabase personal access tokens are stored encrypted at rest when you choose to connect those services. They are used only to provide the connection you requested and are deleted when you disconnect it.
• Bring-your-own-key (BYOK). If you add provider API keys, we store them encrypted and may route requests to that provider under its terms. We do not use BYOK traffic to train models.
• Optional payment records. If you submit a crypto top-up, Ache records the chain, transaction identifier, amount, confirmation state, and credit outcome so it can verify and account for the deposit.

Summary for California residents: We collect identifiers (email, name), internet/network activity (sessions, IP for security), user-generated content (chats, uploads), and commercial information (usage/credits). Sources: you, your device, and service operation. Purposes: provide the service, security, support, and billing. We do not sell or share personal information for cross-context behavioural advertising. See Retention for how long we keep data.

We use your data only to operate Ache and to protect the service from abuse. Your chats are not used to train models, are not profiled for advertising, and are not shared with data brokers.

Our legal bases include performing our contract with you (running the service), legitimate interests such as security and abuse prevention, and consent where required (for example, optional campaign attribution).

We process personal data on the following bases:

• Contract — to create and operate your account, deliver chat/API/Code mode, store your content, and provide support you request.
• Legitimate interests — to secure the service, prevent abuse, maintain audit logs, measure first-party signup attribution, and improve reliability (balanced against your rights; you may object as described below).
• Consent — where required, for optional campaign attribution stored beyond what is strictly necessary; you may withdraw consent at any time by clearing local storage and emailing [email protected].
• Legal obligation — where we must retain or disclose information to comply with applicable law, lawful requests, or regulatory obligations.

Optional marketing attribution is used only for first-party visit and signup measurement.

We do not make solely automated decisions about you that produce legal or similarly significant effects. Rate limiting and abuse detection may use automated signals (e.g. IP and usage patterns) to protect the service; you may contact [email protected] to request human review of a restriction affecting your account.

If your organisation uses Ache for work, your organisation is the data controller for prompts, files, team content, and connected-service data you submit. Ache AI acts as a data processor when we store and process that content only to provide the service you configure.

Team administrators control membership, roles, integrations, webhooks, and budgets. Authentication and team administration events are recorded in an audit trail. See our Trust Center for subprocessors and security controls.

Business and organisation customers that require a Data Processing Addendum (DPA) may request Ache's standard DPA by contacting [email protected].

Our DPA covers Ache's processing of Customer Personal Data, subprocessors, security obligations, data subject requests, international transfers, deletion, and other applicable data protection requirements.

Current standard DPA: version 1.2 (8 September 2026). The full agreement is provided by email after your request — it is not posted publicly. A countersigned copy is available if your procurement process requires one.

Request a DPA

By default, requests are processed on infrastructure we control. If you select an externally hosted model, the prompt, relevant conversation context, attachments, and generated response are sent through the Ache backend to the provider that answers the request.

For most credit-funded models, the product shows the model you selected. Credit-funded routes use Ache ZDR (default) or Ache Expanded (optional opt-in) depending on whether the model has an eligible Zero Data Retention provider — see External model providers below. Other credit routes (direct model APIs, free pool) follow different policies. BYOK routes use your key and your provider's terms. See our Trust Center for a route-by-route breakdown.

Your browser does not connect to model providers directly. Requests are proxied through the Ache backend, which keeps provider credentials server-side.

Primary account data is processed in the United States. External model providers may process requests in their own regions when you select them. If you are in the EEA or UK, we rely on appropriate safeguards for international transfers where required by law.

Where personal data is transferred from the EEA, UK, or Switzerland to countries without an adequacy decision, we rely on appropriate safeguards such as the EU Standard Contractual Clauses (and, for UK transfers, the UK International Data Transfer Addendum or UK IDTA, as applicable), supplemented by technical and organisational measures described in our Trust Center. A copy of our transfer safeguards is available on request at [email protected].

When you select an externally hosted model, that provider receives the prompt, relevant conversation context, attachments, and generated response needed to answer. Ache does not use your chats to train models.

Credit-funded models (models that spend Ache credits — labelled aik in /models) route through operator infrastructure. Ache does not train on your chats. Upstream handling depends on the route:

• Ache ZDR (default for credit-funded models with an eligible Zero Data Retention provider) — requests route only to ZDR-classified upstream providers. Each request sets data_collection: deny with ZDR routing enabled. Upstream ZDR providers do not retain prompts for training or logging beyond what is necessary to complete inference. Ache applies always-on prompt-injection protections and sensitive-information detection before forwarding; these safeguards cannot be turned off or overridden by you, your API keys, or request parameters.
• Ache Expanded (optional opt-in for credit-funded models without an eligible ZDR provider) — you must enable Expanded Model Access in account settings or use an Expanded API key. These models are not ZDR-classified, but Ache still sends requests with training denied (data_collection: deny) — your prompts are not used to train models. Upstream providers may retain sanitized prompts according to their own policies. As with Ache ZDR, prompt-injection protections and sensitive-information detection are always on and cannot be disabled or overridden.
• Direct model API routes (some credit models) — stateless inference APIs with model-improvement opt-in disabled on our operator account; prompts are not used to train models.
• Renewable free-pool routes (ache/free*, ache/auto) — operator API keys to third-party inference APIs under their standard API terms (not consumer chat apps). These routes do not receive the same Ache ZDR or Ache Expanded configuration as paid credit-funded routes. Do not use them for confidential work without reviewing each possible upstream.

Ache still stores your chat history in our database unless you use Incognito or delete conversations. See our Trust Center for a route-by-route breakdown.

BYOK models use your API key and are billed by your provider, not Ache credits. Training, retention, and zero-data-retention are governed entirely by the agreement between you and that provider. Ache proxies the request and stores chat history like any other chat unless you use Incognito. See Bring-your-own-key routing below.

The live model catalogue — including which models are credit-funded vs BYOK — is at /models. For upstream routing details on credit-funded models, contact [email protected].

BYOK provider keys are stored with AES-256-GCM encryption at rest and are never returned after save. Requests pass through the Ache backend so we can authenticate you, enforce team policy, apply rate limits, and deliver the response — Ache remains in the request path even when your key pays the provider.

BYOK is your provider relationship: you choose the vendor, you pay them, and their API terms control training, retention, and zero-data-retention — not Ache credits or Ache's operator infrastructure. Ache does not use BYOK traffic to train models.

There is currently no BYOK mode that retains zero prompt or output content while still saving chat history. For conversations you do not want written to our database, use Incognito — understanding that web search still sends queries to Tavily when enabled. Your provider's own API terms govern what the provider retains when your key is used.

These services receive data only when the related feature is used or enabled. A current subprocessor list is maintained in our Trust Center.

• Tavily — web search. When web search runs — in a chat with search on, or through the authenticated POST /v1/web research gateway — Ache sends the search query to Tavily and receives results under Tavily's privacy policy. Turn web search off on a chat, or disable it on an API key, and that path is not used. We store search counts for quota and billing, not query text in usage rows. Ache does not send a stable Ache customer identifier to Tavily beyond what is inherent in the HTTP request (for example, our server IP and API authentication). Tavily's retention, training, and analytics practices are controlled by Tavily, not Ache.
• Resend — email delivery. Verification and password-reset emails go out through Resend, along with team invitations and optional team notifications. That means recipient email addresses and the message content are handled by Resend.
• Cloudflare — network transit. Traffic to ache.lol passes through Cloudflare's network, so Cloudflare sees connection metadata such as your IP address in the ordinary course of routing and DDoS protection.
• Hosted model providers. Credit-funded models use Ache ZDR or Ache Expanded operator routing; other credit routes and BYOK use direct APIs or your key. See /models for the current list and catalog labels.
• GitHub, Vercel, and Supabase. These receive requests only after you connect the relevant integration or approve a Code mode action. GitHub can receive repository and pull-request operations; Vercel can receive project, deployment, and environment-variable operations; Supabase can receive project metadata and approved SQL.
• Blockchain and price services. Optional crypto top-ups are checked against public chain explorers/RPC providers and a price service. The transaction identifier, public wallet address, amount, and chain are necessarily visible to those services.
• Composio — connected apps. When you use managed integrations, OAuth and tool execution may be handled through Composio for the connections you authorise.
• Sentry — error monitoring. When configured, scrubbed error metadata (stack traces, request paths, and user ID when signed in) may be sent to Sentry. Message content is excluded by design.
• Team webhooks. A team administrator can configure a webhook endpoint. When a subscribed team event occurs, Ache sends that endpoint the event name, team ID, timestamp, and event details chosen by the feature. The administrator controls that destination and is responsible for it.

We do not use analytics scripts, advertising pixels, session recorders, or third-party tag managers in the frontend.

Incognito is enforced on the server, not hidden in the interface. An incognito conversation is held in the server's memory and never written to the database — no messages, no titles, and no conversation-linked chat rows. Memory is neither read nor written. File and image uploads are unavailable in Incognito because storing one would break that promise.

Incognito does not apply to Code mode workspaces — Code mode has its own disk lifecycle described below. Usage and billing metadata (token counts, latency, credit charges) is still recorded for incognito turns, without linking to a stored conversation ID.

Incognito entries are removed when the server process restarts (immediate) or by an automatic sweep of entries older than 24 hours, whichever comes first. The 24-hour window exists so you can reload the page or continue a session without writing to the database; it is not a promise of zero retention while the tab is open. Incognito is server-enforced RAM-only storage, not end-to-end encrypted ephemeral messaging.

Web search still works in incognito and still sends the query to Tavily. External model providers still receive prompts under the relevant route. Incognito limits what Ache stores in our database; it does not change third-party handling or remove data from server memory until restart or the sweep below.

• ache_session — an httpOnly session cookie holding a random token. It is what keeps you signed in, it expires after 30 days, and it is not readable by JavaScript.
• ache_dev — set only for administrative console access. Regular users never receive it.

Your browser also keeps preferences in local storage:

• Light or dark theme and whether the chat sidebar is collapsed.
• Recent command-palette entries.
• First-touch campaign parameters under ache_utm_attribution, when present.

Theme and UI preferences stay on your device. Campaign parameters may be sent to the server when you land with a campaign link (to count the visit) and again when you sign up (to store attribution on your account), as described above.

Essential cookies (session, admin console) do not require consent. Optional first-touch campaign parameters are stored only after you visit via a campaign link; where local law requires consent for non-essential storage, we rely on your continued use after the disclosure in this policy or you may clear ache_utm_attribution in your browser.

You can delete or revoke the following at any time from the product:

• Conversations — from the chat sidebar; deleting a conversation removes its messages. Chats are kept until you delete them; we do not currently offer automatic expiry after a fixed number of days (for example 7 or 30). If you need time-bounded retention, delete conversations manually or contact [email protected] for team options.
• Memory — individually or all at once from the dashboard.
• API keys — from the dashboard.
• Sessions — ended on sign-out, password change, or expiry (30 days).
• Incognito data — removed from memory within 24 hours, as described above.
• Connected services — disconnecting GitHub, Vercel, or Supabase removes the stored credential from Ache. Provider-side records remain governed by that provider.

Typical retention periods:

• Account, chat, memory, uploads — until you delete them or delete your account.
• Sessions — 30 days or until sign-out/password change.
• Usage and billing records — while the account is active and up to seven years for accounting, tax, and dispute records.
• Security and audit logs — up to 12 months unless a longer period is required for an investigation or legal obligation.
• Encrypted backups — up to 30 days after deletion from production; not accessible through the product during that window.
• Incognito conversations — up to 24 hours in memory, as described above.
• Code mode workspaces — see the Code mode section below for archive and deletion timelines.

Backups. When you delete data from the product, it is removed from production databases and file storage promptly. Encrypted infrastructure backups may retain copies for up to 30 days before rotation. Deleted content is not available through Ache during that period. Backups are encrypted at the storage/infrastructure layer; backup encryption keys are controlled separately from application database access.

Other data is kept while your account is active and you have not deleted it. Deleted data is removed from production promptly; encrypted backups may retain copies for up to 30 days before rotation. Third-party providers may retain data under their own policies after you disconnect or delete your account.

After account deletion, we remove personal data from production systems without undue delay (typically within 30 days). We may retain minimal records where required by law (e.g. fraud prevention, tax, or legal claims).

Deletion does not require removal of information that has been anonymised or aggregated, or that we must keep to comply with law, enforce our terms, or resolve disputes.

You can delete your account from Dashboard settings after confirming your password. That removes account data held by Ache, including chats, memory, uploads, and API keys. If you cannot access your account, email [email protected] from the address on it.

Code mode runs each active project in a dedicated Firecracker microVM on runner infrastructure we operate. Each workspace gets its own guest VM with an isolated root filesystem; workloads on a runner host are separated at the hypervisor level, not merely by a shared container namespace. The Ache control plane talks to the runner over an authenticated API; repository files for an active project live on that workspace disk while the project is active. Credentials (GitHub, Vercel, Supabase tokens and BYOK keys) are encrypted at rest with AES-256-GCM using server-side keys separate from user passwords. Workspace repository files rely on full-disk encryption on the runner host; we do not separately encrypt individual files inside the workspace beyond that infrastructure protection.

Lifecycle (defaults):

• Active use — workspace disk persists while you work on the project.
• Idle archive — after about 30 minutes of inactivity, the workspace is checkpointed and archived locally on our infrastructure (your GitHub repository is never modified or deleted by this process).
• Warning — about 25 days after archive, we email the account holder that local workspace data will be deleted soon.
• Deletion — about 30 days after archive, the local workspace and archive checkpoint are deleted from our runner infrastructure. GitHub, Vercel, and Supabase remain governed by those providers.
• Reopen — opening an archived project before deletion restores it to active status and resets the retention clock.
• Manual delete — deleting a Code mode project from the product deletes its local workspace promptly.
• Account deletion — deleting your Ache account removes associated Code mode project records and triggers workspace cleanup; GitHub-side repositories and commits you created remain under GitHub.

Exact timing may vary slightly with sweeper intervals and operational events. Contact [email protected] if you need confirmation for a specific project.

We design logging and monitoring to avoid message content where possible:

• Usage and billing rows store token counts, search counts, latency, and error flags — not prompt or response text.
• Authentication and team audit logs record account and administration events (sign-in, API key create/revoke, team role changes where logged) — not chat content.
• Error monitoring (Sentry, when enabled) receives scrubbed error metadata. Authorization headers, cookies, and secret-like fields are stripped before send. Message content is excluded by design.

Prompts, source code, secrets, environment variables, and tool outputs should not appear in routine application, security, or audit logs. A software defect or misconfiguration could theoretically cause content to appear in an error log; we treat that as a security issue to fix. If you believe sensitive content was logged, contact [email protected].

We implement technical, administrative, and organizational measures designed to protect your information from loss, misuse, and unauthorized access, disclosure, alteration, or destruction — including encryption in transit, encrypted credentials at rest, hashed passwords and session tokens, authentication audit logging, rate limiting, CSRF protection, SSRF validation, sanitised markdown rendering, and automated security checks in our release pipeline.

Transport (TLS). Data in transit between your clients and ache.lol is encrypted with TLS. Plain HTTP requests receive a 301 redirect to HTTPS. HTTPS responses include HTTP Strict Transport Security (HSTS) with a one-year max-age. Subdomain inclusion and HSTS preload are not enabled yet.

Passwords, sessions, and API keys. Account passwords are stored only as bcrypt hashes — the plaintext password is never written to the database or logs. Session tokens and OpenAI-compatible API keys are stored as SHA-256 hashes (API keys keep a short visible prefix for identification). Compromise of the password or token store does not yield usable plaintext secrets.

BYOK and connected-service credentials. Bring-your-own provider API keys and GitHub, Vercel, and Supabase tokens are stored with AES-256-GCM encryption using dedicated server-side encryption keys (distinct from your password). Keys are decrypted only when executing an action you authorised. We use OAuth and provider-scoped tokens where the provider supports them. Compromise of Ache's credential storage would still be serious — we limit key access to production operators and rotate encryption keys on compromise.

Account records and backups. Account and service data live in access-controlled production infrastructure. When you delete data from the product, it is removed from production promptly. Encrypted infrastructure backups may retain copies for up to 30 days before rotation; deleted content is not available through Ache during that window. Backup encryption is at the storage/infrastructure layer, with keys controlled separately from ordinary application database access.

Sign-in security. You can verify your email address (required for API access, uploads, web search, and Work mode) and optionally enable an authenticator app (TOTP) as a second step when signing in. Manage both in Dashboard → Settings → Security.

Export and delete. You can download a full JSON export of your account data or permanently delete your account with a single button in Dashboard → Settings → Data & account. Deletion requires your password to confirm.

Independent verification. We have not published SOC 2 Type II, ISO 27001, or an independent penetration-test report. Our controls are described in this policy, our Trust Center, and our security policy. We can answer common security questionnaires on request for business customers.

Breach notification. If we become aware of a breach that poses a significant risk to your personal data, we will notify affected users and regulators as required by applicable law. Our internal target is to notify affected users within 72 hours of confirming a qualifying breach, even when local law allows longer.

No method of transmission over the Internet or electronic storage is completely secure. We encourage you to use a strong, unique password and to keep your API keys confidential. To report a security issue, contact [email protected] — see our Trust Center and security policy.

We access stored content only to operate the service (for example, to run a model, deliver chat history to you, or execute a Code mode action you approved), respond to your requests, investigate abuse or security issues, comply with law, or fix problems you report. We do not use your conversations for advertising or model training. Administrative tools show account metadata, usage totals, and error reports — not a general-purpose browse of your chat history. Automated systems may scan for abuse signals; human review is limited to safety, security, and legal compliance — not product improvement through training on your content.

Employee and operator access. Ache AI is operated by a small team. There is no standing customer-support console for browsing chat history. When stored content must be accessed (for example, to reproduce a bug you reported or investigate abuse), access is limited to the minimum scope needed for that purpose.

Today we log authentication and team administration events in audit trails, and dev-portal administrative actions in an admin audit log. We are extending production logging so that direct operator access to customer chat content or Code mode workspace files is recorded with actor, timestamp, reason, and scope, and reviewed periodically. Until that system is fully deployed, content access remains limited to least-privilege production practices without a self-service operator browse UI.

Ache is not built for children and is not directed at them. Do not create an account if you are under 13, or under 16 in places where that is the local threshold for consenting to online services on your own. If we learn that an account belongs to a child below that age, we will delete the account and its data.

If you believe a child under the applicable age has created an account, contact [email protected] from the email on the account (or, if you are a parent or guardian, describe the account). We will verify and delete it.

Depending on where you live, you may have the right to:

• Access — receive a copy of personal data we hold about you.
• Rectification — correct inaccurate data (account settings or by contacting us).
• Erasure — delete data, including via account deletion as described in Retention.
• Restriction — ask us to limit processing in certain circumstances.
• Portability — receive data you provided in a structured, machine-readable format (Dashboard → Settings export).
• Objection — object to processing based on legitimate interests, including profiling for abuse prevention where applicable.
• Withdraw consent — where processing is based on consent (e.g. optional attribution), without affecting prior lawful processing.

Submit requests from your account email to [email protected]. We verify identity before fulfilling requests and respond within 30 days (or up to 60 days where permitted, with notice). You may use an authorised agent where your local law allows.

We do not sell or share personal information for cross-context behavioral advertising. If you are in the EU or UK, you may also lodge a complaint with your local data protection authority.

California and US state privacy rights. We do not sell personal information and do not share it for cross-context behavioural advertising. California residents may request access, deletion, and correction, and may not be discriminated against for exercising these rights. To appeal a denied request, reply to our response email within 30 days.

We do not use or disclose sensitive personal information (as defined under California law) for purposes other than providing the service you request. We do not use sensitive personal information to infer characteristics about you.

If what the software does changes, this page gets updated to match, and the date at the top moves. Material changes — a new third-party subprocessor or a new category of stored data — will be announced in the app or by email at least 30 days before they take effect where practicable. Continuing to use Ache after a change means you accept the updated policy.

Ache AI is offered from the United States. Disputes about this policy are governed by the laws of the State of Delaware, United States, excluding its conflict-of-law rules, unless mandatory consumer-protection law where you live requires otherwise. Courts in the State of Delaware have non-exclusive jurisdiction unless your local law requires a different forum.

To the fullest extent the law allows, our liability arising out of the handling of your data is limited to direct damages and excludes indirect, incidental, and consequential loss. Nothing here limits liability for fraud, wilful misconduct, or anything else that cannot lawfully be limited. The Terms of Service covers the rest.