System Prompts, Custom Instructions, and Project Instructions: Who’s Really in Charge?

System Prompt vs Custom Instructions

A system prompt is the instruction set written by the company that built the model. It defines the assistant’s identity, its capabilities and its safety limits, it applies to every user, and you can neither see it nor change it. Custom instructions are the preferences you save in your own settings, which the tool attaches to your chats automatically. One is the building’s fire code. The other is how you arrange your desk.

The confusion around the two is not your fault. Developers use “system prompt” for a specific technical field in an API call. Product teams use it loosely for anything that behaves like a standing instruction. Both meanings float through the same search results, which is why you can read five articles on system prompt vs custom instructions and still not know what happens when your saved rule collides with the one you just typed.

The layer you cannot touch

Layer one is absolute. No phrasing, no roleplay framing and no amount of insistence moves a platform safety rule, because that layer was applied before your message ever reached the model. Recognising this saves real time: when a tool refuses something, hedges heavily or adds a disclaimer you did not ask for, that is almost always layer one, and rewriting your prompt for the fourth time will not change it.

Most experienced operations leads learn this the expensive way, after an afternoon spent trying to argue an assistant out of a caveat. The useful response is to change the task, not the wording.

The three layers you control

Everything below layer one is yours, and each layer has a different reach. Account instructions follow you everywhere. Workspace instructions apply inside one project and, on ChatGPT at least, explicitly beat your account settings there. The prompt you type steers a single answer without changing anything standing behind it.

That reach difference is the whole game. A rule with the wrong reach either bleeds into work where it does not belong, or fails to show up in the work where you needed it.

Where Each Layer Actually Lives

Most system prompt vs custom instructions explainers stop at the definitions, which is where they stop being useful. All three major tools now offer both an account-level instruction box and a workspace-level one, and — this is the part most guides still get wrong — all three offer both on their free plans. Where they differ is in what the workspace layer does to the account layer.

ChatGPT: settings and projects

Your account box sits under Settings, then Personalization, on web and desktop; on iOS and Android it is Settings, then Customize ChatGPT. Our walkthrough on setting up ChatGPT custom instructions covers what actually belongs in that box. How much you can write there depends on your plan:

• Free and Go accounts — up to 1,500 characters
• Plus, Pro, Business, Enterprise and Education — up to 5,000, following an increase in July 2026

The override rule is stated plainly in OpenAI’s own Projects documentation: project instructions apply only inside that project, and they override your global custom instructions. That single sentence explains an enormous share of confused forum threads. If you have organised your work into ChatGPT Projects and set instructions there, your account preferences are not fighting them — they have already lost.

One nuance for anyone on a company account: OpenAI’s documentation notes that in Enterprise and Edu workspaces, chats inside a project use the project instructions only, and personal custom instructions do not apply there at all.

Claude: profile, projects and styles

Claude splits personalisation three ways. The account layer lives under Settings, then Profile, where Anthropic calls the saved rules your profile preferences. Project instructions sit inside each project and apply only to chats opened there. Styles are a separate third control that governs how a response is formatted and delivered rather than what it should contain.

Projects are available to everyone, with free accounts capped at five; the paid plans add retrieval over much larger project knowledge bases rather than unlocking the instruction box itself. If you are using Claude Projects to separate client work, the practical rule is to keep your profile genuinely personal — your role, your terminology, how you like to be spoken to — and push everything task-shaped into the project.

Gemini: instructions and Gems

Gemini’s account box is under Settings, then Personal context, as “Your instructions for Gemini”, and it applies to every chat. Gems have their own separate instruction field, which is how most people build a reusable assistant — our guide to building custom Gemini Gems walks through that builder.

Here is the part that catches people out, and it inverts the pattern from the other two tools. Google’s Gemini Apps help states that your personal-context instructions are not available in certain features, including Gems. A Gem does not inherit your account rules. If your Gem sounds nothing like the rest of your Gemini chats, that is why — and the fix is to repeat the relevant rules inside the Gem itself.

Two more constraints are worth knowing before you build a team workflow on any of this:

• Personal-context instructions require a personal Google Account — they are not available on work, school or supervised accounts
• Gemini inside Workspace apps like Docs and Gmail keeps a separate set of instructions that does not sync with the Gemini app

Why Your Rules Get Dropped

Instructions fail for three reasons, and only one of them is about writing. A rule fades because the conversation grew, backfires because it was phrased as a prohibition, or gets quietly outvoted because it contradicts something on another layer.

Context rot in long chats

Your saved instruction does not get deleted mid-chat. It gets crowded. As a conversation accumulates messages, pasted documents and earlier answers, the instruction competes for attention against far more text than it did at message one. Chroma Research documented this pattern in its 2025 study on context rot, testing 18 frontier models and finding that output quality degrades as input length grows — well before the context window is anywhere near full.

The practical fix is unglamorous: start a fresh chat more often than feels necessary. If you cannot, restate the one constraint that matters in your next message rather than scrolling up to point at the original. This is also the mechanism behind a lot of what looks like randomness, which we unpack in why AI output varies between sessions.

Negative rules that backfire

Telling a model what not to do gives it a description of the forbidden thing and no description of the wanted thing. “Do not write a chatty introduction” leaves the entire question of how to open completely unspecified, so the model falls back on its defaults — which is exactly the chatty introduction you banned.

Prohibitions still have their place — a banned-word list is genuinely useful. They just work far better as a supporting clause underneath a positive structure than as the whole instruction. There is more on this in our guide to specifying format so output arrives usable.

Rules that quietly contradict

The third failure is the one nobody sees coming. Your account box says “keep everything brief and skimmable”. Your project instructions say “write full analytical paragraphs with worked reasoning”. Neither is wrong. Together they ask for opposite things, and the model resolves the conflict by picking somewhere in the middle that satisfies neither.

Nothing warns you. There is no conflict indicator in any of these tools, which is why the placement discipline in the next two sections matters more than the wording.

Writing Instructions That Actually Stick

The reliable pattern is to keep each layer doing one job: your account box describes you, your workspace box describes the work, and your prompt describes today’s task. Set up in that order and the layers stop competing.

This is the layer that follows you into every unrelated chat, so keep it identity-shaped rather than task-shaped. Your role, your audience, your terminology, how blunt you want the answers. Anything that is only true when you are doing one specific kind of work does not belong here.

Who I am: [job title] at a [industry] company, working mainly with [audience, e.g. non-technical department heads].

How I want responses:
- Lead with the answer or recommendation, then the reasoning.
- Default to continuous prose. Use a list only when I am asking for steps or options.
- Flag it explicitly when you are uncertain rather than smoothing over it.
- Use British spelling and write numbers under ten as words.

Terms I use: [term] means [definition]. [term] means [definition].

Anything that is true for one client, one report or one recurring deliverable goes into the project or Gem. This is what stops rules from client A leaking into work for client B, and it is the single highest-value change most people make.

Context: every chat in this space relates to [client or workstream].

Standing rules for this work:
1. Use the structure: Situation, Options, Recommendation, Next step.
2. Keep each section under 120 words.
3. Refer to the organisation as [exact preferred name], never an abbreviation.
4. Where a figure is needed and I have not supplied it, write [FIGURE NEEDED] rather than estimating.
5. Cite which uploaded document a claim came from, in brackets, after the claim.

If a request conflicts with these rules, follow the request and tell me which rule you set aside.

That final line is worth stealing. It does not prevent conflicts, but it converts a silent override into a visible one.

Sometimes your standing rules are simply wrong for today’s job — your account box enforces brevity and you need a formal four-paragraph response to a regulator. You do not need to edit your settings and remember to change them back.

For this response only, set aside my saved preference for brevity.

Task: draft a formal reply to the enquiry pasted below.
Tone: formal, precise, no contractions.
Length: four full paragraphs.
Structure: acknowledge the enquiry, state the facts, state what we are doing, give a date for the next update.

Enquiry:
[paste]

If you want a sharper frame for writing the instruction text itself, the four elements in our Role, Goal, Context, Format system apply to instruction boxes exactly as they do to prompts.

Choosing the Right Layer

Here is the whole decision, compressed into one question. The Always-True Test: before writing any instruction, ask what it is always true for — every chat you will ever have, every chat in one body of work, or only this one — and put it on that layer. It is the placement discipline we teach at PromptPeakAI, and it takes about four seconds per rule.

Most bad instruction sets fail this test in the same direction: a rule that is only true for one client ends up in the account box, where it colours everything else you do.

Run the test across what you already have. Most people find two or three rules sitting a layer too high.

Below are my current saved AI instructions. For each individual rule, tell me:

1. Is it true for every chat I will ever have, only for one client or recurring job, or only for a single task?
2. Which of those three layers should it live on?
3. Does it contradict any other rule in this list?

Return a table with columns: Rule, Correct layer, Conflicts with.

My current instructions:
[paste]

What Instructions Cannot Do

Saved instructions are genuinely powerful, and they are oversold everywhere. Four limits are worth knowing before you build a team process on top of them.

That last point matters more than it sounds, because the instruction box is exactly where people paste the things they most want the AI to know — client names, internal processes, pricing logic. Treat it as content you have published to your tool provider, not as a private note.

The distinction between saved rules and stored memory trips up a lot of people; our explainer on what ChatGPT memory keeps about you covers the other half of that picture.

When Instructions Go Wrong

Almost every instruction failure maps to one of five causes, and each has a specific fix rather than a general “try rewording it”.

Work down that list before rewriting anything. In practice the second and third rows account for most of the frustration, and neither is a writing problem.

The honest answer to system prompt vs custom instructions is that neither one simply wins: the platform layer is absolute, the workspace layer beats your account settings inside its own space, and your typed prompt steers the answer in front of you without disturbing either. Give yourself twenty minutes to set those layers up properly once, and the question that started this stops being a mystery you re-solve every week.