How to Train ChatGPT on Your Data (and What That Actually Means)

You've seen the advice everywhere: "train ChatGPT on your data" to get better answers. The phrase implies you're adjusting the model itself, turning dials, changing weights. You're not. Understanding how to train ChatGPT on your data starts with understanding that none of the consumer-facing personalization tools change the underlying model at all. What they do is interesting, useful, and worth configuring carefully. But it is not training. This piece explains what actually happens when you set custom instructions, when memories get saved, and when the new background synthesis system rewrites what the model thinks it knows about you. If you want control over the process, you need to know the machinery.

Key Takeaways

Custom instructions, saved memories, and background synthesis are three distinct mechanisms. None of them modify model weights. They inject context into your prompt at inference time.
The newest memory architecture ("Dreaming V3") infers relationships and priorities from your conversation history without being asked, shifting from storage to inference. This is powerful but harder to audit than the older explicit-memory list.
Custom instructions were recently expanded to 5,000 characters for paid tiers, giving you meaningful room to define role, tone, format, and domain constraints in a persistent system prompt.
The "Improve the model for everyone" toggle and memory are separate settings. Turning off training does not turn off memory, and vice versa.
If auditability matters to you (it should), you need to understand where your data lives, what gets inferred versus what you explicitly set, and what "delete" actually removes.

What Does "Training" Mean When Users Say It?

Almost always, they mean "getting ChatGPT to respond the way I want, consistently." That is a reasonable goal. But the word "training" in machine learning has a precise meaning: updating model parameters using data. When you type custom instructions or let the model save a memory, no gradient is computed. No weight changes. The model that responds to you is the same model that responds to everyone else on the same tier.

What you're actually doing falls into three categories, each with different mechanics and different tradeoffs.

How Do Custom Instructions Work Under the Hood?

Custom instructions are a persistent system-prompt injection. You write text in two fields ("What would you like ChatGPT to know about you?" and "How would you like ChatGPT to respond?"), and that text gets prepended to every conversation you start. The model sees it as though you typed it at the top of the chat, every time, automatically.

This is not subtle engineering. It is string concatenation. And that's fine, because it works. The constraint has always been length. Until recently, custom instructions were capped at 1,500 characters per field. As of July 15, 2026, that limit was raised to 5,000 characters for Plus, Pro, Enterprise, Business, and Education users. That's a meaningful change. 1,500 characters forced you to make tradeoffs (do I specify my tech stack or my writing style?). 5,000 gives you room for both, plus format constraints, domain-specific terminology, and role definitions.

The important properties of custom instructions:

They are static. They do not change unless you change them.
They are fully auditable. You wrote them. You can read them. You know exactly what the model sees.
They consume context window. Those 5,000 characters are tokens the model could otherwise use for your conversation. On a long chat, this matters.
They apply globally. You cannot scope them to specific topics or projects without manual toggling.

If you want deterministic, predictable personalization, custom instructions are the mechanism. They are blunt, transparent, and yours to control.

What Is the Difference Between Saved Memories and Background Synthesis?

There are two distinct memory systems, and they work very differently.

Saved memories are the older mechanism. During a conversation, the model decides (or you tell it) to remember a fact: "I use Python 3.12," "My company sells industrial sensors," "I prefer concise answers." These get stored as an explicit, user-editable list. You can view every item, delete individual entries, or clear the whole list. At the start of each conversation, relevant saved memories are retrieved and injected into the prompt, similar to custom instructions but dynamic.

This system had clear virtues. You could see what the model "knew." You could correct it. The relationship between stored data and model behavior was traceable.

Background synthesis, shipped June 4, 2026 under the internal name "Dreaming V3," is architecturally different. A background process runs after your conversations end, reads across your full conversation history, and updates what the model knows about you. You do not ask it to remember anything. It infers relationships, priorities, and patterns on its own.

The technical shift is from storage to inference. The older system stored explicit facts you surfaced. The new system transforms raw memory fragments into structured "memory chains" with weighted relationships between facts. It infers that because you mentioned a Singapore trip in June and asked about humidity in July, your trip has concluded, and it rewrites "the user is going to Singapore" to "the user went to Singapore in July 2026" without you doing anything.

This is qualitatively different from a key-value store. It is a profile-building system that runs during idle time, approximately five times more compute-efficient than doing the same work during live chat because synthesis moved into offline batch processing.

Why Does the Shift from Storage to Inference Matter?

Because it changes what you can audit.

The older saved-memories list was transparent. You could inspect it, item by item. If the model said something unexpected, you could check whether a stored memory caused it. The new system is more opaque. It draws inferences from years of conversation history, and what it infers about your role, priorities, or habits isn't directly visible in the same way.

New controls were shipped alongside: a memory summary page listing inferences by topic with timestamps, the ability to mark an inference wrong, tell the model to stop bringing up a topic, or remove an item outright. There's an in-chat "don't mention this again" control. These are real improvements. But they're after-the-fact corrections to a system that runs autonomously, not beforehand approvals of what gets synthesized.

A 2026 study presented at the ACM CHI Conference put a name to this: the "personalization-convenience paradox." The feature most users value (the model remembering context without being told) is the feature most users cannot fully audit or constrain. This is not a hypothetical concern. It's a measured user-experience finding.

Does Any of This Actually Change the Model?

No. This is the single most important thing to understand. Custom instructions, saved memories, and background synthesis all operate at the prompt layer. They add context to your input before the model processes it. The model's weights remain identical to every other user's instance on the same version.

Think of it this way: you're not retraining a chef. You're handing the same chef a longer note before each meal. The chef's skills don't change. The note just gets more detailed.

This distinction matters for several reasons:

Deletion is real. Because your data is context injection, not weight modification, deleting a memory or custom instruction actually removes its influence. The model doesn't "still know" something you deleted. It literally never knew it. It was reading a note, and now the note is gone.
There is no "un-training" problem. Fine-tuning model weights creates a genuine un-training challenge (you can't surgically remove a single data point's influence from a gradient update). Prompt injection has none of this. Remove the injected text, and it's removed.
Your data's influence is bounded. Custom instructions can't make the model know something outside its training data. They can bias the model toward certain framings, formats, or assumptions, but they can't teach it new facts about the world. If you inject "the capital of France is Berlin," the model will likely still say Paris. (It might hesitate, though, which is its own problem.)

What About the "Improve the Model for Everyone" Toggle?

This is separate from memory entirely, and conflating the two is a common mistake.

The training toggle controls whether your conversations can be used to fine-tune future model versions. For Free, Plus, and Pro accounts, this is controlled by an opt-out toggle. Team, Enterprise, and Education plans are not used for training by default.

Turning off training does not turn off memory. Turning off memory does not turn off training. They are independent settings governing independent processes. One feeds future model development. The other personalizes your current experience. You can have both on, both off, or either combination.

If you care about whether your data influences the model for other users: that's the training toggle. If you care about whether the model remembers your preferences across sessions: that's memory. If you care about both, configure both.

How Should You Actually Configure Custom Instructions?

Treat them like a system prompt for an API integration, because that's what they are.

With 5,000 characters available on paid tiers, you have room to be specific. Here's what actually works, based on running production systems that rely heavily on persistent context:

State your role and domain explicitly. "I'm a backend engineer working primarily in Go and PostgreSQL" is more useful than "I'm a programmer." The model calibrates terminology, assumed knowledge level, and example complexity based on this.

Specify output format. "Always use code fences with language tags. Never use placeholder code without marking it clearly. When I ask for a SQL query, assume PostgreSQL 16 syntax" saves you from correcting format on every response.

Set negative constraints. "Do not explain basic concepts unless I ask. Do not add caveats about consulting a professional. Do not use bullet points unless the content is genuinely a list." Negative instructions are surprisingly effective at removing filler.

Define your preferred reasoning style. "Show your reasoning before the conclusion" or "Give the answer first, then explain if I ask" are instructions the model follows reliably.

What doesn't work well: vague aspirational instructions ("be creative," "think outside the box"), instructions that contradict the model's safety training (these get overridden), and overly long instructions that consume too much context window on short conversations.

What Happens When Custom Instructions and Memory Conflict?

This is a real problem with no clean answer. If your custom instructions say "always respond in British English" but a synthesized memory infers from your conversation history that you prefer American spelling, the model has to resolve the conflict at inference time. There is no documented priority hierarchy. In practice, the model tends to weight the most recent and most specific instruction, but "tends to" is not "reliably does."

The mitigation is straightforward: keep your custom instructions authoritative on matters of format, tone, and role, and let memory handle factual context (your projects, your tech stack, your preferences that evolve over time). When there's a conflict, your explicit custom instructions should be the thing you trust. If the model starts overriding them based on inferred memory, that's a signal to review and prune the memory summary.

What Are the Regulatory Implications of Background Synthesis?

They are significant and time-sensitive. Under GDPR, AI systems that build persistent behavioral profiles are classified as profiling activities that trigger consent obligations and the right to erasure. The EU AI Act's transparency obligations for chatbot systems are scheduled to take effect August 2, 2026. Background synthesis, by definition, builds a persistent profile from behavioral data.

For individual users, this means your right to deletion is not limited to "delete my conversations." It extends to any profile data derived from those conversations. If you delete a chat, the inferences drawn from that chat should, in principle, also be purged.

For business users, particularly those in regulated industries, this creates a data-residency and audit question that needs answering before deploying any AI assistant with persistent memory at the organizational level. What was inferred? From what data? Where is it stored? Can it be exported for audit? Can it be selectively deleted? These are questions you should be asking any vendor, including us.

How Does This Compare to Using the API Directly?

If you're a developer, the API gives you full control over exactly this problem. You manage your own context injection. You decide what gets prepended to each request. You store your own user profiles in your own database. Nothing is inferred without your code doing the inferring.

The tradeoff is that you build and maintain everything. Custom instructions, saved memories, and background synthesis are the consumer-facing UX for a problem that API users solve with their own retrieval-augmented generation (RAG) pipelines, vector databases, and session management code. The consumer features are more convenient and less controllable. The API is less convenient and fully controllable.

There is no in-between product from the major providers. You either use the consumer chat product with its autonomous memory management, or you build your own stack on the API.

We found this gap frustrating enough to build into. Selina runs on a stack of frontier models, routed per task, but the memory layer is ours. It's adaptive, encrypted at rest, and does not synthesize inferences about you in an opaque background process. You control what it remembers. What you delete is gone. Actually gone. This is a deliberate architectural choice, not an oversight. The model is not the moat. The memory is the moat, and memory only works as a moat if the user trusts it enough to put real context into it.

What Should You Actually Do?

If you're configuring a frontier chat product for daily use, here's a concrete sequence:

Write your custom instructions first. Treat them as your constitution. Role, domain, format, negative constraints. Use the full character limit if you have meaningful things to specify. Don't pad.
Review your saved memories periodically. Open the memory management page and read what's there. Delete anything outdated, wrong, or overly specific. If you told the model about a project that ended six months ago, remove it. Stale context degrades response quality.
Understand what background synthesis is doing. If the memory summary page shows inferences you didn't expect, that tells you something about what the system is prioritizing. Correct or remove inferences that mischaracterize your work or preferences.
Separate your training toggle from your memory settings. Make a conscious decision about each. Do not assume that one controls the other.
If you're using this for work, check your organization's data policy. Persistent AI memory in a chat product is not the same as an internal tool. Understand what your organization permits before putting proprietary context into a consumer memory system.

Why "Training" Is Still the Wrong Word

The word "training" implies permanence and reciprocity. You train the model, the model learns, the learning persists. None of that is happening in the consumer product. You are writing a longer and longer note. The model reads the note at the start of each conversation and throws it away when the session ends. The note persists (in memory storage), but the model's understanding does not.

This is actually good news for control. It means your personalization is modular, deletable, and inspectable (at least in principle, with the caveats above about background synthesis opacity). You are not locked into a model that has "learned" your bad habits. You can rewrite the note anytime.

But it also means there are limits. The model cannot learn new capabilities from your data. It cannot update its knowledge cutoff based on your documents. It cannot acquire skills it wasn't trained with. You are steering, not teaching. The distinction matters every time you hit a wall and wonder why "training" isn't working. It's not working because you weren't training. You were configuring. And configuration has different failure modes than training.

Get clear on the machinery, and the machinery works for you. Confuse it with something it isn't, and you'll spend your time fighting the wrong constraints.

Start a free 7-day trial if you want memory you control, on models you don't have to manage. No card required.

Sources & References

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.