Does OpenAI train on your API data? 12 providers, 3 answers, one 30-day default

No. Data sent to the OpenAI API has not been used to train OpenAI models by default since March 1, 2023, and the platform documentation says so in one sentence. But “not used for training” is one column of a table that has four, and the retention column is written per endpoint: /v1/audio/transcriptions keeps nothing, /v1/chat/completions keeps abuse-monitoring logs for 30 days, /v1/responses also stores application state for 30 days unless you turn store off, and Zero Data Retention is granted by approval, not by checkbox. Across the twelve providers whose clauses we read on 2026-09-11, six say no by default; DeepSeek and Moonshot permit training under their published terms: DeepSeek names an opt-out right without a self-serve API control, while Moonshot points to a separate written agreement. Mistral’s default varies by product, without naming which products; Cohere explains its opt-out toggle without stating the default. Groq and Alibaba Model Studio could not be verified from the pages we could read.

The rest is the clauses, quoted, and where each one lives.

Two HN threads, one mathematician, and a sentence with a carve-out

This week’s news is about the consumer product, not the API. On September 10, two threads sat on the Hacker News front page at the same time. In the first, a user wrote that they had turned off ChatGPT’s “allow training” setting more than once, made a note of the date, and found it enabled again (Tell HN: OpenAI keeps re-enabling the ‘allow training’ setting, 179 points at collection). Three commenters reported the same experience. Eight reported the opposite: they had turned it off once, months or years ago, and it was still off. One of them: “I would not over-index on a sample size of one.” Neither set has been verified by anyone with backend access.

The second thread (Another researcher says OpenAI trained on conversations, then claimed breakthrough, 161 points at collection) pointed, through two layers of screenshots, at a three-post thread by Andreas Thom, a group theorist at TU Dresden. His account is specific. After OpenAI announced in August that a model had constructed the first non-sofic group, using methods from a 2019 paper by Gábor Kun and Thom, he emailed two OpenAI researchers. He and a colleague had spent months discussing extensions of that work with ChatGPT, and he asked two things: whether those conversations had entered training data, and whether they had been accessible to the process that produced the proof. The complete answer he quotes is one line: “Regarding your conversations with ChatGPT: that did not happen.”

Thom’s reading is that a one-line answer to a two-part question addressed only the second part. He also notes that he turned off model training on June 29, that the setting “is still only a promise whose implementation users cannot audit,” and that it is prospective: it says nothing about conversations from before that date.

Weeks later, in the separate Navier–Stokes dispute with Tristan Buckmaster and Levent Alpöge, OpenAI published a statement. The relevant sentences, from the Navier–Stokes solution page, “Concurrent work”: “We (the researchers and the agents) did not see any of their work through any means until they released it publicly — in particular, no specific user data was accessed in order to solve this problem. While unlikely, we cannot rule out that de-identified data derived from their usage of our products helped improve our models.”

Thom has called the answer he received misleading. OpenAI has not publicly responded to his posts as of this writing, and the mathematics is Lean-verified and not in dispute. Nothing here establishes that any specific conversation was used for anything. What the week establishes is narrower: “did not access your data” and “did not train on your data” are two different statements. One company treated them as one in an email and as two in a public post, and the people asking had no way to check either.

Consumer toggle and API default are two different regimes

The toggle in the first thread lives in ChatGPT’s settings. A commenter on the second thread pasted its label as it appears to a Pro subscriber: “Improve the model for everyone. Allow your content to be used to train our models, which makes ChatGPT better for you and everyone who uses it.” The API runs under a different rule; OpenAI’s help centre puts both on one page.

For individuals, the page says: “When you use our services for individuals such as ChatGPT and Codex, we may use your content to train our models.” The opt-out is the privacy portal’s “do not train on my content,” and “once you opt out, new conversations will not be used to train our models.” New conversations. Three further details on the same page matter. Feedback is an exception: “If you choose to provide feedback, the entire conversation associated with that feedback may be used to train our models.” Temporary Chat is excluded from training. And Codex “has separate controls for allowing training on full environments,” separate from the ChatGPT toggle (How your data is used to improve model performance, read 2026-09-11).

For businesses, the same page: “By default, we do not train on any inputs or outputs from our products for business users, including ChatGPT Business, ChatGPT Enterprise, and the API. We offer API customers a way to opt-in to share data with us … Unless they explicitly opt-in, organizations are opted out of data-sharing by default.” The Enterprise privacy page makes it a headline: “We do not train our models on your data by default.”

So the two threads are about the regime where training is on unless you turn it off, and the API is the regime where it is off unless you turn it on. If your product calls the API with your own key, the toggle that may or may not have reset itself is not your toggle.

“Not used for training” is one column. OpenAI’s table has four

OpenAI’s platform documentation does something most providers do not: it publishes a per-endpoint table with four columns, covering training, abuse-monitoring retention, application-state retention, and Zero Data Retention eligibility (Data controls in the OpenAI platform — Your data, read 2026-09-11). The training column reads “No” on every row. The other three columns are where the differences live.

Abuse-monitoring logs apply everywhere: “By default, abuse monitoring logs are generated for all API feature usage and retained for up to 30 days, unless longer retention is required by law, or is reasonably necessary to protect our services or any third party from harm.” The page is explicit that these logs “may contain certain customer content, such as prompts and responses.”

A subset of the rows, quoted from the table:

The Responses API stores by default, and the table does not say so. Both /v1/responses and /v1/chat/completions read “None, see below for exceptions” in the application-state column. The exception is underneath: “the Responses API has a 30 day Application State retention period by default, or when the store parameter is set to true.” Read the row and nothing is kept; read the note below it and a month is. If you migrated from Chat Completions and did not touch store, your prompts and completions are now held for a month on top of the abuse logs. The fix is one field:

{
  "model": "gpt-5.5",
  "input": "Summarise the attached contract.",
  "store": false
}

Audio transcription keeps nothing. /v1/audio/transcriptions and /v1/audio/translations show “None” in both retention columns. The recording is the least-retained thing you can send; the transcript you then post to a chat model is logged for 30 days. A meeting-notes developer who read the same table put it in one line, “The audio is the safe part. The text isn’t.” (OpenAI Data Retention Policy (2026): What They Keep, and For How Long)

Stateful endpoints are yours to delete. Conversations, Assistants threads, vector stores, files: “Objects that are not deleted via the API or dashboard are retained indefinitely.” That is not a policy OpenAI imposes but one you choose by not deleting.

The fourth column: Zero Data Retention “excludes customer content from abuse monitoring logs” and forces store to false “even if the request attempts to set the value to true.” Modified Abuse Monitoring does the log exclusion without the behaviour change. Neither is a checkbox: “Currently, these controls are subject to prior approval by OpenAI and acceptance of additional requirements.” Approved customers then pick one of the two for an organisation or a project. Even with ZDR on, the endpoints marked “No” in the last column still store application state, image and file inputs are still scanned on submission and “retained for manual review” if a classifier flags them, and OpenAI reserves a “Safety Retention” right to make specific models ineligible for specific customers, with written notice.

None of this is hidden; it is all on one page. But it is a table, and your own traffic needs one. “Does OpenAI train on API data?” has a one-word answer. “What happens to my API data?” has a per-endpoint one.

Twelve providers’ training clauses, side by side

The method is the one we used for price-change notice clauses: read the provider’s own legal or documentation page, quote it, link the section, date the read. Every row was read on 2026-09-11. Where a page could not be read by script, the row says so.

The wording, provider by provider.

OpenAI. “As of March 1, 2023, data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us).” Covered above.

Anthropic. “Anthropic may not train models on Customer Content from Services.” That is section B of the Commercial Terms (effective June 17, 2025), a contract, not a settings page. The privacy FAQ adds the exception that recurs across this table: feedback via thumbs up or down stores “the entire related conversation” for up to five years, and that data “may” be used to train (Is my data used for model training?).

Google. Two tiers in one document, effective March 23, 2026. Unpaid Services, meaning AI Studio and the unpaid Gemini API quota: “Google uses the content you submit to the Services and any generated responses to provide, improve, and develop Google products and services and machine learning technologies,” and “human reviewers may read, annotate, and process your API input and output.” Paid Services, meaning a Cloud project with active billing: “Google doesn’t use your prompts … or responses to improve our products,” and logs “for a limited period of time, solely for detecting and preventing violations of the Prohibited Use Policy.” The tier is decided by billing, not by endpoint. Europe gets two clauses that are easy to merge and should not be. A use restriction: “You may use only Paid Services when making API Clients available to users in the European Economic Area, Switzerland, or the United Kingdom.” And a data clause pointing the other way: if you are in those territories, the Paid Services data terms “apply to all Services, including Google AI Studio and unpaid quota in the Gemini API, even though they are offered free of charge.” Paid data treatment on the free tier; no shipping to European users from it.

DeepSeek. Section 4 of the Open Platform Terms (effective April 29, 2026) spells out what you may do with Inputs and Outputs, including “training other models (such as model distillation)”. On what DeepSeek does with them, the Terms only point elsewhere (DeepSeek Open Platform Terms of Service). First to the Privacy Policy (last update February 10, 2026), which lists among its purposes for User Input “to train and improve our technology, such as our machine learning models and algorithms,” and among your rights, as its own item after the targeted-advertising one, “the right to opt-out of using your Personal Data for training our models or optimizing our technologies.” The policy names no mechanism for exercising it on the API. Then to a training-methods disclosure, where fine-tuning pairs are “produced by our research team, with a small portion potentially based on user input,” de-identified, with the opt-out routed back to the Privacy Policy (Model Principles and Training Methods Explanation). No self-serve control for API traffic is named in any of the three. Retention: “for as long as you have an account.”

Mistral. Section 4.2 of the Commercial Terms (effective August 5, 2026): “Mistral AI will not use Customer Data or Outputs to train its artificial intelligence models except (a) when you (i) opted-in to training on a Mistral AI Product set to opt-out by default or (ii) have not opted-out of training on a Mistral AI Product set to opt-in by default, (b) when Customer or an End User provides Feedback to Mistral AI, (c) as otherwise may be provided in an Order Form or (d) when Customer uses Labs or Preview Models.” Clause (a)(ii) allows training on products set to opt in by default unless you opt out, without saying which products these are. Labs and Preview models are also exceptions to the default exclusion from training, regardless of your other preferences. The Privacy Policy (effective September 3, 2026) gives the retention default: Input and Output kept “for thirty (30) rolling days to monitor abuse (unless zero data retention is activated).”

Cohere. From the Enterprise Data Commitments (last update December 5, 2025): “You can opt out from your prompts and generations being used to train Cohere models in your dashboard settings at any time … Adjust the toggle to ‘Off’ to opt out.” The page never says “on by default”; the presence of an opt-out toggle alone does not establish its initial state. On the SaaS platform, logged prompts and generations are deleted after 30 days, longer if flagged; zero data retention is by approval; and “your change in settings will apply to data created after you make that change.”

Together AI. The docs list two organisation-level toggles: “Store prompts and model responses: on by default. Stores prompts and outputs for product improvements.” And “Allow organization’s data for training: off by default.” Turning the first off is what the docs call zero data retention, and it “does not retroactively affect data processed before then” (Zero data retention). Passthrough models forward your request to an upstream provider under that provider’s policy.

Fireworks AI. Section 3.6 of the Terms of Service (last updated July 10, 2026): “We will not use your Content to train our own models or to improve the Service … our Zero Data Retention commitment applies to your use of the Service for inference. It does not apply to any feature of the Service that, by design, requires the retention or further processing of data … including, among other things, the Response API.” The docs give the number: Response API requests with store=True, the default, keep conversation data for 30 days, “designed to be consistent with the OpenAI API” (Data retention policies at Fireworks). Same trap, second vendor.

xAI. From the developer FAQ: “xAI never trains on your API inputs or outputs without your explicit permission. By default, all API requests and responses are stored on our servers (encrypted at rest) for 30 days for auditing purposes in the event of suspected abuse or misuse.” Zero data retention exists at team level, but the same page adds: “For most customers, we do not recommend enabling ZDR,” because it disables the stateful Responses API, Files and Collections, and Batch.

Moonshot AI. Section 4 of the Kimi Open Platform Terms (last updated July 30, 2026): “We may use Content to provide, maintain, develop, support, and improve the Services … Customer who requires restrictions on the use of Customer Content for training or improving Moonshot AI models may contact Moonshot AI to discuss available enterprise arrangements or separate written agreements. Unless otherwise expressly agreed in writing, Customer Content may be used for the foregoing purposes.” The Privacy Policy keeps “account, input, and payment information … while your account is active,” on Singapore servers.

Groq. The public privacy policy says: “This Policy does not apply to the information that we process as a ‘data processor’ on behalf of customers (‘Customer Data’) … governed by our Groq Services Agreement and Data Processing Addendum.” Both documents live on the console domain, which returned 403 to our fetches; an archived copy rendered as an empty shell. We do not know what they say.

Alibaba Model Studio. The help-centre page titled “Data privacy and security” renders client-side; every URL variant we tried returned an empty shell. Same treatment.

Retention: the 30-day number, and who does not give one

Default retention of API prompts and outputs when you do nothing, what extends it, and the path to zero.

The 30-day number is not a coincidence. Five providers land on it as their default: OpenAI, Anthropic, Mistral, Cohere, xAI. Fireworks copies it for its Responses API “to be consistent with the OpenAI API”. Google says “limited period” and gives no number. Thirty days is the industry’s abuse-monitoring window, and it means a month of your production prompts exists, verbatim, at every provider in that group, all the time.

The rows without a number are the ones to read twice. Account-lifetime retention (DeepSeek, Moonshot) and store-until-deleted defaults (Together, and OpenAI’s stateful endpoints) are not abuse windows. They are your data in someone else’s storage until you act, and also the easiest to fix: two have a self-serve switch, the other two a delete button.

Three things every clause has that the toggle does not cover

Reading twelve of these back to back surfaces patterns no single page advertises.

Every opt-out is prospective. OpenAI: “new conversations will not be used.” Together: zero data retention “does not retroactively affect data processed before then.” Cohere: “will apply to data created after you make that change.” Thom’s June 29 opt-out has the same property, and he says so. Whatever your provider held before you flipped the switch is governed by the terms in force when it was collected, and by the retention row above.

Feedback is a side door. At OpenAI, “the entire conversation associated with that feedback may be used to train our models,” even for opted-out users. At Anthropic, a thumbs up or down stores “the entire related conversation” for up to five years, and it “may” be used to train. At Mistral, feedback plus “the associated Input and Output” is used to train, with Mistral acting “as Controller” (Data Processing Addendum). If your product surfaces a rating button that forwards to the provider, your users’ opt-out status may not govern the rated conversation.

Flags extend retention, and so do frontier tiers. Anthropic keeps flagged content up to two years. Cohere may “retain and review” flagged prompts. OpenAI’s 30 days runs “unless … reasonably necessary to protect our services or any third party from harm.” Anthropic’s Covered Models policy, effective June 9, 2026, adds a category: for Mythos-class models, “prompts submitted to, and outputs generated by, covered models are retained for 30 days … on every platform where these models are offered,” including for organisations that otherwise have zero data retention (Data retention practices for Covered Models, read 2026-09-11). We wrote about the two-tier release pattern last week; this is its data-retention consequence. The most capable model on the menu may carry the least negotiable retention.

Opt-out solves a training-policy problem, not a trust-model problem

The sharpest framing of this week’s news is in a post by Koutian Wu, written on September 8: “‘Not used for training’ and ‘never processed, never stored, never touched’ are different claims. Opt-out gives you the first. Only architecture gives you the second.” And: “Opting out solves a training-policy problem. It does not remove the third-party from your trust model.” (“We Don’t Train on Your Data” Is a Promise. “Your Data Never Left Your Computer” Is a Fact.)

The twelve rows above are evidence for that framing, not a case against any provider. Every clause quoted here describes what the company will do with data it already holds. The abuse-monitoring log exists. The 30 days exist. Wherever a provider runs a de-identification step, its output exists too; OpenAI’s Navier–Stokes sentence refers to that output, not to any particular user. And the party that can check what happened to a given request is the provider, by construction. Thom called the opt-out “a promise whose implementation users cannot audit.” Wu called the gap an information asymmetry “baked into the architecture, not into anyone’s ethics.”

So “we don’t train on your API data” is a policy: true and useful at the six providers in the first group, and still revisable by the company, overridable by a court, verifiable by nobody outside.

A gateway is one more third party, and that includes this one

Routing traffic through an LLM gateway adds a party to the data path. We have written before that choosing a managed gateway over a self-hosted proxy moves the data path from your hands to a vendor’s. This article is the other half of that sentence: whoever holds the data path has a retention clause, and it belongs in the same table as the twelve above.

PiRouter is a gateway. Requests through it cross one more boundary before they reach anyone else in that table, so its own terms on logging and retention are as much a row in your spreadsheet as theirs, and should be read the same way: the page, the quote, the date. The docs are where to start. We are not going to tell you a gateway makes this problem go away, because nothing on the vendor side can.

What to do this week

1. List your endpoints, not your providers. OpenAI’s table is per endpoint and Fireworks copied the shape. A team that only calls /v1/audio/transcriptions has a different answer from one that calls /v1/responses with defaults.
2. Set store: false on /v1/responses at OpenAI and store=False at Fireworks, unless you rely on stateful features. Confirm in your own request logs that the field is sent.
3. Open the organisation-level settings at Together (two toggles), Cohere (Data Controls), and Mistral (per-product training preference). Write down what you found and the date.
4. Read your gateway’s clause with the same three questions: training default, retention default, who can turn it to zero.
5. Put the re-read on a schedule. Every page cited here carries an effective date between June 2025 and September 2026, and several changed this summer. The notice-period method applies: the clause tells you how often to look.

The one-paragraph version

OpenAI does not train on API data by default and has not since March 2023; this week’s threads concern the consumer toggle, which is a different regime. But the API answer has four columns, not one, and the retention column is per endpoint: transcription keeps nothing, chat keeps abuse logs for 30 days, Responses keeps state for 30 days unless you turn it off, and zero retention is granted by approval. Across twelve providers, six say no by default; DeepSeek and Moonshot permit training under their terms: DeepSeek names an opt-out right without a self-serve API control, while Moonshot points to a separate written agreement. Mistral’s clause leaves which products opt in by default unstated, Cohere’s page does not state the toggle’s default, and Groq and Alibaba Model Studio could not be verified from the pages read. Opt-outs described here apply prospectively; feedback is a side door, and flags and frontier tiers extend retention. An opt-out is a policy; it does not remove the third party from your trust model. A gateway is one more third party. Read its clause the same way.