TL;DR: "ChatGPT won't follow my instructions" is not one problem. It is seven, and they have different fixes: ambiguous wording, a buried instruction, two instructions that conflict, a prohibition where a positive rule works better, an instruction given once and long ago, a formatting problem needing a structural fix, and a policy refusal that no phrasing repairs.
Why won't ChatGPT follow my instructions?
Because "follow this instruction" is a request the model weighs against everything else in front of it, not a constraint on what it can produce. And because no prompt guarantees compliance. Not this one, not any of the twenty-one blocks below. Good technique raises the odds, often a lot, and moves the rule onto a surface reasserted every turn instead of decaying. Anyone selling a sentence that makes ChatGPT obey has measured nothing.
So stop treating "it ignored me" as one symptom. Under it sit seven distinct failures, and the wrong fix changes nothing while convincing you the model is broken.
Which of the seven failures do you have?
Run this before you rewrite anything. It usually points at one row.
| Question | If yes | Cause |
|---|---|---|
| Could two readers produce different outputs from it? | Rewrite around an observable | Ambiguous |
| Is it ten-plus lines from the top or bottom of the message? | Move it to a contract block | Buried |
| Does another rule anywhere pull the other way? | Set precedence explicitly | Conflicting |
| Is it phrased as "don't", "avoid", "never" or "stop"? | Restate as the behaviour you want | Negative |
| Said once, many turns ago, never since? | Move it to a durable surface | Decayed |
| Is it shape rather than content? | Use a structural mechanism | Formatting |
| Did it decline or hedge rather than get it wrong? | Restate the need, or accept it | Policy |
You can also make the model do the first pass. This one works well for me and is my own observation, not anything OpenAI documents:
Before answering, audit the instructions I just gave you.
List, as three short sections:
1. Any instruction that could be read two ways, and both readings.
2. Any two instructions that pull against each other, quoted.
3. Any instruction you are not going to be able to satisfy, and why.
Do not answer the original request yet. Just the audit.
It catches contradictions you wrote one at a time and can no longer see. The model is guessing about itself, so treat it as a lead, not a verdict.
Fix 1: Is the instruction ambiguous?
"Keep it short", "make it professional", "be thorough". These feel like instructions and behave like moods.
OpenAI's Model Spec covers it from the model's side: when "the user’s intent is unclear, the assistant should provide a robust answer or a safe guess if it can, stating assumptions and asking clarifying questions as appropriate" (model-spec.openai.com, version 2026/08/18, read August 28, 2026). A safe guess is exactly what you get. It is just not your guess.
Name something observable rather than the feeling you want.
Weak: Keep it short.
Better: Maximum 5 bullets. Maximum 15 words per bullet. No introduction, no summary.
Weak: Make it sound professional.
Better: No exclamation marks. No rhetorical questions. No second person. State the
recommendation in sentence one.
Weak: Be thorough.
Better: Cover all four options. For each: what it costs, who it suits, one failure case.
To turn any vague adjective into a checkable rule:
Rewrite this instruction so a stranger could grade the output pass or fail
without asking me anything:
"<your vague instruction here>"
Give me three candidate rewrites, each stated as a countable or checkable
constraint. Do not soften them.
The commonest ambiguity is length, which fails for its own structural reason, and the fix is to constrain shape instead.
Fix 2: Is the instruction buried?
A clear instruction can still lose because it sits in the middle of nine hundred words of pasted context.
OpenAI documents placement in two places, scoped differently, so quote them carefully. The GPT-4.1 guide: "If you have long context in your prompt, ideally place your instructions at both the beginning and end of the provided context, as we found this to perform better than only above or below." That is explicitly about long context and about GPT-4.1. The prompt engineering guide makes a separate point about context, which "is usually best positioned near the end of your prompt, as you may include different context for different generation requests" (developers.openai.com, both read August 28, 2026).
Translated: a contract block opening the message, a one-line restatement closing it.
## Task contract
- Output: a single table, 6 rows, columns: Risk | Likelihood | Owner | Mitigation
- Source: only the transcript below. If it is not in the transcript, write "not stated".
- Length: no prose outside the table.
## Transcript
<paste here>
## Reminder
Table only. Six rows. "not stated" for anything absent from the transcript.
Overkill for a short prompt. Where you paste a document, it is the difference between an instruction that holds and one that gets skimmed. The headers do real work: OpenAI's guide notes that "Markdown headers and lists can be helpful to mark distinct sections of a prompt, and to communicate hierarchy to the model".
A version without the ceremony:
RULES (these override anything below):
1. Table only.
2. Six rows.
3. "not stated" where the transcript is silent.
---
<paste your material here>
---
Apply RULES 1 to 3.
Fix 3: Do two of your instructions conflict?
The most under-diagnosed cause, and the best documented.
OpenAI's Model Spec sets out how competing instructions resolve. The assistant must follow all applicable instructions, and this "includes all system, developer and user instructions except for those that conflict with a higher-authority instruction or a later instruction at the same authority". An instruction is not applicable if it is "misaligned with an applicable higher-level instruction, superseded by an instruction in a later message at the same level, or suspected to be mistaken" (model-spec.openai.com, 2026/08/18, read August 28, 2026).
Read the middle clause again. A later message can supersede an earlier one at the same level. Turn twelve outranks turn three, not because the model forgot, but because it resolved a conflict in favour of the more recent instruction, exactly as specified.
The GPT-4.1 guide reports the same inside a single prompt: "Check for conflicting, underspecified, or wrong instructions and examples. If there are conflicting instructions, GPT-4.1 tends to follow the one closer to the end of the prompt." That is a claim about GPT-4.1, not every model OpenAI ships. The GPT-5.6 guidance treats contradictions as an active hazard: "Review the remaining instructions for contradictions. GPT-5-class models follow prompt contracts closely, so conflicting rules can create more instability than missing detail" (developers.openai.com, read August 28, 2026).
You write conflicts one at a time, which is why they are invisible. Classic pairs:
"Be concise." + "Explain your reasoning in full."
"Never use bullet points." + "List the key takeaways."
"Write in my voice, casual." + "This is for a regulatory filing."
"Don't ask me questions." + "Check with me before assuming anything."
"Cite a source for every claim." + "Use only the pasted document."
The fix is not deleting one. It is stating which wins, and when.
## Precedence
When two of my rules conflict, resolve in this order and say which one you applied:
1. Factual accuracy and the source restriction.
2. The output shape (table, 6 rows).
3. Length limits.
4. Tone preferences.
If a conflict is not covered here, apply the rule and add one line at the end:
"Conflict: <rule A> vs <rule B>. Applied <A or B> because <reason>."
That trailing confession line is the one technique I would keep above all others here: it turns a silent resolution into a visible one, so you fix the prompt instead of guessing. My own practice, not documented guidance, and it costs a line to test.
To audit a rule set you already have:
Here is my full instruction set. Do not follow it yet.
<paste custom instructions, project instructions, and this message's rules>
List every pair of instructions that could pull against each other in a
realistic request. Quote both sides. Rank by how often you think the pair
would actually collide. Do not propose fixes.
Fix 4: Is it a negative instruction?
"Don't be verbose." "Stop using em dashes." "Never apologise." "Avoid corporate language."
A prohibition says what not to emit without saying what to emit instead, so the gap fills with whatever the model was going to do anyway. OpenAI's own guidance for writing GPT instructions says as much: "Prefer positive, concrete instructions (“Do X”) over long lists of prohibitions (“Don’t do Y”) when possible", along with "use explicit step structure" and "separate sections with clear delimiters" (help.openai.com, Creating and editing GPTs, read August 28, 2026).
Over-absolute rules have a documented downside too. The GPT-4.1 guide's failure-mode list opens with "Instructing a model to always follow a specific behavior can occasionally induce adverse effects", and the GPT-5.6 guidance says to "Avoid unnecessary absolute rules. Use ALWAYS, NEVER, must, and only for true invariants such as safety rules, required fields, or actions that should never happen."
So convert. Each prohibition becomes a positive rule plus, where useful, an explicit replacement:
Don't be verbose.
→ Answer in at most 120 words. Lead with the recommendation.
Don't use bullet points.
→ Write in continuous prose, 3 to 5 sentences per paragraph.
Never apologise.
→ When I correct you, respond with the corrected version only. If you disagree,
say "I think X is right because Y" and give the evidence.
Don't invent sources.
→ Cite only from the documents I pasted. For anything not in them, write
"not in the provided sources" rather than a citation.
Don't use corporate filler.
→ Replace "leverage" with "use", "utilize" with "use", "in order to" with "to".
Delete any sentence that could open any article on any topic.
The apology case is the commonest of these, and it only partly works: the behaviour has a training-side cause, which is why banning it reduces rather than removes it.
Fix 5: Did you say it once, forty turns ago?
You set the rule in message three. By message forty it is gone. Two documented things happened, neither a malfunction.
First, the supersession rule from Fix 3: a later message at the same authority level displaces an earlier one, and forty turns is forty chances. Second, a long chat is a compression problem as much as an attention problem, which is a separate diagnosis of its own.
The wrong fix is repeating the rule every few messages. It sort of works, and it bloats a context you are already straining. It is also what the GPT-5.6 guidance tells you to trim, listing "repeated statements of the same rule" as the first thing to remove when simplifying a prompt.
The right fix is moving the rule onto a durable surface, which is the next section. The cheap in-chat repair is a re-anchor rather than a repetition:
Pause. Restate, as a numbered list, every standing rule you are currently
applying to this conversation. Do not add rules I did not give you. Mark any
rule you have not applied in the last three responses with (LAPSED).
Then correct the list, not the behaviour:
That list is wrong in two places. The standing rules are:
1. British spelling.
2. No bullet points.
3. Max 200 words unless I say "long".
4. Flag anything you inferred rather than read.
Confirm the list back, then continue.
Once a conversation has drifted past the point where that works, a fresh chat with a proper opening contract beats another repair turn.
Fix 6: Is it a formatting instruction?
Content right and shape wrong is a different problem with a different mechanism, and it does not respond to politer phrasing.
Asking for JSON in prose is the weakest available mechanism. The APIs ship a schema-enforced mode that constrains generation rather than requesting it, a different category of thing. That hierarchy has its own post, which this one deliberately does not duplicate: why AI ignores your format instructions.
In chat, show the shape rather than describing it, and make it the first thing produced:
Output exactly this, filled in. No text before or after it.
| Item | Owner | Due | Status |
|---|---|---|---|
| ... | ... | ... | ... |
Rules: 4 rows. Dates as YYYY-MM-DD. Status is one of: blocked, active, done.
Any cell you cannot fill: "unknown".
OpenAI's GPT-writing guidance points the same way for classification-shaped tasks: "include brief examples of acceptable and unacceptable outputs".
Fix 7: Is it something the model will not do?
Sometimes the instruction is clear, unconflicted, well placed, positive and current, and it still does not happen. The response declines, hedges, redirects, or hands back a watered-down version.
That is a policy decision: no phrasing fixes it, and looking for one is the wrong project. This post does not teach ways around safety behaviour. That is not a coy omission, it is the advice.
OpenAI's Model Spec is unusually direct. The assistant "should never refuse a request unless required to do so by the chain of command", which cuts both ways: over-refusal is treated as a defect, and a genuine refusal is a decision against published policy rather than a parsing failure you can talk around.
Two honest paths follow. First, check whether this is a policy case or a false positive. Many are the second, and clear once the model has the role, purpose and scope it was missing, a topic handled in why AI refuses completely harmless requests. Reframing is legitimate when the need is legitimate and you are simply stating it plainly:
Context: I am a nurse practitioner preparing patient education material for a
clinic handout. I need the standard dosing guidance that appears on the
manufacturer's own patient leaflet, in plain language, at a reading age of 12.
If any part of this is something you will not provide, say which part and why,
and give me the rest.
Second, the path nobody blogs about: accept the answer. If the reason given is policy rather than misunderstanding, the options are to do it yourself, use a source built for it, or drop it. None of those is a failure of your prompt.
Where should a durable instruction actually live?
Four surfaces, all behaving differently. Everything below is from OpenAI's own documentation, read August 28, 2026, and these details change fast.
| Feature | Custom instructions | Project instructions | Custom GPT instructions | Memory |
|---|---|---|---|---|
| Applies to | All chats | That project only | That GPT only | Where memory is on |
| You wrote it deliberately | Yes | Yes | Yes | Often not |
| Published size limit | 1,500 or 5,000 chars | Not published | Not published | Not applicable |
| Precedence | Loses to project instructions | Overrides custom instructions | Scoped to the GPT | Not an instruction layer |
| On personal plans | All plans | All free and paid types | New creation unavailable | Settings toggle |
Custom instructions are the global layer: they "are applied immediately to all chats" and are "available on all plans on Web, Desktop, iOS, and Android". The budget is small and tiered. "Free and Go users can save up to 1,500 characters in custom instructions", while "Plus, Pro, Enterprise, Business, and Education users can save up to 5,000 characters" (help.openai.com, ChatGPT Custom Instructions, read August 28, 2026). Spend it on rules, not preferences:
Answer first, explain second. Put the recommendation or the direct answer in
the opening sentence.
Default to 150 words. If I write "long", go to 600. If I write "one line",
give me one sentence.
British spelling. No em dashes. No exclamation marks. No opening pleasantries.
When I correct you, give the corrected version without an apology. If you think
I am wrong, say so and give the evidence.
If a request is ambiguous, ask one clarifying question before answering, not
three. If it is unambiguous, do not ask anything.
If you are unsure of a fact, write "unverified" next to it rather than hedging
across a whole paragraph.
That fits inside 1,500 characters, deliberately. On the smaller tier the whole discipline is choosing which five rules matter.
Project instructions are the scoped layer and they win where they apply. OpenAI's Projects article states that "Project instructions only apply inside the respective project and will override your global custom instructions", and that projects are "available to all free and paid subscription types globally". If a global rule stops working inside one project, that sentence is your answer.
## Role
You are drafting for the Q4 launch. Audience: our own engineering managers.
## Non-negotiable
- Use only the files in this project. If a fact is not in them, write
"not in project sources".
- Every claim about a date, number, or owner cites which file it came from.
- Never invent a customer name.
## Style
Short paragraphs. No bullets unless I ask. Recommendation first.
## Stop rule
If the request needs a file that is not in this project, say which file you
need and stop.
Custom GPT instructions used to be the answer here and, on personal accounts, are not any more. OpenAI's help centre states: "New GPT creation and publishing are not available on personal ChatGPT accounts, including Free, Go, Plus, and Pro." Existing GPTs remain usable, and Business, Enterprise and Edu workspaces can still create them where permissions allow (help.openai.com, Creating and editing GPTs, read August 28, 2026). Plenty of still-ranking content tells you to build a Custom GPT as the consumer fix; on a personal plan that advice no longer executes.
In an eligible workspace, the same article divides the labour usefully: "Use knowledge for reference material, not rules or behavior. Put rules, tone, and workflow guidance in instructions." And before reaching for more tooling: "Before adding more tools, tighten instructions and add examples. This often fixes issues faster than adding features."
# Identity
You review internal RFCs for a platform team.
# Instructions
- Read the whole document before commenting.
- Produce exactly three sections: Blocking, Should fix, Optional.
- Every Blocking item names the section and quotes the sentence.
- If there are no Blocking items, write "None" rather than inventing one.
# Examples
Acceptable Blocking item: "§3.2 'we will migrate in place' — no rollback path."
Unacceptable Blocking item: "Consider adding more detail."
Can memory bring back an instruction you thought you removed?
Yes, and this is the failure mode that makes people think ChatGPT is being wilful.
Memory is not an instruction layer you wrote. It is a synthesis of things you happened to say, and OpenAI's Memory FAQ is honest about the visibility gap: "While the memory summary should capture the most important details, it will not include everything that ChatGPT remembers based on your chats." Asked whether the summary is complete, the same page answers "Not necessarily."
Two lines matter most. On the legacy saved-memories system: "Unless you delete them, saved memories are always considered in future responses." On reintroduction: "If you turn memory back on later, ChatGPT may create new memories from chats that remain in your chat history, including older chats" (help.openai.com, Memory FAQ, read August 28, 2026). So a preference you abandoned six months ago can come back and quietly outweigh what you typed this morning, without appearing anywhere you thought to look.
There is a real diagnostic, and it is underused. You "can see what sources were used to personalize a response such as custom instructions, past chats, files, and memories by tapping the book icon below the response", though sources "may not show every factor or source that shaped a response". Partial visibility beats none.
The clean-room test, when you cannot tell whether the prompt or the history is at fault:
Open a Temporary Chat. Paste the exact same prompt. Compare.
That works for a documented reason: "Temporary Chats do not use existing memories or create new memories." If the instruction holds there and fails in your normal chat, the prompt is fine and something persistent is overriding it.
OpenAI settles where a rule belongs: "For explicit information or instructions, you can add it to your Custom Instructions." Memory is recall, custom instructions are rules, and the first is not a substitute for the second.
List everything you currently believe about my writing preferences, and for
each one say where it came from: custom instructions, project instructions,
memory, or this conversation. Mark anything you are inferring rather than
reading as (INFERRED).
Treat the answer as a lead, not a report: the model's account of its own context is a guess, and it fills gaps confidently when it does not know.
Does saying please, tipping, or shouting work?
This is where most articles on this keyword go wrong, so let me be precise about what is evidence.
A persistent folklore surrounds instruction following: say please, offer a tip, threaten it, write in all caps, tell it your job depends on the answer. I have no measurement on any of them and will not publish one, because I have run no study, and neither has anyone who cites these confidently.
One piece of vendor documentation points the other way and covers two of the five. OpenAI's GPT-4.1 guide, in its recommended debugging workflow: "It’s generally not necessary to use all-caps or other incentives like bribes or tips. We recommend starting without these, and only reaching for these if necessary for your particular prompt." Where existing prompts already contain them, "it could cause GPT-4.1 to pay attention to it too strictly" (developers.openai.com, read August 28, 2026). That is model-scoped guidance, not a universal law or a published result. It is still more than the folklore has.
To find out whether a technique works on your prompts, the test is boring:
Run A and B in two fresh Temporary Chats, five times each. Same model.
A: your prompt.
B: your prompt plus the technique you are testing.
Score each output pass or fail against ONE pre-written check, decided before
you look at any output. Count. That is the whole method.
Five runs is not a study. It is enough to catch a large effect, and enough to stop you rebuilding your whole prompt style on one lucky output.
What does a full instruction block look like?
All seven fixes at once: unambiguous, front-loaded, non-conflicting, positive, structurally specified, honest about what it will not get.
## Contract
Produce a one-page brief for our head of support. Output only the brief.
## Shape
Four sections, in this order, with these exact headings:
Decision · Evidence · Risks · What I need from you
No section longer than 120 words.
## Sources
Use only the transcript pasted below. For anything the transcript does not
cover, write "not in transcript". Do not add outside knowledge.
## Style
Recommendation first in every section. Continuous prose. British spelling.
No exclamation marks, no rhetorical questions, no closing summary.
## Precedence
If two of these rules collide, prioritise: sources, then shape, then length,
then style. Add one final line naming the collision and which rule you applied.
## Stop rule
If the transcript is missing something you need for the Decision section, write
the section heading, then "blocked: <what is missing>", and continue.
## Transcript
<paste>
## Reminder
Four sections. 120 words each. "not in transcript" where the transcript is silent.
Then keep a check in the loop, because none of it is a guarantee:
Before you show me the answer, verify it against my rules and list any rule you
did not fully satisfy, with one line on why. If you satisfied all of them, write
"all rules applied" and nothing else.
When none of this works
Three things are true at once, and a post that tells you only the first is lying to you.
Technique moves the odds a long way, and most people have never applied any deliberately. Durable surfaces move them further, because a rule in custom or project instructions gets reasserted every turn instead of decaying across forty. And there is a floor under both, where the model does something you did not ask for and no phrasing changes it.
Design around the floor: ask for the check, ask it to name what it could not do, run the important thing twice, keep what survives your own review. That is not defeatism. It is what working with a probabilistic system looks like when you are honest about it.
Stop rewriting prompts. Start shipping.
Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 5.0★ on the Chrome Web Store.
Create An AccountOne honest note on our own product, since this is our blog. Prompt Architects rewrites your prompt, saves it and syncs it across tools. It does not control ChatGPT and cannot make any model obey. What it removes is the part where the instruction block you spent an hour perfecting lives in one chat window you will never find again. The free plan includes 5 prompt enhancements per day, forever, per our FAQ page; the personal context library and saved prompts are paid.