System Prompt vs. User Prompt: What Belongs in Each When You Talk to ChatGPT, Claude, or Gemini

Ask ten people what they type into ChatGPT and most of them will describe the same thing: one block of text where they explain who the AI should be, what they want, and how the answer should look, all stitched into a single message and sent as one turn. That is not how the systems underneath ChatGPT, Claude, or Gemini are actually built to take instructions. All three separate the instruction that should hold true for an entire conversation from the specific thing you are asking for right now, and route them through two different channels — a system prompt and a user prompt — that the model treats differently even when the interface hides the seam between them. Knowing which channel you are actually writing into, and what belongs in each, is the difference between a persona that holds steady for fifteen messages and one that quietly erodes by message five.

What a system prompt actually does

A system prompt is the instruction the model treats as standing context for the whole conversation, not just the message you just sent. It is where role ("you are a patient, thorough coding tutor who explains the reasoning behind every fix"), rules ("never invent a citation — say so plainly if you do not know one"), formatting defaults ("always answer in short bullet points, never a wall of prose"), and boundaries ("do not provide medical dosages; suggest a professional instead") belong, because these are things that should stay true across every turn, not just the current one. Models are trained to give system-level instructions more durable weight than a similar instruction buried inside a regular message, which is exactly why a rule stated once in a system prompt tends to survive a long back-and-forth, while the same rule typed once in message three tends to get diluted as more recent instructions and context compete for the model’s attention by message eight.

What belongs in the user prompt instead

The user prompt is everything specific to the current turn: the actual question, the document you just pasted in, the one-off request that has no business applying to every future message in the conversation. Put a persistent rule in a user message and it usually survives fine for that message and maybe the next one, but it has no special standing once the conversation moves on, and it competes with whatever you type after it. Put a situational, one-off detail in the system prompt instead — "summarize the attached email in three bullet points" — and you have built a standing persona around a single task, so reusing that same system prompt for the next unrelated question leaves the model quietly expecting to summarize something when you are now asking about something else entirely. The dividing line worth remembering: system is for what is always true about this conversation, user is for what is only true about this one message.

How ChatGPT, Claude, and Gemini expose the split differently

All three products give you a system-prompt channel, but not the same way, and knowing which surface you are on changes what is actually available to you. ChatGPT’s consumer app exposes it as Custom Instructions in settings, plus Custom GPTs, which bake a standing system prompt into a reusable, shareable version of the assistant; through the API, developers set a dedicated system message that sits outside the regular back-and-forth entirely. Claude’s API treats the system prompt as its own top-level parameter, kept separate from the message list rather than living inside it as just another turn with a special label — inside Claude.ai itself, Projects let you attach standing instructions and reference material to every conversation started inside that project, which does the same job through a different name. Gemini’s API takes a dedicated system instruction field alongside the regular conversation, and on the consumer side, Gems are the equivalent: a saved persona with standing instructions that carries into every chat you start from it. Functionally, all three are doing the same job — a durable instruction kept separate from the message stream — the difference is only where you go to set it and what the product calls it.

The most common mistake: one message doing both jobs

The usual failure is not forgetting that a system prompt exists — it is cramming the persona, the rules, and the actual task into one message and sending all of it as a regular turn, because a plain chat box is the only input most people ever see. It works, in the sense that the model responds, but the rules that mattered most — tone, format, boundaries — end up carrying the same weight as the specific one-off request sitting right next to them, and by the third or fourth follow-up, the model has drifted back toward its default behavior because nothing is anchoring it there anymore. The fix is not a longer, more emphatic message — it is moving the durable half of that message into the channel actually built to hold it, and leaving the user message with only what is specific to that turn.

When you do not have system-prompt access at all

Plenty of situations put you in a plain chat window with no settings panel and no API key — a shared team account, an embedded chat widget on someone else’s site, a tool that simply does not expose the field. In that case you are stuck putting everything into one message, but you can still borrow the structure: state the persona and rules first, clearly separated from the request with a line break or a label like "Instructions:" followed by "Task:", and if you notice the model drifting over a long conversation, restate the single most important rule again near your latest message rather than assuming the one you stated at the start is still carrying weight. It is a workaround, not a substitute — a real system prompt still holds up better over a longer conversation, because the model is not just reading it as another message competing for space — but it recovers most of the benefit when the option genuinely is not there.

A simple way to split any prompt into both

Before sending anything, ask two separate questions: what should be true about every message in this conversation, and what is true about this message only. The answer to the first question — the role, the tone, the formatting rules, the boundaries — goes into the system prompt, Custom Instructions, Project, or Gem, whichever your tool happens to call it. The answer to the second question — the actual document, question, or task sitting in front of you right now — goes into the user message, and only there. A useful test: if an instruction would still make sense typed into the very first message of a brand-new, unrelated conversation, it belongs at the system level; if it only makes sense in the context of what you are asking this instant, it belongs at the user level. Most people who complain that a chatbot "forgot" an instruction mid-conversation did not actually lose it — they put a system-level rule into a user-level slot, and it got outcompeted the way anything sitting in that slot eventually does.

None of this calls for a more elaborate prompt, just the right box for each half of it. Put the durable half where the model is actually built to hold onto it, keep the situational half separate, and the "it worked great for the first three messages and then drifted" problem mostly disappears — not because the model got smarter, but because you stopped asking one channel to do two jobs at once.