Data Retention & What Goes Back

Detail

Per the Privacy Center: on consumer plans, conversations are saved to your account until you delete them. The governing setting’s printed label is “Help Improve our AI models” (Settings > Privacy — the Privacy Center’s walkthrough names the exact path and also calls it “the model training setting”; the storage article’s prose calls it “the model improvement setting”).

This label has now moved twice, and that is itself the teaching. The group’s own document and this curriculum’s first draft called it “Improve Claude for everyone”; that was corrected to “Help Improve Claude” on 2026-07-28 (receipts R33, R34). The page changed again on or before 2026-08-03, when a re-fetch found it printing “Help Improve our AI models” (receipt R68) — confirmed still current when this correction landed on 2026-08-10 (receipt R69). Both superseded phrasings now return zero hits on both chipped pages. What has not moved across any of those dates is the navigational path (Settings > Privacy) across the two historical label corrections. So: navigate by the path, not by the label — and if the words on your screen do not match the words here, that is the expected failure mode of a printed label, not evidence that the underlying rule changed. Check the date on this page and confirm with your Anthropic contact.

The setting’s reach, stated declaratively:

• On — new and resumed chats and coding sessions may be used for model training, and can be retained in de-identified form for up to 5 years in the training pipelines.
• Off — the settings walkthrough and storage article both say previously stored and new chats/coding sessions stop being used in future model training. Training already underway and already-trained models are not undone. Safety-classifier uses remain an explicit exception; feedback and other opt-ins have separate rules. The earlier narrower interpretation below is superseded by this complete reading of both paragraphs.
• Delete — the retention page gives a 30-day backend deletion period, with safety/legal exceptions. Flagged inputs/outputs may be retained up to two years and safety scores up to seven; applicable law, disputes and usage-policy enforcement can also extend retention. A chat-history deletion is not a promise that every separately retained record is erased.

Three scope facts that matter for this group: both articles scope themselves to “our consumer products such as Claude Free, Pro, Max and when accounts from those plans use Claude Code” — so consumer Claude Code sessions ride the same toggle, which is easy to miss when the coding surface feels separate from chat. Max is inside this claim, same as Free and Pro. And the toggle’s default for a new account is stated on neither page — the settings article gives change instructions only, and the storage article names no default (searched both, fetched 2026-07-28, for “default”, “by default”, “new account” — receipts R33, R34) — so “what happens if I do nothing?” is itself a confirm-don’t-assume item: Where to confirm the training toggle is off, plan by plan.

Source & currency

• Current verification — 2026-09-16 (receipts R70, R71, R72): Label/path and consumer scope checked on all three sources. Both paragraphs cover previous and new data in future training; safety-review and explicit-opt-in exceptions are now visible in the summary. Default-state and off-state-window absences were checked in the article bodies. No human clinical sign-off is implied.

• Earlier dated entries below are history, not the current verification date.

• Source: How long do you store my data? — Anthropic Privacy Center (cited by the source doc) + How do I change my model improvement privacy settings? (the settings walkthrough the label and path rest on — added 2026-07-28).

• Status: CONFIRMED 2026-08-10 (receipts R19, R31, R33, R34, R68, R69) — raised from ▪ at CG4, re-verified 2026-07-28 with the settings walkthrough added as a second source, and re-verified again 2026-08-10 with both sources re-fetched in one pass (R69, HTTP 200 each): every figure and commitment below stands verbatim, and the only change since ship is the toggle’s printed label (second drift — see the Detail note). Both figures are verbatim on the storage page: “we may retain your data in a de-identified format for up to 5 years in our model training pipelines” and, on deletion, “Deleted from our back-end storage systems within 30 days.” The page also scopes itself explicitly — “This article is about our consumer products such as Claude Free, Pro, Max and when accounts from those plans use Claude Code” — which is both why nothing here should be read across to a commercial plan and why consumer Claude Code sessions are inside the claim. The toggle’s label was corrected twice: on 2026-07-28 from “Improve Claude for everyone” to “Help Improve Claude” (receipts R33, R34), and again to “Help Improve our AI models” — the drift observed 2026-08-03 (receipt R68) and the correction landed 2026-08-10 after re-confirming the page still prints it (receipt R69). Both superseded phrasings now appear on neither chipped page — re-enumerated 2026-08-10, zero hits each. The storage article names no label at all in either state; it refers to “the model improvement setting” in prose, so the label rests on the settings walkthrough alone — a single-source fact, which is part of why it moves without warning.

• Why the chip could move on a claim that rests partly on an absence. This node carried ▪ because the OFF state has no published automatic retention window, and an unverified absence is not a verified fact. At CG4 the absence was verified rather than assumed, two ways (§4.4): every duration string on the page was enumerated — 30 days, 5 years, 2 years, 7 years, 5 years — and none is tied to the setting being off; and the OFF paragraph was read in full, where the page makes a use commitment (“we will not use your previous or new chats or coding sessions for future model training”) and not a retention one. The absence is now a finding with a receipt behind it, so the node states what the source states.

• One structural detail, recorded because it explains the gap without excusing it. The article carries a heading — “Standard Retention Timeframe” — with no text under it. The section that would name a default window is present and empty, confirmed in the page’s raw HTML across three independent retrievals. Read the honest claim precisely: no automatic retention window for the off state is published here, not your data is not retained when the setting is off. The page does not say the second thing, and the difference is exactly the sort a compliance decision turns on.

• ⚑ Compliance-critical: retention windows move — confirm current specifics with your Anthropic contact before relying on this for a compliance decision. This is a teaching aid, not compliance or legal advice.

Related

• Data Retention & What Goes Back — parent domain
• Commercial plans: no training by default and by contract — the exception is data you hand over yourself — the contractual opposite on Work/Education/Gov plans
• Where to confirm the training toggle is off, plan by plan — where the toggle actually lives, plan by plan
• Risk of using personal Pro/Max accounts for org work — why personal accounts for org work are the live risk here
• Retention (data) — the term, plainly
• Ensuring a rare disease is well-represented in the model — the same training pipeline, seen from the other side: the group also wants its disease represented in future models

Detail

The contractual commitment. Anthropic’s Commercial Terms of Service, §B (Customer Content): “Anthropic may not train models on Customer Content from Services.” “Customer Content” is defined in the same section as Inputs and Outputs together — your submissions and Claude’s responses. That sentence carries no toggle and no conditions.

The policy statement. Anthropic’s Privacy Center, in the article scoped to commercial products: “By default, we will not use your inputs or outputs from our commercial products (e.g. Claude for Work, Anthropic API, Claude Gov, etc.) to train our models.”

The exception — and it is the one that matters operationally. From the same article: “If you explicitly report feedback or bugs to us (e.g. via our thumbs up/down feedback button), or otherwise choose to allow us to use your data, then we may use your chats and coding sessions to train our models.”

This resolves an apparent discrepancy in the documentation. The API documentation phrases the commitment conditionally — “Retained data is never used for model training without your express permission” — which reads, in isolation, like a weaker promise than the Commercial Terms’ flat prohibition. They are consistent: feedback, bug reports and other explicit opt-ins are permission routes described by the policy. The button is not exclusive. This teaching does not decide how an organization’s executed contract applies to a specific submission.

What that means in practice. The structural difference between plan families holds: consumer plans govern training by a user-facing setting (Consumer plans: the training toggle governs training use — up to 5 years if on; no automatic window published if off); commercial plans are governed by contract, with an opt-in path rather than an opt-out toggle. For an organization deciding whether to standardize on an org plan rather than members’ personal accounts (Risk of using personal Pro/Max accounts for org work), this is a genuine argument in favor — but the policy exceptions require care around feedback, bug reports and other opt-ins. See The feedback button hands over the whole conversation for 5 years — and it, or a bug report, permits training: that button hands over the entire conversation, for five years, and may train on it.

Still worth asking your account team (Which contract terms actually govern the working group's accounts): confirm which contract governs each account, and whether your executed terms match the published Commercial Terms.

Source & currency

• Current verification — 2026-09-16 (receipts R73, R75, R76): All three cited sources re-fetched. The no-training commitment and policy exceptions remain; the residual button-only implication was removed. Historical corrections below remain visible.

• Earlier dated entries below are history, not the current verification date.

• Source: Is my data used for model training? — Anthropic Privacy Center, commercial · Anthropic Commercial Terms of Service §B · API and data retention.

• Status: CONFIRMED — re-verified 2026-07-28 (receipts R17, R18, R12, R36, R40) — all three passages verified on the live pages 2026-07-25 and re-verified 2026-07-28, when the API docs page (home of the “express permission” sentence the node reconciles) became the third chip.

• Correction history — worth reading, because this node was wrong twice in opposite directions. Before 2026-07-25 it claimed commercial data is “not used to train models — ever … not a setting someone could flip,” sourced to the consumer retention article, which excludes commercial readers by its own scope line. During the 2026-07-25 patient-safety round it was over-corrected to STALE-RISK on the reasoning that no source stated the commitment — but that check had only covered the retention articles, and the commitment is published in the training article and in the Commercial Terms. The independent review caught it the same day. Asserting a negative (“no source says this”) requires searching where the claim would actually live; a partial search reported the house empty after opening one drawer. The current text carries the commitment and its real exception.

• ⚑ Compliance-critical: plan-tier guarantees are contract terms — confirm your executed terms with your Anthropic contact before relying on this for a compliance decision. This is a teaching aid, not compliance or legal advice.

Related

• Data Retention & What Goes Back — parent domain
• Consumer plans: the training toggle governs training use — up to 5 years if on; no automatic window published if off — the consumer-side contrast, which is a toggle
• The feedback button hands over the whole conversation for 5 years — and it, or a bug report, permits training — the exception, in full: what the feedback button actually hands over
• Which contract terms actually govern the working group's accounts — confirming which contract governs each account
• Risk of using personal Pro/Max accounts for org work — the standardization decision this fact supports

On the 7-vs-30-day figure (resolved 2026-07-23): the working group’s own document recorded API log retention as 7 days. Current Anthropic documentation supersedes that — the standard is not retained by default, with a 30-day backend-deletion window where retention applies. Treat the doc’s 7-day figure as outdated. Retention stays compliance-critical: confirm current specifics with your Anthropic contact.

Detail

The API tier has the shortest default window of the product family — and the only fully negotiated one: ZDR, where data isn’t stored beyond real-time safety processing. Two sharp edges to carry with it: custom Skills sit outside ZDR (Agent Skills sit outside ZDR, and outside HIPAA coverage on the API path — Skills carry instructions, never data), and in the HIPAA context, Claude Code is BAA-covered only when ZDR is enabled — and ZDR blocks access to some newer models (Claude Code: not covered on the API path at all; on Enterprise only with ZDR. Cowork: not yet covered). ZDR is an arrangement you verify you actually have, not an assumption.

What “not retained by default” does not cover

Start with the exception the source attaches to the sentence itself, which the earlier version of this node dropped: “Conversation content (your prompts and Claude’s outputs) is not retained by default; the exception is Covered Models, which require 30-day retention.” Covered Models are named: “Claude Fable 5 and Claude Mythos 5 are designated Covered Models … and require 30-day data retention.” So if you are using Fable 5 or Mythos 5, your prompts and outputs are retained for 30 days — mandatorily, not as a fallback. This is the same rule that makes those models unavailable under ZDR, stated from the other side, and it applies to organizations that never considered ZDR at all. The 30-day requirement “applies wherever Covered Models are offered.”

Beyond that, several things sit outside the default, and one of them catches people building real tools:

• Files you upload stay until you delete them. The feature-eligibility table’s Files API row reads: “Files retained until explicitly deleted.” Upload a registry spreadsheet or a scanned document through the Files API and it persists — no 30-day clock, no ZDR coverage (the row is No for both ZDR and HIPAA). If you upload it, you own deleting it. Note the related distinction: HIPAA eligibility “applies to PDFs sent inline through the Messages API, not through the Files API.”
• Stateful features are stateful by design. The documentation is explicit that the “No” rows are not oversights: “Features marked ‘No’ for ZDR are fundamentally stateful: the Batch API stores your jobs, the Files API stores your files, and code execution runs in persistent containers. Data for these features is retained per the feature’s documented policy. Using them is a choice to step outside your ZDR arrangement for that specific data.”
• Flagged content and legal holds are retained regardless of arrangement — see the status note below.
• Other retention models sit alongside this page entirely: Compliance API data “follows its own retention model,” the Activity Feed “retains data for 6 years,” and claude.ai chat, file, and project content “follows your organization’s retention policy” set in Organization settings > Data and privacy — which means part of your retention posture is a control you hold, not one Anthropic sets.
• JSON schemas are cached separately and do not receive PHI protections — Never put PHI in a JSON schema — cached schemas are not protected like message content.

Source & currency

• Source: API and data retention — Claude platform docs + How long do you store my organization’s data? — Anthropic Privacy Center.
• Status: CONFIRMED 2026-07-23 — discrepancy resolved (receipts R20, R21, re-fetched this round): “Conversation content (your prompts and Claude’s outputs) is not retained by default” (R20); “we automatically delete inputs and outputs on our backend within 30 days of receipt or generation” (R21). The source doc’s earlier 7-day figure did not corroborate on any current primary source and is treated as outdated — the current standard is not-retained-by-default with a 30-day backend-deletion window. ZDR is per-organization. Exception (retained regardless of arrangement): flagged content may be retained up to 2 years (safety-classification scores up to 7 years), plus legal holds. Re-verified 2026-07-28 (receipts R36, R38) when the Privacy Center storage article — the page the 30-day deletion figure is quoted from — joined the chip list. Re-verified and expanded 2026-07-25 (receipt R12): the exception surface now also states the Files-API “retained until explicitly deleted” rule, the stateful-features principle in the documentation’s own words, and the retention models that sit outside this page (Compliance API, 6-year Activity Feed, org-configurable claude.ai retention). The Files-API case is the sharpest for this audience — an uploaded registry file has no expiry clock. Corrected the same day, after independent review: the node had quoted “not retained by default” while truncating the clause that follows it in the source — “the exception is Covered Models, which require 30-day retention” — and the Covered-Models rule appeared nowhere else here. That was an understatement of exposure (the only one this round produced) on a node whose title is the reassurance line; the mandatory 30-day retention is now stated first among the exceptions. ⚑ Compliance-critical: confirm current specifics with your Anthropic contact before relying on this for a compliance decision. Teaching aid, not compliance or legal advice.

Related

• Data Retention & What Goes Back — parent domain
• Agent Skills sit outside ZDR, and outside HIPAA coverage on the API path — Skills carry instructions, never data — the ZDR carve-out every Skill builder must know
• Claude Code: not covered on the API path at all; on Enterprise only with ZDR. Cowork: not yet covered — where ZDR meets BAA coverage
• Never put PHI in a JSON schema — cached schemas are not protected like message content — “prompts not stored” does not extend to the cached JSON schema
• ZDR — Zero Data Retention — the term, plainly
• Covered Model — the designation behind the mandatory-retention exception

Detail

Both exclusions, from the same feature-eligibility table. The API documentation’s row for Agent skills marks it No for ZDR and No for HIPAA, with the note: “Skill data retained per standard policy.” The Agent Skills documentation states the ZDR half in its own words: “Agent Skills is not covered by ZDR arrangements. Skill definitions and execution data are retained according to Anthropic’s standard data retention policy.”

Scope note — read this before quoting the HIPAA half. That table’s own lead sentence scopes it: “The following table lists which Claude API features are eligible for ZDR and HIPAA readiness arrangements.” So the No/No is documented for the API path. On the Enterprise path, the authority is a different document, and the Help Center says so plainly: “The Implementation Guide for HIPAA Entities on the Anthropic Trust Center lists every feature’s status and is the authoritative source.” That guide is access-gated, so this curriculum cannot verify the Enterprise-side status of Skills — and will not guess it. If you are on Enterprise with a BAA, check the Implementation Guide for Skills specifically rather than assuming either way.

Why the HIPAA half is the one that was missing here. For a clinician or a registry-handling nonprofit, “is it under our BAA?” is the primary question, and this curriculum previously answered only the ZDR question — leaving a reader with a BAA to assume their Skills were covered by it. On the API path they are documented as not covered. Either way the prudential rule below holds, which is why the design advice does not depend on resolving the Enterprise question.

The design rule this produces — treat it as first-class, not a footnote: a Skill carries instructions, never data. Every use case this curriculum teaches (Skills) is a method — an abstract-review rubric, a house style, an intake template, a minutes format, a lay-summary pattern. None of them needs a real patient record inside the Skill to work. That is fortunate, because the retention posture means anything you did put inside would follow standard retention regardless of your ZDR or HIPAA arrangements. Good Skill design and safe Skill design are the same discipline here.

The group’s own version of this question for the contact: Retention considerations specific to Skills, outside ZDR.

Source & currency

• Source: API and data retention — Claude Docs (the feature-eligibility table: Agent skills — ZDR No, HIPAA No) · Agent Skills overview — Claude Docs §Data retention.
• Status: CONFIRMED — re-verified 2026-07-28 (receipts R12, R15, R35) — both passages verified on the live pages 2026-07-25 and re-verified 2026-07-28 via the Agent Skills overview, whose own Data-retention section states the exclusion (“Agent Skills is not covered by ZDR arrangements”) and which joined the chip list that day. R35 is this node’s 2026-07-28 evidence row; the API-retention page stays the chip for the eligibility-table claim, on its 2026-07-25 verification (receipt R12). Corrected 2026-07-25 on two counts: (1) the node taught only the ZDR carve-out and never stated the HIPAA exclusion, which for a PHI-handling reader is the more consequential of the two; (2) the source: chip pointed at the consumer retention article while the status block cited the API table — the chip now points at the document the claim actually comes from.
• ⚑ Compliance-critical: ZDR and HIPAA coverage boundaries move — confirm current specifics with your Anthropic contact before relying on this for a compliance decision. This is a teaching aid, not compliance or legal advice.

Related

• Data Retention & What Goes Back — parent domain
• API: content not retained by default; inputs/outputs deleted within 30 days; ZDR negotiable — the ZDR baseline this claim carves out of
• Most ways of using Claude are never covered by Anthropic's BAA — and on two cloud platforms, coverage is someone else's call — the coverage picture this exclusion belongs to
• Retention considerations specific to Skills, outside ZDR — the working group’s bring-to-the-call version
• Skills — where Skills are taught (build them data-free)
• ZDR — Zero Data Retention — the arrangement Skills sit outside of
• Skill (Claude) — the term, plainly

Detail

What is retained, and for how long. Identical wording on both the consumer and the commercial retention policies: “Where you have provided feedback to us (e.g. by submitting feedback through our thumbs up/down button or sent bug reports), we retain data associated with that submission for 5 years.” The training article is more specific about the scope: “When you provide us feedback via our thumbs up / down button, we will store the entire related conversation, including any content, custom styles, conversation preferences, or model settings, in our secured back-end for up to 5 years.” Not the rated message — the conversation.

What it permits. This is the sharp edge. Commercial plans are not trained on by default (Commercial plans: no training by default and by contract — the exception is data you hand over yourself) — but: “If you explicitly report feedback or bugs to us (e.g. via our thumbs up/down feedback button), or otherwise choose to allow us to use your data, then we may use your chats and coding sessions to train our models.” The API documentation’s phrase “never used for model training without your express permission” describes exactly this: the feedback button is one way express permission is given. This is a published policy exception; how an executed contract applies is a question for the organization and its advisers.

Read that quoted sentence carefully, because the list is not one item long. It names feedback, bug reports, and “otherwise choose to allow us to use your data” — three routes, not one. An earlier version of this node called the feedback button “the one thing that permits training”, which was wrong in the dangerous direction: a reader who had memorised it would have believed a bug report was safe to file with patient detail in it. It is not. Whatever discipline you apply to the thumbs-up button, apply identically to the bug-report form.

One limit worth knowing, from the same source: “Feedback data does not include raw content from connectors (e.g. Google Drive), including remote and local MCP servers — though data may be included if it’s directly copied into your conversation with Claude.” So a connector-sourced document is not swept in by reference; a passage you pasted is.

Three further properties:

1. Plan-independent. The same 5-year sentence is published for consumer products and for organization data. Check any negotiated terms separately; this describes the published policies.
2. Outside the training toggle. The “Help Improve our AI models” model-improvement setting (Consumer plans: the training toggle governs training use — up to 5 years if on; no automatic window published if off) does not govern this; turning it off does not turn this off.
3. Deleting the chat does not undo it. Retention attaches to the submission, not to the conversation in your history — and “your data will still be included in model training runs that are already in progress, or in models that have been trained” (Actual timeline to purge data after deletion).

The practical teaching. The feedback buttons are the most frictionless controls in the interface and they carry the longest ordinary-use retention window plus a training permission. The habit to build: if an exchange contains patient information, member-identifying detail, or anything you would not want held for five years or trained on — do not rate it, and do not attach it to a bug report. Reproduce the problem with a sanitized example, then rate that. This is the single highest-value habit in this module, because feedback and bug reports can create a separate retention and training path.

Source & currency

• Current verification — 2026-09-16 (receipts R71, R73, R74): Consumer and organization retention pages plus commercial training article re-fetched. Feedback, bugs and other permission remain non-exclusive. The label matches the separately verified settings node (receipt R70). Contract-waiver and plan-tier absolutes were removed.

• Earlier dated entries below are history, not the current verification date.

• Source: How long do you store my organization’s data? (commercial) and How long do you store my data? (consumer) — the 5-year sentence is identical on both · Is my data used for model training? — the entire-conversation scope, the training permission, and the connector limit.

• Status: CONFIRMED — re-verified 2026-07-28 (receipts R13, R14, R18, R34, R38, R40) — verified verbatim on all three live pages 2026-07-25 and again 2026-07-28, when all three joined the chip list (the chip previously named one of them). The “identical on both” claim about the 5-year sentence was re-verified byte-for-byte across both storage articles before re-chipping, not assumed. Node created 2026-07-25: the 5-year feedback window was absent from this curriculum entirely. Expanded the same day, after independent review, with the two facts that make it consequential rather than merely notable — the entire conversation is stored, and feedback is an act that permits training on commercial data.

• Correction 2026-08-10 (CG8 red-team RT-4, permissive-direction over-claim). The title, plain-language line, Detail, and the printed one-pager rule all said the feedback button was “the one thing” that permits training. The node’s own quoted source says otherwise — “If you explicitly report feedback or bugs to us … or otherwise choose to allow us to use your data” — and the node’s own practical teaching already said not to attach sensitive material to a bug report. The exclusive phrasing was therefore contradicted by the evidence on the same page, and it failed in the direction that clears a risk rather than flagging one: a reader relying on the printed rule would have believed a PHI-bearing bug report was safe. Corrected to non-exclusive phrasing at all four sites plus the domain hub’s one-pager gloss (five in total; the phrase was enumerated across what/graph/ and site/src/ before the edit, and the three other “one thing”/“only thing” hits are unrelated sentences in other nodes). No source re-fetch was required or performed — this is a correction of our wording against a quote already receipted, so retrieved: deliberately stays 2026-07-28.

• ⚑ Compliance-critical: confirm current specifics with your Anthropic contact before relying on this for a compliance decision. This is a teaching aid, not compliance or legal advice.

Related

• Data Retention & What Goes Back — parent domain
• Commercial plans: no training by default and by contract — the exception is data you hand over yourself — the training question, which this is independent of
• Consumer plans: the training toggle governs training use — up to 5 years if on; no automatic window published if off — the setting that does not govern this
• Actual timeline to purge data after deletion — the companion lesson: what deletion does and does not reach
• Which contract terms actually govern the working group's accounts — worth raising in the same conversation with your account team

Detail

This is a false-safety trap, and it is the kind a careful person walks into. Someone about to type something sensitive — a family’s situation, a case detail, a draft that quotes a patient — reaches for the most private-looking option on the screen. The name and the ghost icon both suggest the conversation evaporates. On a Team or Enterprise plan, it does not.

What incognito actually does. The source is direct: “Incognito chats are temporary conversations that aren’t saved to your chat history or to Claude’s memory.” Three further protections are real and worth having — “Incognito chats are not used for training”; “Claude won’t pull information from incognito chats when searching previous conversations”; and, if memory is in use, “Starting an incognito chat won’t use Claude’s existing memory” and “Incognito chats will not be included in future memory entries.” It is available on every plan: “Incognito chats are available to all Claude users (Free, Pro, Max, Team, and Enterprise plans).”

What it does not do. Retention is stated plainly, and it applies to the plans an organization is most likely to be on: “While incognito chats aren’t saved to your chat history, they are retained for either 30 days (default), or longer in accordance with your organization’s custom data retention setting (available for Enterprise plans).” The article then gives Team and Enterprise their own section, and all three of its points cut against the intuition the name creates:

• “Incognito chats are included in organizational data exports available to account Owners.”
• “While incognito chats aren’t saved to your chat history, they are retained for 30 days for safety, or longer in accordance with your organization’s data retention policy.”
• “Incognito chats are included in the Compliance API (available for Enterprise plans).”

Read the second and third together with the first: on an Enterprise plan, an incognito chat can be retained longer than 30 days — because a longer organizational retention policy extends it, not just shortens it — and it is reachable by both the export route and the compliance-tooling route. So the surface a staff member picked because it looked private is, on these plans, one of the more visible surfaces in the product from the organization’s point of view.

Two smaller edges that matter operationally. Incognito is not available inside Projects — “Incognito mode is currently only available for chats outside of projects, so you will not see the ghost icon when starting a chat within a project” — so it is unavailable in exactly the structured workspaces where a group is most likely to have organised its work. And it is one-way and unrecoverable: “once you start an incognito chat, it cannot be converted to a regular chat or saved to your history”, and “Once closed, incognito chats cannot be reopened.” Anything worth keeping must be copied out before the window closes. Note also that Claude still sees your profile: asked whether it can access custom styles and personal preferences in an incognito chat, the article answers “Yes, Claude can access this information within an incognito chat.”

What to teach. Incognito is a good tool for the thing it actually is — keeping clutter, exploratory drafting, or a personal aside out of your own history and out of Claude’s memory. It is not a control for sensitive data, and it must never be the reason someone decides it is safe to type patient information. The decision about whether patient data may enter a surface at all is governed by your organization’s arrangement and the surface’s coverage, not by whether a chat is incognito — see API: content not retained by default; inputs/outputs deleted within 30 days; ZDR negotiable for the retention baseline and the exceptions that survive any setting.

Source & currency

• Source: Use incognito chats — Claude Help Center (stamped “Updated over a week ago” at retrieval).
• Status: CONFIRMED 2026-07-28 (receipt R59) — every quoted passage verified on the live page this date, from extracted body text rather than raw HTML. Node created 2026-07-28: incognito chats were absent from this curriculum entirely, and the gap mattered more than most, because the feature’s name actively teaches the wrong conclusion to precisely the reader this site is written for.
• ⚑ Compliance-critical: confirm current specifics with your Anthropic contact before relying on this for a compliance decision. This is a teaching aid, not compliance or legal advice.

Related

• Data Retention & What Goes Back — parent domain
• API: content not retained by default; inputs/outputs deleted within 30 days; ZDR negotiable — the retention baseline, and the exceptions that survive whatever setting you choose
• Consumer plans: the training toggle governs training use — up to 5 years if on; no automatic window published if off — the other place a per-user control is mistaken for an organizational guarantee
• Retention (data) — what retention means, plainly
• Retention — connections (the compliance spine crosses here) — the compliance spine this sits on

Detail

The newest models are Covered Models (Covered Model), and they carry a mandatory retention window: “Claude Fable 5 and Claude Mythos 5 are designated Covered Models … and require 30-day data retention; ZDR is therefore not available for either model.” An organization configured for zero data retention that calls one of them gets a refusal, and the error message is itself the clue to the way out — it names two levels, not one: “In order to access this model, your organization or workspace must have data retention enabled.”

The documented mechanism. Under a heading of its own, “Enable 30-day retention for a workspace”: “Organizations with a ZDR arrangement can make Claude Fable 5 and Claude Mythos 5 available in a specific workspace by enabling 30-day retention for that workspace only. Other workspaces in the organization keep zero data retention.” The steps are short — in Claude Console > Settings > Workspaces, select the workspace and open its Privacy controls tab, then “Enable the 30-day data retention setting for the workspace.” After that, “Requests to Claude Fable 5 and Claude Mythos 5 from this workspace now succeed. Workspaces without an override continue to follow the organization default.”

Why this matters to a group handling patient data. It converts an all-or-nothing decision into a design decision. A group can keep the workspace where sensitive work happens at zero retention, and put the work that genuinely needs the newest reasoning — literature synthesis, methods drafting, code — in a separate workspace that carries the 30-day window. The boundary is the workspace, so the boundary has to be real: which work lives where becomes a policy your group writes and enforces, not a setting Anthropic enforces for you.

And the trap, stated plainly. Switching the override on does not buy the newest models and keep zero retention in that workspace. It trades one for the other, inside that workspace. Prompts and outputs sent from it are retained for at least 30 days. Anthropic’s Covered Models policy is explicit that the retention is a floor and that automated inspection applies to it: retained data is “retained for at least 30 days and then automatically deleted, unless they are subject to a safety investigation or we are legally required to maintain them”, and “Retained data is assessed by automated safety systems designed to flag harmful content.” So a workspace with the override on is the wrong home for anything your zero-retention arrangement exists to protect. If someone enables it for convenience and the boundary is not enforced in practice, the organization has quietly moved sensitive work into a retained, machine-inspected surface without anyone deciding to.

Two scope notes. This is an API / Claude Console mechanism — it is about workspaces on the developer platform, not about how claude.ai conversations are governed. And the retention requirement travels with the model rather than with the platform: “The 30-day data retention requirement applies wherever Covered Models are offered.” Separately, HIPAA readiness does not work this way — it “is enforced at the organization level”, which is why mixed workloads need separate organizations rather than separate workspaces (Enabling HIPAA does not cover every feature — coverage is decided feature by feature carries the coverage picture). Retention granularity and HIPAA granularity are different, and assuming one from the other is the error to avoid.

Source & currency

• Source: API and data retention — Claude Docs (§Model-specific data retention requirements, §Enable 30-day retention for a workspace) · Covered Models — Claude Help Center (the at-least-30-days floor and the automated-review statement).
• Status: CONFIRMED 2026-07-28 (receipts R60, R61) — every quoted passage verified on the live pages this date, from the documentation’s .md source endpoint and from extracted body text rather than raw HTML. Node created 2026-07-28: workspace-scoped retention appeared nowhere in this curriculum, which described the retention posture only at organization scale.
• ⚑ Compliance-critical: retention mechanics and model designations move — confirm current specifics with your Anthropic contact before relying on this for a compliance decision. This is a teaching aid, not compliance or legal advice.

Related

• Data Retention & What Goes Back — parent domain
• API: content not retained by default; inputs/outputs deleted within 30 days; ZDR negotiable — the organization-scale baseline this adds a workspace-scale control beneath
• Covered Model — the designation that creates the mandatory window
• ZDR — Zero Data Retention — the arrangement the override carves a hole in, deliberately and in one place only
• Enabling HIPAA does not cover every feature — coverage is decided feature by feature — the contrast: HIPAA readiness is enforced at organization level, so it does not have a per-workspace equivalent
• Retention — connections (the compliance spine crosses here) — the compliance spine this sits on