Privacy Policy

This policy explains what personal data Caveman Labs, Inc. collects through caveman.so, Caveman Cloud, the caveman CLI, our other tools, the Caveman Language Codex plugin and the Caveman Mode browser extension, why we collect it, who receives it, how long we keep it and how you can control it. Questions, requests and complaints go to contact@caveman.ac.

Summary

The full policy below governs. This is the short version.

• Caveman Labs, Inc. is a US company. We decide how personal data is used for our Website, accounts, billing, support, CLI telemetry, security logs and Product Data Sharing. For the traffic you route through Caveman Cloud, we act on your behalf under our Data Processing Agreement.
• The Website sets no cookies. It runs cookieless analytics, including session replays with every form field masked, and it records which AI agents and crawlers read it.
• Caveman Cloud keeps your request history and the redacted, encrypted bodies of your requests and responses until you delete them, on every plan. Admins can set a deletion window, and on paid plans can turn body storage off.
• On the Free plan, your content is part of the price: what reaches Caveman Cloud from a Free account may be used to improve Caveman's own models, and we ask you to agree to that on its own screen at sign-up. On Pay-as-you-go it is off unless an Admin turns it on or the Workspace kept an earlier setting from the former Indie or Team plans. On Enterprise it is never on.
• We forward your requests to the Model Providers you choose, using your own API keys, which you can pass with each request or store with us encrypted. We add no markup to tokens and do not resell them.
• The caveman CLI sends pseudonymous usage telemetry by default. That telemetry never includes prompts, completions, file paths or credentials. Turn it off with caveman telemetry off.
• With routing on, the CLI sends your latest message, the one before it and the end of the agent's last reply to Caveman Cloud to pick a model. The text is dropped after the decision unless the Free router-learning conditions described below apply. Turn routing off with caveman off routing.
• The Caveman Language Codex plugin collects no data. Caveman receives no conversations, files or usage data through its skills. Your AI host handles conversations under its own policies and settings.
• The Caveman Mode browser extension collects nothing and makes no network requests.
• We do not sell personal data, share it for cross-context behavioural advertising, or show ads.
• You can ask to access, correct, delete or export your personal data, and you can object to how we use it.

At a glance

Each row is explained in full further down.

Who we are

Caveman Labs, Inc., a Delaware corporation, 1209 Orange Street, Corporation Trust Center, Wilmington, Delaware 19801, United States ("Caveman", "we", "us"), is the controller of the personal data described in this policy, except where we say we act on behalf of a Customer. A controller is the party that decides why and how personal data is used. You can reach us about anything in this policy at contact@caveman.ac.

If we are required to appoint a representative in the EU or UK under Article 27 GDPR / UK GDPR, we will list their details here.

Terms used in this policy

• "Website" means caveman.so and docs.caveman.so.
• "Caveman Cloud" or the "Services" means our hosted service: the LLM gateway (api.caveman.so), the dashboard (app.caveman.so), the control API and the features built on them.
• "Workspace" means a customer organisation in Caveman Cloud.
• "Customer" means the business, other organisation or individual that holds a Workspace or has signed an Order Form with us. "You" means the person reading this policy, whether you act for a Customer or on your own.
• "Plan" means the Free, Pay-as-you-go or Enterprise plan that applies to a Workspace.
• "Customer Data" means the content and data a Customer routes through, imports into or stores in Caveman Cloud, including Payloads and Usage Metadata.
• "Payloads" means the bodies of requests sent to Model Providers and of their responses, and content imported from a Customer's own traces and logs.
• "Usage Metadata" means the measurements and labels recorded about each request, described in the Caveman Cloud section.
• "Model Providers" means the third-party AI model providers a Customer reaches through Caveman Cloud with its own API keys or accounts.
• "Open-Source Tools" means our software and models published under an open-source or other public licence, including the caveman CLI.
• "Caveman Mode" means our browser extension.
• "Product Data Sharing" means the setting under which Payloads and Usage Metadata may be used to improve Caveman's own models.
• "Data governance" means the dashboard page where Workspace Admins manage retention, payload storage and Product Data Sharing, and where the Workspace owner can delete Workspace data.

Scope and our role

This policy covers personal data we handle through the Website, Caveman Cloud, the Open-Source Tools, the Caveman Language Codex plugin and Caveman Mode. It also covers personal data we receive when you email us, book a call with us, or deal with us as a customer, prospect or supplier.

It describes how the Services work at the date of this version. Some features are previews or are switched on for some Workspaces only. Where a feature is built but not yet switched on, we say so.

Where we are the controller

We are the controller for personal data in:

• the Website, including waitlist sign-ups, analytics and hosting logs;
• Caveman Cloud accounts, sign-up checks, sign-in and sessions;
• billing and the customer relationship;
• support requests and other messages you send us;
• CLI telemetry;
• security, audit and abuse-prevention logs; and
• Payloads and Usage Metadata used under Product Data Sharing, for the purpose of improving our models.

Where we act for our Customers

For Customer Data, we act as a processor under the GDPR and UK GDPR, and as a service provider under US state privacy laws. The Customer is the controller. It decides what data passes through the Services, how long it is kept and who in its organisation can see it. Our Data Processing Agreement governs this processing and takes precedence over this policy for Customer Data.

If you are an end user of a Customer's application, or a developer whose details appear in a Customer's repository, please send requests about Customer Data to that Customer. If you contact us instead, we will pass your request to the Customer where we can identify it, and we will help the Customer respond.

The exception is Product Data Sharing. Where it applies, we use Payloads and Usage Metadata to improve our own models as an independent controller. The section on Product Data Sharing explains how.

Dedicated and self-hosted deployments

An Enterprise deployment can run in the Customer's own cloud account, operated by Caveman under a separate written agreement. A customer-operated deployment, where separately agreed, also uses that Customer's environment. Request content, traces, artifacts and operational telemetry are stored in the deployment's configured databases, object storage and backups. These deployments retain data for platform functions such as replay and evaluation; they are not zero-data-retention services. Enterprise customer content is not used to improve Caveman's models.

The deployment agreement identifies the account and region, operational and support access, permitted transfers, and retention and deletion responsibilities. Keeping storage in the Customer's account does not mean Caveman has no access when we operate or support the deployment. Where we process personal data on the Customer's behalf, the deployment's data-processing agreement applies. Customer-selected model providers and integrations receive data according to the Customer's configuration. Using Caveman's hosted gateway or hosted routing is a separate use of the hosted service.

Installation licence verification is offline. The caveman CLI's usage telemetry is separate: it is on by default even when the CLI signs in to a Customer's own installation, and reaches Caveman as described under CLI telemetry. This includes a random install ID and the IP address recorded by the receiving service, but not prompts, responses, code or file paths. Turn it off with caveman telemetry off, CAVEMAN_TELEMETRY=0 or DO_NOT_TRACK=1. Support messages, billing contacts and other information sent directly to Caveman are also covered by this policy.

Model Providers and other third parties

When a Customer sends a request through Caveman Cloud, we forward it to the Model Provider the Customer chose, using the Customer's own API key or account. The Model Provider handles that data under its own agreement with the Customer. Model Providers are not our sub-processors. This policy does not cover how Model Providers, GitHub, Google, Cal.com or any other third-party service use personal data. Their own privacy policies apply.

Website

Information you give us on the Website

• Waitlists. If you join a waitlist, we collect your email address, any note you add and the source of the sign-up, such as the page you used. Your browser sends the entry straight to Supabase, where we store it, so Supabase's request logs also record your IP address. We also attach your email address to that visit's analytics, as the section on product analytics explains.
• Contact. The contact page offers an email link and a booking link. If you email us, we receive your email address, your name and whatever you write.
• Booking a call. If you book a call through Cal.com, Cal.com collects the details you enter, such as your name, email address and any notes, and shares them with us so we can hold the meeting.

Information collected automatically on the Website

• Hosting and security logs. Our hosting provider (Vercel) and our network provider (Cloudflare) record standard request data when you visit, including your IP address, browser user agent, the URL requested and the time. Cloudflare also uses this data to detect and block attacks and abuse. These providers keep their logs for a limited period.
• Browser storage. The Website sets no cookies. It saves a few preferences in your browser's local storage, such as whether you dismissed a banner and cached GitHub star counts. These values stay on your device and are never sent to us. The Cookie Policy lists each one.
• GitHub star counts. Some pages show star counts for our GitHub repositories. Your browser fetches these directly from api.github.com, so GitHub receives your IP address and browser details under its own privacy statement.
• Booking widget. The Cal.com booking script loads only when you hover over, focus or click a booking button. Once it loads, Cal.com receives your IP address and browser details.
• Product analytics. The Website runs cookieless product analytics with PostHog, including session replays with every form field masked. The section on cookies and product analytics explains what it collects.
• Automated clients. When a crawler, AI agent or other automated client requests a page, the Markdown version of a page or a machine-readable file (such as llms.txt or openapi.json), or calls our /mcp or /ask endpoints, we record its name as its user agent claims it (such as GPTBot), the path, the kind of endpoint, the request method and the format served. We never record the query or request body, the client's IP address or its full user agent. For a client we do not recognise by name, a Do Not Track or Global Privacy Control signal turns this off. Named crawlers and AI agents are recorded either way.

What the Website does not do

• It runs no advertising, tracking pixels or cross-site tracking.
• It serves its fonts from our own domain, so your browser makes no request to Google Fonts.
• Site search, including the /ask and /mcp endpoints, runs against our own documents. It does not send your query to an AI model, and we do not keep the query.
• Its analytics stores nothing on your device. It does not record what you type into forms, with one exception you choose: the email address you give to join a waitlist.

Hosted Caveman Cloud

This section describes the hosted service. For deployments in a Customer's own cloud account, see Dedicated and self-hosted deployments above.

This section describes the personal data Caveman Cloud processes. Account, sign-up, session and security data is ours to control. Most of the rest is Customer Data, which we process for the Customer.

Accounts and sign-in

Anyone can create an account. You can sign up and sign in with an email address and password, with Google or with GitHub. A second sign-in method is linked to your account only when you add it while signed in. The first sign-in that does not come from an invitation creates a personal Workspace on the Free plan. A Free Workspace is for one person.

To create and secure your account, we process your name, email address, profile image (if you add one or it comes from Google or GitHub), a hash of your password, your multi-factor authentication and passkey material, your role and your Workspace memberships. We store passwords only as hashes and cannot read them. If you sign in with Google or GitHub, that provider shares your name, email address and profile image with us.

The sign-up page uses Cloudflare Turnstile to tell people from bots. Turnstile receives your IP address and browser signals under Cloudflare's privacy policy. We keep a keyed hash of the IP address used to sign up, to limit abuse, not the address itself.

Organisations can also admit people through single sign-on with OpenID Connect (including Microsoft Entra ID) or SAML, provision accounts with SCIM, let anyone with an approved email domain join, or send invitation links. In each case your organisation's identity provider or Admin shares the details your organisation configures, usually your name and email address.

At sign-up on the Free plan we show a separate screen, apart from the Terms of Service, asking you to agree to Product Data Sharing before your Workspace is created. When we publish a new version of our Terms, the dashboard asks a Workspace owner or Admin to accept it, and other members see a notice. We keep a record of each consent and acceptance.

Sessions

While you are signed in, we keep a session record containing a session token, your IP address and your browser user agent. We use it to keep you signed in and to protect your account. A dashboard session ends after 7 days without use. The session cookie is described in the Cookie Policy.

When you sign in from the CLI, it receives a short-lived access token and a session that lasts 30 days, and the Services create a gateway key named caveman-cli for your account. That key lasts until you revoke it in the dashboard.

Security and audit logs

Caveman Cloud keeps an append-only audit log of significant actions in each Workspace, such as changes to settings, keys, members, consents and retention, and reads of stored Payloads. Each entry records who acted, what changed and when. The IP address in an audit entry is stored as a keyed (HMAC) hash, not in readable form. We also keep the operational logs we need to run and secure the Services. Our cloud provider's records of who accessed stored data are kept in a locked store for 365 days. Requests to Caveman Cloud pass through Google Cloud load balancers and Cloudflare, which keep request logs, including IP addresses, for a limited period.

Usage Metadata

For each request routed through the gateway or imported from a Customer's traces, Caveman Cloud records Usage Metadata: the model and provider, token counts, cost, latency, status, salted hashes of the Payloads, any tags attached to the request, the ID of the Workspace member who sent it, a hashed ID for the Customer's own end user if the Customer supplies one, a session ID and any routing decision. Usage Metadata powers the dashboard, spend reports, routing, billing and savings measurement. It is Customer Data.

Payloads

Every Workspace stores the Payloads of its traffic by default, so the traffic can be shown, replayed and used to prove a change. Before a Payload is stored, it passes through automated redaction. A built-in set of rules removes common sensitive patterns, such as email addresses, bearer tokens, payment card numbers, US Social Security numbers and credential formats, and a Workspace can add its own rules. Redaction is automated and will not catch everything. Redacted Payloads are kept in object storage, encrypted with AES-256-GCM using envelope encryption, under data keys scoped to one Workspace.

On Pay-as-you-go and Enterprise, an Admin can turn payload storage off in Data governance, and the Services then keep Usage Metadata only. On the Free plan payload storage stays on.

Compression originals, caches and artifacts

When Caveman Cloud compresses a prompt, it keeps an encrypted copy of the original so the prompt can be restored byte for byte. These originals are exact copies, not redacted. Caveman Cloud also keeps encrypted copies of responses for its response cache, the files the SDKs save for recovery and, while artifact storage is on, the artifacts produced by agent runs. Originals and SDK files follow the Workspace's payload setting. Agent artifacts are kept only while artifact storage is on. It is on for Workspaces that start on Free, and it stays on when they add a card or move to Enterprise. It is off for Workspaces created directly on Pay-as-you-go or Enterprise, including customer-owned installs. An Admin can turn it on or off on every plan. Cached responses expire after 5 minutes by default and never later than 24 hours.

Imported traces and logs

A Customer can send its existing traces and logs to Caveman Cloud: OpenTelemetry traces and logs (including from LiteLLM), or exports from Langfuse and Helicone. Their metadata, such as span names, models, timings, severity, event names and exception types, is stored as the exporter sent it, without redaction. When the project stores Payloads, prompt, completion and tool content from the import is redacted, encrypted and kept as a Payload. Where the project stores Payloads, log bodies, exception messages and stack traces are redacted, cut to 16 KiB each and kept in ClickHouse Cloud, protected by the provider's encryption at rest. An OpenTelemetry exporter can send the header x-cave-capture-content: false to stop prompt, completion and tool content from its traces being kept. Any import, a Langfuse or Helicone file included, can send x-cave-retention: metadata to keep no content, log bodies included. Imported content follows the Workspace's Product Data Sharing setting, like gateway traffic.

Model routing

When routing is on, each routing request sends Caveman Cloud your latest message with what your agent attaches to it (up to 128 KiB), your previous message and the end of the agent's last reply (up to 16 KiB each), and request facts such as tool names, effort, agent headers and token counts. This happens on every plan, with no separate opt-in. The gateway reads the text in memory to choose a model and effort, then drops it. We keep the text only for a Free Workspace whose project has opted in to router learning, only for sampled requests, and only when router-learning collection is enabled for the deployment. Session state travels in a signed token your client holds, never the text. We keep one record per routing decision, with the Workspace, project, decision ID and time, for 13 months for billing, and routing outcomes from opted-in Free projects for up to 365 days.

Replay, comparisons and agent runs

• Replay. Replay is on by default for each project, on every plan. It lets Caveman Cloud send a project's redacted stored Payloads to Model Providers, using the Customer's stored keys, to compare models, build and test fixes, and judge results. Caveman Cloud can start this work itself, for example when it looks for a cheaper setup and tests it on your traffic. An Admin can turn replay off for each project. Payloads leave Caveman's own systems for this purpose only with replay on.
• Agent runs. If a Customer connects a repository, Caveman's agents can copy its code and history, read the Workspace's recorded traffic, write tests and open pull requests. They run in isolated sandboxes and call Model Providers with the Customer's keys.

Prompt snippets and embeddings

To analyse traffic and run the semantic cache, Caveman Cloud stores redacted prompt snippets and embeddings (numerical representations of text) in ClickHouse Cloud, protected by the provider's encryption at rest, and maps of how requests cluster in our own database. We keep traffic snippets, embeddings and cluster maps for at most 90 days, semantic-cache samples for at most 30 days and semantic-cache judgments for at most 90 days, and never longer than the Workspace's own window.

Zero data retention

A Customer can tighten retention for a single request by sending the x-cave-retention header. The value metadata limits storage for that request to Usage Metadata. The value zdr (zero data retention) disables Payload storage, compression originals, caching and replay for that request. The header can only make retention stricter. It can never loosen a Workspace's settings.

Model Provider keys

You can pass your Model Provider API key with each request, or store it in Caveman Cloud. Stored keys are encrypted with envelope encryption under a dedicated cloud KMS key. The gateway uses a stored key when a request carries none, and features such as routing through Caveman Cloud, model comparisons, replay and agent runs use stored keys.

If you connect Amazon Bedrock on hosted Caveman Cloud, you give us a Bedrock API key or AWS access keys, which we store encrypted like other stored keys. Requests run in, and are billed to, your AWS account. Hosted Caveman Cloud does not assume a role in your AWS account.

AI features in the dashboard

Some features, such as Ask, briefs, judges and agent runs, use AI models. On hosted Caveman Cloud they run on the Customer's own Model Provider keys. See the section on AI features and automated decisions.

Connecting AI assistants

You can connect an AI assistant, such as Codex, Claude Code or Cursor, to your Workspace through our MCP server. You approve each connection on a consent screen that lists the permissions the assistant asks for; by default, reading the organisation, request metadata and settings. Only assistants we have registered can connect. Access tokens last 15 minutes and are renewed for up to 30 days. We store tokens only as keyed hashes and delete them 24 hours after they expire.

We record each consent in the audit log, when each connection was last used, and every read of stored Payloads. We do not log the arguments or results of tool calls. An assistant can read only what the permissions you approved, and your own role, allow. You can revoke a connection at any time.

Our skills for coding agents, when signed in, send your Workspace an inventory of the repository you run them in and the results of the fixes they make, with the branch, commit and pull request link. This is Customer Data.

GitHub integration

The GitHub integration is optional. On hosted Caveman Cloud, you install Caveman's GitHub App on the repositories you choose. It requests read access to repository metadata and write access to repository contents and pull requests, and GitHub notifies us when the App is installed or changed and when its pull requests change. Some features read commit history, including commit author names and email addresses, to attribute work to contributors. Those details are Customer Data. The Customer is responsible for informing its contributors where the law requires it.

Email we send

We send transactional email through Resend, including sign-in emails, password resets, invitations, digests, spend alerts and billing-limit warnings. Resend processes your email address and the message content to deliver them.

Billing

Pay-as-you-go needs a card on file. Stripe collects and holds your card details; we never see the full card number. We send Stripe the billing email address, the Workspace ID and the usage total for each product needed to charge the Customer, and we keep a daily count of billable events for the life of the Workspace so that deleting request history never changes a bill. Free and Pay-as-you-go include the same monthly allowances, and each product has a billing limit you can set.

Support

If you contact us for help, we process your contact details, the content of your messages and anything you choose to share, such as screenshots, logs or request IDs. Our staff email runs on Google Workspace. If we need to look at a Workspace's data to answer a support request, we access only what the request needs.

CLI and local tools

Our local tools run on your own machine. Most of them never contact us. This section lists every case where one does, and the third parties some of them reach.

CLI telemetry

The caveman CLI (npm package @caveman-ai/cli) sends usage telemetry to us by default. You can turn it off at any time.

• Before anything is sent. The first time you run the CLI interactively, it shows a notice about telemetry. Nothing is sent before that notice. In CI the CLI sends nothing, unless you set CAVEMAN_TELEMETRY=1.
• How to turn it off. Run caveman telemetry off, or set DO_NOT_TRACK=1 or CAVEMAN_TELEMETRY=0 in your environment.
• Pseudonymous, not anonymous. Each installation has a random install ID. Our telemetry service, which runs on Supabase, stores the IP address of the machine that sent each event alongside the event. We clear stored IP addresses after 90 days and delete events after 13 months. Supabase's platform request logs also record each request's IP address and approximate location for the log retention period of our Supabase plan.
• What it sends. The event name, the time it happened and the time we received it; the install ID; the CLI version, operating system, CPU architecture and Node.js major version; whether you are signed in and, if so, your cached plan name; how the CLI was installed; your time zone and locale; that you agreed to telemetry after the notice, and the first start of the local runtime; agent session starts, meaning which coding agent and whether the session is new or resumed; the command and subcommand run, from a fixed allowlist, and the agent it ran for; its duration, outcome, error class and exit class; counts of tokens processed, of cache reads and writes, and of tokens saved (an inferred figure); the version of the event format; aggregate statistics from the local Proxy; aggregate counts from the first-run scan; and the name of any tool called through the CLI's MCP server (sent only if you set CAVEMAN_TELEMETRY=1). The CLI's own session hook sends the session-start event.
• What it never sends. Prompts, completions, raw command-line arguments, file paths, tool arguments or results, credentials, or rows or files from your local databases.
• Deleting your telemetry. When you run caveman telemetry off, the CLI prints the install ID it discarded. Send that ID to contact@caveman.ac and we will delete the events linked to it.

When you sign in to Caveman Cloud from the CLI

Signing in is optional. Once you are signed in, the CLI talks to Caveman Cloud in three ways:

• Sync. Right after you sign in, after each local caveman wrap session and whenever you run caveman sync, the CLI uploads span metadata to your Workspace: timestamps, request and trace IDs, the agent, provider and model, status, latency, byte sizes, token counts, cost and savings figures, the authentication mode and the IDs of the optimisations applied. It also uploads the findings from caveman learn and the aggregate counts from the first-run scan. It never uploads prompt or response bodies. Once uploaded, this data is Customer Data. Set CAVEMAN_OFFLINE=1 to stop the sync after each wrapped session; the sync right after sign-in still runs.
• Device check. At sign-in, and about once a week during wrapped sessions, the CLI checks your plan's device allowance. It sends a hash of a random device ID and your computer's hostname as the device name, so you can tell your devices apart in the dashboard. CAVEMAN_OFFLINE=1 stops the weekly check but not the one at sign-in.
• Managed gateway mode. If you route your coding agent through the Caveman Cloud gateway, your requests are processed as described in the Caveman Cloud section. For Claude Code, the CLI also tags each request with the GitHub repository (owner and name) and branch, so the Workspace can see spend by repository. Set CAVEMAN_WORK_TAGS=0 to stop sending these tags.

What the CLI keeps on your machine

• Your Caveman Cloud sign-in token, in the macOS Keychain or, elsewhere, in ~/.caveman/credentials, readable only by your user.
• Exact originals of compressed content, in ~/.caveman/ccr.db, so the CLI can restore them byte for byte. They can include anything that appeared in that content, including secrets.
• The CLI does not keep your Model Provider keys. When it wraps Codex, it copies Codex's own sign-in file into a temporary folder readable only by your user and deletes it when the session ends. When it wraps an agent that needs a key in its configuration, such as OpenClaw or Qwen Code, it writes that key to a temporary file readable only by your user. In managed gateway mode it forwards your key to Caveman Cloud with each request.
• The first-run scan reads the last 30 days of your local Claude Code and Codex history to estimate waste. Only aggregate counts leave your machine, and only as described above.

Third parties the CLI and tools contact

• GitHub and npm. Installers, signed binaries and updates come from GitHub and the npm registry, which see your IP address.
• Anthropic, if you compress a file. The /caveman-compress skill sends the file you choose to Anthropic, through your Claude Code login or your own ANTHROPIC_API_KEY, under your agreement with Anthropic.
• Caveman Code. It sends no telemetry anywhere. Once a day at most, on interactive start, it asks GitHub whether a newer release exists. It also asks the npm registry about extension packages you install. When fd or ripgrep is missing, it downloads it from that tool's GitHub releases.
• cavemem. It runs locally and sends nothing to Caveman. Its default local embedding model is downloaded from Hugging Face the first time it runs. Anything else it reaches, such as an embeddings API called with your own key or web search used to enrich your notes, is a provider you configure.

Tools that never contact Caveman

The Caveman skill and its hooks, the SDKs and middleware, caveman learn (except through sync), Blocks, Browse, CaveGemma and the Caveman Mode extension make no calls to Caveman, unless you point an SDK at Caveman Cloud yourself. The local Proxy makes no calls to Caveman unless you are signed in and turn routing on, in which case it sends routing requests as described under Model routing.

Plugins and MCP servers for AI assistants

Several of our tools install into AI assistants such as Codex, Claude Code and Cursor, as plugins, skills or Model Context Protocol (MCP) servers. What each one handles:

• The Caveman Language Codex plugin contains instruction skills and static assets only. Caveman collects no data through it; see its dedicated section below.
• The Caveman plugin for Claude Code (skills and hooks) runs inside your assistant on your machine. Its hooks keep their state in your assistant's settings folder and make no network calls. /caveman-stats reads your local assistant transcript, and nothing leaves your machine. /caveman-compress sends the file you choose to Anthropic, as described above.
• Caveman Browse runs as a local MCP server and drives the Chrome browser you are already using, including pages where you are signed in. Page content goes only to your assistant and your Model Provider, never to Caveman.
• The CLI's Caveman Cloud MCP server runs locally with your CLI sign-in. Its tools read your Workspace through the Caveman Cloud API, as described in the Caveman Cloud section.
• The hosted Caveman Cloud MCP server is described under Connecting AI assistants.
• The caveman.so MCP server at /mcp searches our public documents. It needs no account, and we record only what the Website section describes.

None of them ask for your passwords, payment details or government identifiers, and none of them read your conversation beyond what you or your assistant pass to a tool.

Products in private preview

Some products are available only to invited testers: Caveman Router, which picks a model for each task your coding agent runs; Pebble, our coding agent; and model routing inside the CLI. Routing requests go to Caveman Cloud and are handled as the Model routing section describes. The CLI's setup ticks routing by default, and caveman off routing turns it off. When you are signed in, the CLI's local runtime also sends your Workspace one event per request: the agent, its version, the provider, the result of each stage, the models, token counts and the routing outcome and reason. These events never contain prompt text, are kept as your Workspace's request history on every plan, and are never used to improve Caveman's models. caveman telemetry off stops them. We will add a full section to this policy before any of these previews is generally available.

Reporting security issues

If you report a vulnerability by email or through GitHub private vulnerability reporting, we process your contact details and the report so we can investigate and reply.

Caveman Language Codex plugin

This section covers the Caveman Language plugin for Codex and its /caveman, /ultracave and /megacave instruction skills.

Caveman Labs, Inc. does not collect, receive, store, sell or share any data through this plugin. The package contains instruction skills and static assets only. It has no Caveman server, analytics, tracking, telemetry, account connection or mechanism for sending your conversations, files or usage data to Caveman.

Because we receive no data through the plugin, we retain no such data and have none to delete. Caveman does not use plugin conversations or files for model training. The Caveman Cloud Product Data Sharing provisions in this policy do not apply to the plugin.

Codex and your chosen AI host process conversations and may store chat or skill state under their own policies and settings. Installing this plugin does not change those policies or settings. Information you separately send us, such as a support email or a public GitHub issue, is covered by the relevant sections of this policy.

Caveman Mode browser extension

Caveman Mode is a browser extension for Chrome and Firefox that makes AI chat assistants reply tersely. This section is the privacy policy for the extension and applies to the extension alone.

Caveman Mode does not collect, store or transmit any personal data. It makes no network requests of its own, contains no analytics or tracking, and sends nothing to us or to any third party.

What the extension stores

Your preferences only: whether the mode is on, the intensity level and which supported sites it is active on. The extension saves them with the browser's chrome.storage API so your choices persist between sessions and sync across your own signed-in browsers. They contain no personal information and are never sent to us. Your browser provider handles that sync under its own terms.

What the extension accesses

The extension works only on the supported AI chat sites: chatgpt.com, chat.openai.com, claude.ai and gemini.google.com. When you press send, it accesses the text in the message box so it can add a short instruction asking the assistant to reply tersely, and it checks whether the chat already has messages. This happens entirely on your device, in the page. The extension does not read, store, log or transmit your conversations, and it does not run on any other website.

Limited Use

The use of information by Caveman Mode complies with the Chrome Web Store User Data Policy, including the Limited Use requirements.

• We do not sell or transfer user data to third parties.
• We do not use or transfer user data for any purpose unrelated to the extension's single function.
• We do not use or transfer user data to determine creditworthiness or for lending purposes.

If the extension's data practices change, we will update this section and, where the Chrome Web Store or the law requires it, ask for your consent first.

Where we get personal data

• From you, when you create an account, join a waitlist, email us, book a call or use the Services.
• From your organisation, when a Workspace Admin invites you, assigns you a role, approves your email domain or sets up single sign-on or SCIM.
• From your devices, automatically, when you visit the Website, use the dashboard or run the CLI with telemetry on.
• From Customers, as Customer Data they route through, import into or store in Caveman Cloud, which can include data about their own end users and repository contributors.
• From third parties you connect or use: Google or GitHub, if you sign in with them; your organisation's identity provider, if it uses single sign-on; GitHub, if your organisation installs our GitHub App; Cloudflare, which checks sign-ups for bots; Cal.com, when you book a call; and Stripe, when you add a card.

Why we use personal data and our legal bases

Where the GDPR or UK GDPR applies, we need a legal basis for each use of personal data. The table below sets out our purposes, the data involved and the basis we rely on.

• "Contract" means the processing is necessary to perform a contract with you, or to take steps you ask for before entering into one (Article 6(1)(b)).
• "Legitimate interests" means the processing is necessary for our legitimate interests or those of a third party, and your interests and rights do not override them (Article 6(1)(f)).
• "Legal obligation" means the law requires the processing (Article 6(1)(c)).
• "Consent" means you have agreed to the processing (Article 6(1)(a)). You can withdraw consent at any time, without affecting processing that took place before.

You need to give us account data, such as your name and email address, so that we can provide the Services to you. Without it, you cannot use Caveman Cloud. Apart from that, and a card on file if you choose Pay-as-you-go, giving us personal data is not a statutory or contractual requirement.

Where we rely on legitimate interests, you can ask us how we weighed our interests against yours. We will not use personal data for a new purpose that is incompatible with those above without telling you first and, where the law requires it, asking for your consent.

Product Data Sharing and model improvement

What Product Data Sharing is

Product Data Sharing lets us use Payloads and Usage Metadata to improve Caveman's own models and evaluations: the models that classify, label and investigate traffic, route requests, compress prompts, cache responses and optimise spend in our Services.

When it applies

• Free plan. Your content is part of the price of Free. What reaches Caveman Cloud from a Free Workspace, including recorded requests with their Payloads and, for projects that opt in to router learning, sampled routing-request text, may be used to improve our models. We ask you to agree to this on its own screen at sign-up, separately from the Terms of Service. If you decline, you are not signed up, and every local tool keeps working.
• Pay-as-you-go. Off by default for new Pay-as-you-go Workspaces. A Workspace Admin can turn it on or off in Data governance, which shows the current setting. A Workspace that moves from Free to Pay-as-you-go stops sharing from that moment. Workspaces that were on the former Indie or Team plans moved to Pay-as-you-go with their sharing setting unchanged, so a former Indie Workspace can still have sharing on until an Admin turns it off.
• Enterprise, dedicated and self-hosted deployments. Never. It cannot be turned on.

A Workspace that returns to Free after a failed payment keeps its existing setting. Sharing turns back on only if an Owner or Admin turns it on.

We may use data for model improvement only where Product Data Sharing applies and the required notices and permissions are in place. Publishing this policy does not turn on sharing for an existing Workspace.

Our role for model improvement

When we use data under Product Data Sharing, we act as an independent controller for that purpose. We are not the Customer's processor for it. The Customer must have the right to share the data with us for this purpose, including any notices or permissions its own users require. A Customer must not send special categories of personal data, personal data relating to criminal convictions and offences, or children's personal data through a Workspace where Product Data Sharing applies, which is always the case on the Free plan. On any plan, a Customer must not send protected health information regulated under HIPAA or payment card data covered by PCI DSS unless its Order Form allows it.

Safeguards for shared data

• Before a Payload is stored, it passes through the automated redaction described in the Caveman Cloud section. Redaction lowers the chance that personal data is kept, but it does not remove that chance.
• We keep data used for model improvement while Product Data Sharing applies to it, and never longer than the Workspace's own retention window. The training sets we build from it expire at most 365 days after they are built, or sooner if the window is shorter.
• Only staff who need the data for this work can access it.
• We never sell this data. We never share it with other customers. We never use it to train a third party's general-purpose model.

Turning Product Data Sharing off

On Pay-as-you-go, a Workspace Admin can turn Product Data Sharing off in Data governance at any time. Turning it off stops new collection for this purpose and deletes the stored copies kept only for it. Training sets already built from that data are not rebuilt with it; they are deleted when they expire, at most 365 days after they were built, or sooner if the Workspace's window is shorter or its data is deleted. Copies the Workspace keeps for its own use, under its payload setting, stay until the Customer deletes them.

On the Free plan, Product Data Sharing stays on while the Workspace is on Free. To stop it, add a card to move to Pay-as-you-go, or stop using the Workspace.

Deleting a Workspace's data in Data governance also deletes data held under Product Data Sharing, including from training sets. Improvements already made to models, and aggregated or de-identified data, cannot be undone.

Cross-customer practice evidence

Separately from Product Data Sharing, a Workspace on Free or Pay-as-you-go can opt a project in to contributing derived practice evidence, so that practice rankings improve across customers. It is off by default. Only derived before-and-after metrics, window sizes and a practice identifier contribute. We never contribute prompts, responses, diffs, repository content or organisation identity. Revoking applies to the next rollup and is recorded in the audit log. Enterprise Workspaces and Workspaces without a known Plan cannot opt in.

Your right to object to model improvement

You can object to the use of your personal data for model improvement by writing to contact@caveman.ac, whatever the plan of the Workspace involved. We honour an objection by excluding from Product Data Sharing the data we can link to you, such as by your email address, Workspace member ID or a Customer's client user ID. To find data that can be linked to you only by its content, we may need help from the relevant Customer, because Payloads are stored per Workspace and encrypted.

AI features and automated decisions

Some Caveman Cloud features use AI models to produce answers, summaries, scores, tests or proposed changes. These include Ask, briefs, judges, model comparisons and agent runs. On hosted Caveman Cloud they run on the Customer's own Model Provider keys. By configuring a provider key for an AI feature, leaving replay on for a project, or starting an agent run, the Customer instructs Caveman to send the relevant Customer Data to that Model Provider, under the Customer's agreement with that provider.

At the date of this version, hosted Caveman Cloud does not send Customer Data to a model provider under Caveman's own account. Before it does, for example to embed text for the semantic cache, we will add that provider to the Sub-processors page with the notice the DPA requires.

We identify AI features as AI features. AI output can be wrong, incomplete or out of date, so check it before you rely on it.

The gateway also uses automated rules and models to choose a model, compress a prompt or serve a cached response. These decisions concern requests, not people. We do not make decisions based solely on automated processing, including profiling, that produce legal effects concerning you or similarly significantly affect you.

How we share personal data

We share personal data only as described below.

• Sub-processors and service providers. Companies that host and run parts of our Website and Services for us: Google Cloud, ClickHouse Cloud, Cloudflare, Resend, Stripe, Vercel, Supabase, PostHog, Google Workspace and Cal.com. They may use personal data only to provide their services to us. Our Sub-processors page lists each one, what it does and where.
• Model Providers, on the Customer's instructions. We forward requests to the Model Providers a Customer chooses, using the Customer's own keys or accounts, and send them stored Payloads where the Customer has replay on.
• Services you connect. When you or your organisation connect Google or GitHub sign-in, single sign-on, SCIM or our GitHub App, data passes between us and that service as needed to make the connection work.
• Your organisation. Workspace Admins and members can see information about your activity in their Workspace, such as audit log entries and usage attributed to you.
• Professional advisers. Lawyers, accountants, auditors and insurers, under duties of confidentiality.
• Corporate transactions. If we are involved in a merger, acquisition, financing, reorganisation, sale of assets or insolvency, personal data may pass to the other party or a successor. The recipient must handle it in line with this policy, or we will tell you before a different policy applies.
• Legal requests and protection. We disclose personal data where we must by law, for example to comply with a court order or a valid request from a public authority. We may also disclose it where needed to protect the rights, property or safety of Caveman, our Customers or others, or to prevent fraud or abuse. Where the law allows, we tell the affected Customer before disclosing Customer Data.
• With your consent or at your direction.

We do not sell personal data. We do not share personal data for cross-context behavioural advertising. We do not show ads, and we do not let advertising networks collect data on our Website or Services.

International transfers

Caveman Labs, Inc. is a US company. Caveman Cloud stores its core data on Google Cloud in the europe-west4 region (Netherlands). Usage Metadata, prompt snippets and embeddings are stored in ClickHouse Cloud, running on Google Cloud in the same region and reachable only over private connectivity.

Other processing happens elsewhere. Requests to the Website and Caveman Cloud pass through Cloudflare's global network, which terminates TLS and inspects traffic to block attacks. Several of our providers are US companies. Our staff may access data from outside the European Economic Area, including from the United States.

When we transfer personal data from the EEA, the UK or Switzerland to a country that does not have an adequacy decision, we use the European Commission's Standard Contractual Clauses or another lawful transfer mechanism. For personal data we receive as a controller, including account data and data used under Product Data Sharing, we use Module 1 (controller to controller). For Customer Data we process as a processor, we use Module 2 (controller to processor) or Module 3 (processor to processor), as the DPA sets out. For transfers from the UK and Switzerland, we add the UK International Data Transfer Addendum and the amendments Swiss law requires. Where a provider is certified under the EU-US Data Privacy Framework or its UK or Swiss extensions, we may rely on that certification. You can ask us for a copy of the safeguards that apply to a transfer by writing to contact@caveman.ac.

How long we keep personal data

The hosted Customer Data and backup periods in this section apply to hosted Cloud. Customer-account deployments use the retention, backup and deletion arrangements in their deployment agreement. The periods for separate CLI telemetry and information sent directly to Caveman still apply to that information.

We keep personal data only for as long as we need it for the purposes in this policy, unless the law requires us to keep it longer. Customer Data is kept until the Customer deletes it, on every plan. A Workspace Admin can set a window in Data governance, from 1 day to 36,500 days, after which request history, Payloads or agent artifacts are deleted automatically; by default no window is set.

Deletion

The Workspace owner can delete the Workspace's data in Data governance. We carry out the deletion 30 days after the request. A daily job also deletes data whose window has ended. Database backups, point-in-time recovery logs and earlier object versions roll off within about 35 days after deletion. Rows deleted from our analytics database by a retention window can stay on disk, and in backups taken in that time, for about a month, and those backups are kept up to 30 days more, so in total up to about two months. If an Admin lengthens or removes the window after rows were deleted, those rows can stay on disk until the database merges them or the Workspace is deleted. Your user identity is deleted once no Workspace refers to it.

A Customer can export Customer Data during its agreement with us and for 30 days after the agreement ends, or longer where the EU Data Act's switching rules apply. Export means the export tools in the Services, which document their formats and structures, plus reasonable help from us on request. We delete remaining Customer Data within 30 days after that export period ends, and backups roll off within about 35 days after deletion.

Self-service account deletion is not yet available in the dashboard. To delete your account, email contact@caveman.ac. Customers can export the data held about one of their own end users through our API, to answer requests from those users.

How we protect personal data

We use technical and organisational measures appropriate to the risk, including:

• encryption in transit with TLS 1.2 or higher, at the Cloudflare edge and between Cloudflare and our origin, which accepts traffic only from Cloudflare;
• encryption at rest using our cloud providers' encryption, with object storage encrypted under KMS keys we manage;
• envelope encryption with AES-256-GCM for stored Payloads, under data keys scoped to one Workspace, and KMS envelope encryption for stored Model Provider keys and GitHub App secrets;
• rotation of KMS keys every 90 days;
• automated redaction before Payloads are stored;
• row-level security in the database to keep each Workspace's data separate;
• role-based access control in the dashboard, and scoped tokens for API and MCP access;
• an append-only audit log, including reads of stored Payloads;
• isolated sandboxes for agent runs;
• multi-factor authentication and passkeys, available to every account; and
• least-privilege access to production systems for our staff.

No system is perfectly secure. You are responsible for protecting your own credentials and keys and for choosing settings that suit your needs. To report a security issue, write to contact@caveman.ac. For the open-source toolkit, you can also use GitHub private vulnerability reporting.

Your rights

Rights under the GDPR and UK GDPR

If the GDPR or UK GDPR applies to you, you have the right to:

• access the personal data we hold about you and get a copy of it;
• rectification: have inaccurate data corrected and incomplete data completed;
• erasure: have your data deleted in certain cases;
• restriction: have us limit how we use your data in certain cases;
• data portability: receive data you gave us in a structured, machine-readable format, or have it sent to another controller, where we process it by automated means on the basis of contract or consent;
• object to processing based on our legitimate interests, including Product Data Sharing and CLI telemetry. The section on Product Data Sharing explains how we honour an objection to model improvement. You can object to direct marketing at any time, and we will then stop;
• withdraw consent at any time, where we rely on consent. This does not affect processing that took place before;
• not be subject to a decision based solely on automated processing that has legal or similarly significant effects on you. We do not make such decisions; and
• lodge a complaint with a supervisory authority, in particular in the country where you live, where you work or where you think the infringement took place. In the Netherlands, where Caveman Cloud stores its data, the authority is the Autoriteit Persoonsgegevens. In the UK, it is the Information Commissioner's Office. We would appreciate the chance to deal with your concern first.

These rights have limits set by law. For example, we may keep data we need to comply with a legal obligation or to defend a legal claim. For Customer Data, please contact the Customer, which controls it.

US state privacy rights

This section applies to residents of California and of other US states with comprehensive privacy laws, where those laws apply to us. For California residents, it is our notice at collection under the California Consumer Privacy Act, as amended by the California Privacy Rights Act (CCPA).

It covers personal information we handle as a business. It does not cover Customer Data we process as a service provider, which the Customer controls.

Categories we collect

In the past 12 months we have collected the categories of personal information below. The sections above explain the sources, the purposes and how long we keep each kind of data.

We use sensitive personal information only to sign you in and keep your account secure. We do not use it to infer characteristics about you. Payloads can contain any information a Customer chooses to send. That is why a Customer must not send special categories of personal data, criminal-offence data or children's personal data through a Workspace where Product Data Sharing applies.

No sale or sharing

We do not sell personal information and we do not share it for cross-context behavioural advertising, as those terms are defined in the CCPA. We have not done so in the past 12 months. We have no actual knowledge of selling or sharing the personal information of consumers under 16. We do not disclose personal information to third parties for their own direct marketing purposes.

We treat a Global Privacy Control signal sent by your browser as a valid request to opt out of the sale and sharing of personal information linked to that browser. Because we do not sell or share personal information, there is nothing further to switch off today. We will honour the signal if that ever changes.

Your rights under US state laws

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

• know and access the categories and specific pieces of personal information we have collected about you, the sources, the purposes, and the categories of recipients;
• delete personal information we collected from you;
• correct inaccurate personal information;
• portability: receive your personal information in a portable format;
• opt out of the sale or sharing of personal information, targeted advertising, and profiling in furtherance of decisions that produce legal or similarly significant effects. We do none of these;
• limit the use of sensitive personal information to the purposes the law permits. We already limit it in this way; and
• non-discrimination: we will not deny you service, charge you a different price or give you a different quality of service because you exercised your rights. The Free plan's exchange for Product Data Sharing is described in the Notice of financial incentive below.

Notice of financial incentive

We offer the Free plan in part in exchange for Product Data Sharing. California law may treat this as a financial incentive.

• What we offer. Use of Caveman Cloud on the Free plan without a card on file.
• Data involved. Payloads and Usage Metadata from your Workspace, including sampled routing-request text for projects that opt in to router learning, used to improve Caveman's own models as described in the section on Product Data Sharing.
• How you opt in. By agreeing on the Product Data Sharing screen when you sign up for the Free plan.
• How you withdraw. At any time, by adding a card to move to Pay-as-you-go, where sharing is off, or by no longer using the Free Workspace.
• Value of the data. We estimate the value of a Free Workspace's data to us from the expenses we incur to provide the Free plan's allowances to that Workspace without charge: hosting, storage, processing and support. We do not price the data separately, and the estimate does not change what Free costs you, which is nothing.

Do Not Track

The Website does no cross-site tracking. Its product analytics respects Do Not Track: if your browser sends the signal, nothing is sent. We honour Global Privacy Control as an opt-out of sale and sharing, as described above. It does not switch off the Website's analytics; Do Not Track does.

Authorised agents

You can use an authorised agent to make a request for you. We will ask the agent for your signed permission, and we may ask you to verify your identity directly with us or to confirm that you gave the agent permission, unless the agent holds a valid power of attorney.

Verifying your request

To protect your data, we verify requests before acting on them. We will usually ask you to write from, or confirm access to, the email address linked to your account or waitlist entry. For CLI telemetry, we use the install ID. We use the information you give us for verification only to verify you.

Appeals

If we decline to act on your request, you can appeal by replying to our decision and asking us to reconsider. We will respond to your appeal within the time your state's law requires, and explain our reasons. If you are not satisfied with the outcome, you can contact your state attorney general.

Other US states

Residents of states such as Colorado, Connecticut, Oregon, Texas and Virginia have rights similar to those described above where those states' laws apply to us. Use the same process to exercise them.

How to exercise your rights

To exercise any of your rights, email contact@caveman.ac. Tell us what you would like us to do and which of our products your request relates to, such as your account, a waitlist entry, the CLI (include your install ID) or the Website. Writing from the email address linked to your account helps us verify you quickly.

Some things you can do yourself:

• Workspace Admins can set retention windows, turn payload storage off on paid plans, turn replay off per project and change Product Data Sharing on Pay-as-you-go, in Data governance. The Workspace owner can delete Workspace data there.
• You can revoke an AI assistant's connection to your Workspace in the dashboard.
• You can turn off CLI telemetry with caveman telemetry off, DO_NOT_TRACK=1 or CAVEMAN_TELEMETRY=0.
• You can turn off the Website's analytics with your browser's Do Not Track setting, and clear the Website's and dashboard's browser storage in your browser settings.

We respond within one month of receiving a request under the GDPR or UK GDPR. We can extend this by two further months for complex or numerous requests, and we will tell you if we do. For requests under US state laws, we confirm receipt within 10 business days where the law requires and respond within 45 days, which we can extend by another 45 days where the law allows. We do not charge for requests, unless a request is manifestly unfounded or excessive and the law allows a fee.

If your request concerns Customer Data, we will refer you to the Customer and help the Customer respond.

Children

The Website and the Services are for business and professional use by adults. They are not directed at anyone under 18, and we do not knowingly collect personal data from anyone under 18. If we learn that we have collected personal data from someone under 18, we will delete it. If you think this has happened, write to contact@caveman.ac.

Marketing communications

We send transactional email, such as sign-in emails, invitations, digests, spend alerts, billing-limit warnings and notices about changes to our terms, through Resend. These messages are part of providing the Services, so you cannot opt out of them while you have an account.

We send product updates and news only where the law allows: with your consent, or, where permitted, to business contacts and customers about products similar to those they use. If you joined a waitlist, we may email you about access to the product you signed up for. Every product update email includes a way to unsubscribe. You can also opt out at any time by writing to contact@caveman.ac.

Cookies and similar technologies

The Website sets no cookies. The dashboard uses only cookies that are strictly necessary for sign-in and security. Both use your browser's local or session storage for preferences and sign-in state. Neither uses advertising or cross-site tracking cookies. The Cookie Policy lists every cookie and storage key, what it does and how long it lasts.

Product analytics

We use PostHog, on its EU cloud, for product analytics on caveman.so. It works as follows:

• it is cookieless, keeping its identifiers in memory only, so nothing is stored on your device and each visit starts fresh;
• it records the pages you visit as page paths without query strings, how long and how far you read, the buttons and links you click with their visible labels, click and scroll heatmaps, page speed, script errors and browser console messages;
• it records campaign tags (utm_*) on the link that brought you here, with ad click IDs masked, and the referring site's domain and search engine, but never the full referring address or your search terms;
• it derives your approximate location from your IP address, which is then discarded;
• it records session replays of how pages render and respond, with every form field masked in your browser before anything is sent, no request or response contents, and demo areas that repeat text you typed left out;
• it does not collect what you type, form values, file paths or free text, except that if you join a waitlist or book a call, it links that visit, including its session replay, to the email address you entered or to your Cal.com booking, for that browser tab only;
• it respects Do Not Track: with the signal on, nothing is sent. It does not read Global Privacy Control, so turn on Do Not Track if you want the Website's analytics off; and
• session replays are deleted after 30 days. Other analytics events are kept for the retention period of our PostHog plan, currently up to 7 years.

PostHog is also configured for the dashboard but is not switched on there. If we switch it on, it will be cookieless, will not capture interactions automatically or record sessions, will identify events by your user ID, Workspace ID and plan, and will be off for Enterprise Workspaces. We will update this policy and the Cookie Policy before we do.

Data breaches

If a personal data breach affects personal data we control, we will notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, where the law requires notification. We will tell affected individuals without undue delay where the breach is likely to result in a high risk to them, or where US state breach notification laws require it.

If a breach affects Customer Data, we will notify the affected Customer without undue delay and, where feasible, within 72 hours of becoming aware of it. We will give the Customer the information it needs to meet its own obligations. Our Data Processing Agreement sets out the details.

Changes to this policy

We may update this policy as our Services, our providers or the law change. The version tag at the top of this page shows which version you are reading. We give at least 30 days' advance notice of material changes, by email to Workspace owners and Admins and by a notice on this page. A change can take effect sooner where the law or security requires it. Where the law requires your consent to a change, we will ask for it. Earlier versions are available on request.

Contact us

Caveman Labs, Inc. 1209 Orange Street, Corporation Trust Center, Wilmington, Delaware 19801, United States

Email: contact@caveman.ac

Write to this address for privacy questions, requests to exercise your rights, complaints, security reports and help with any of our products.