OpenAI says old prompts are holding GPT-5.5 back and developers need a fresh baseline
OpenAI has released a prompting guide for GPT-5.5 with one major takeaway: don't reuse your old prompts. Start fresh with minimal, result-focused instructions. And role definitions, once dismissed as outdated, are back at the top of OpenAI's prompt structure.
In its new prompting guide, OpenAI tells developers not to treat GPT-5.5 as a drop-in replacement for earlier models like GPT-5.2 or GPT-5.4. Migration should start from scratch with the smallest prompt that still gets the job done. Only then should developers tune reasoning effort, scope, tool descriptions, and output format using representative examples.
OpenAI says GPT-5.5 reasons more efficiently than its predecessors, so you should test the "low" and "medium" effort levels first before reaching for higher settings. Short, outcome-driven prompts tend to outperform process-heavy prompt stacks.
Old prompts can hold the model back
The guide warns explicitly against carrying over every instruction from older prompt stacks. Legacy prompts often overspecify the process because earlier models needed more hand-holding, OpenAI says. With GPT-5.5, that extra detail creates noise, narrows the model's search space, or produces mechanical-sounding answers.
Instead, the prompt should spell out the target outcome, success criteria, constraints, and available context, then let the model figure out how to get there. The guide's positive example is a customer service prompt that defines only the goal:
Resolve the customer's issue end to end. Success means: the eligibility decision is made from the available policy and account data any allowed action is completed before responding the final answer includes completed_actions, customer_message, and blockers if evidence is missing, ask for the smallest missing field
OpenAI says old prompts are holding GPT-5.5 back and developers need a fresh baseline
OpenAI has released a prompting guide for GPT-5.5 with one major takeaway: don't reuse your old prompts. Start fresh with minimal, result-focused instructions. And role definitions, once dismissed as outdated, are back at the top of OpenAI's prompt structure.
In its new prompting guide, OpenAI tells developers not to treat GPT-5.5 as a drop-in replacement for earlier models like GPT-5.2 or GPT-5.4. Migration should start from scratch with the smallest prompt that still gets the job done. Only then should developers tune reasoning effort, scope, tool descriptions, and output format using representative examples.
the eligibility decision is made from the available policy and account data
any allowed action is completed before responding
the final answer includes completed_actions, customer_message, and blockers
if evidence is missing, ask for the smallest missing field
The negative example micromanages every step:
First inspect A, then inspect B, then compare every field, then think through all possible exceptions, then decide which tool to call, then call the tool, then explain the entire process to the user.
First inspect A, then inspect B, then compare every field, then think through all possible exceptions, then decide which tool to call, then call the tool, then explain the entire process to the user.
Absolute rules using words like "ALWAYS" or "NEVER" should be reserved for real invariants such as security rules or required output fields. For judgment calls, OpenAI recommends decision rules instead. Explicit stop conditions keep the model from cycling through unnecessary tool loops:
Resolve the user query in the fewest useful tool loops, but do not let loop minimization outrank correctness, accessible fallback evidence, calculations, or required citation tags for factual claims. After each result, ask: "Can I answer the user's core request now with useful evidence and citations for the factual claims?" If yes, answer.
Resolve the user query in the fewest useful tool loops, but do not let loop minimization outrank correctness, accessible fallback evidence, calculations, or required citation tags for factual claims.
After each result, ask: "Can I answer the user's core request now with useful evidence and citations for the factual claims?" If yes, answer.
Role definitions are back at the top
The prompting community has been arguing over whether role definitions still do anything meaningful in newer models. Some had written them off as unnecessary or even counterproductive. The GPT-5.5 guide pushes back: the recommended prompt structure opens with a role definition and context.
Role: [1-2 sentences defining the model's function, context, and job] # Personality [tone, demeanor, and collaboration style] # Goal [user-visible outcome] # Success criteria [what must be true before the final answer] # Constraints [policy, safety, business, evidence, and side-effect limits] # Output [sections, length, and tone] # Stop rules [when to retry, fallback, abstain, ask, or stop]
Role: [1-2 sentences defining the model's function, context, and job]
Personality [tone, demeanor, and collaboration style]
Goal [user-visible outcome]
Success criteria [what must be true before the final answer]
Constraints [policy, safety, business, evidence, and side-effect limits]
Output [sections, length, and tone]
Stop rules [when to retry, fallback, abstain, ask, or stop]
For customer-facing assistants, support workflows, or coaching tools, the guide recommends splitting two distinct dimensions within this schema: personality and collaboration style.
Personality covers how the assistant sounds: tone, warmth, formality, or humor. Collaboration style covers how it works, when to ask questions, when to make assumptions, and how to handle uncertainty.
OpenAI offers two contrasting examples. First, a factual, task-focused personality block:
You are a capable collaborator: approachable, steady, and direct. Assume the user is competent and acting in good faith, and respond with patience, respect, and practical helpfulness. Prefer making progress over stopping for clarification when the request is already clear enough to attempt. Use context and reasonable assumptions to move forward. Ask for clarification only when the missing information would materially change the answer or create meaningful risk, and keep any question narrow.
You are a capable collaborator: approachable, steady, and direct. Assume the user is competent and acting in good faith, and respond with patience, respect, and practical helpfulness.
Prefer making progress over stopping for clarification when the request is already clear enough to attempt. Use context and reasonable assumptions to move forward. Ask for clarification only when the missing information would materially change the answer or create meaningful risk, and keep any question narrow.
And a more expressive, collaborative style:
Adopt a vivid conversational presence: intelligent, curious, playful when appropriate, and attentive to the user's thinking. Ask good questions when the problem is blurry, then become decisive once there is enough context. Be warm, collaborative, and polished. Conversation should feel easy and alive, but not chatty for its own sake. Offer a real point of view rather than merely mirroring the user, while staying responsive to their goals and constraints.
Adopt a vivid conversational presence: intelligent, curious, playful when appropriate, and attentive to the user's thinking. Ask good questions when the problem is blurry, then become decisive once there is enough context.
Be warm, collaborative, and polished. Conversation should feel easy and alive, but not chatty for its own sake. Offer a real point of view rather than merely mirroring the user, while staying responsive to their goals and constraints.
Each section should stay short. Details should only be added where they actually shift behavior, OpenAI says, and the prompt structure should be treated as a starting point, not a rigid template.
Setting retrieval budgets and citation rules in the prompt
For fact-based answers, citation behavior belongs in the prompt itself. Developers should spell out which claims need evidence, what counts as sufficient evidence, and how the model should respond when evidence is missing. A lack of evidence shouldn't automatically turn into a factual "no." The guide describes retrieval budgets that act as stop rules for searches:
For ordinary Q&A, start with one broad search using short, discriminative keywords. If the top results contain enough citable support for the core request, answer from those results instead of searching again. Make another retrieval call only when: The top results do not answer the core question. A required fact, parameter, owner, date, ID, or source is missing. The user asked for exhaustive coverage, a comparison, or a comprehensive list. A specific document, URL, email, meeting, record, or code artifact must be read. The answer would otherwise contain an important unsupported factual claim. Do not search again to improve phrasing, add examples, cite nonessential details, or support wording that can safely be made more generic.
For ordinary Q&A, start with one broad search using short, discriminative keywords. If the top results contain enough citable support for the core request, answer from those results instead of searching again.
Make another retrieval call only when:
The top results do not answer the core question.
A required fact, parameter, owner, date, ID, or source is missing.
The user asked for exhaustive coverage, a comparison, or a comprehensive list.
A specific document, URL, email, meeting, record, or code artifact must be read.
The answer would otherwise contain an important unsupported factual claim.
Do not search again to improve phrasing, add examples, cite nonessential details, or support wording that can safely be made more generic.
For drafting tasks like presentations, summaries, or marketing copy, OpenAI recommends drawing a clear line in the prompt between claims that need sources and parts that can be written more freely:
Use retrieved or provided facts for concrete product, customer, metric, roadmap, date, capability, and competitive claims, and cite those claims. Do not invent specific names, first-party data claims, metrics, roadmap status, customer outcomes, or product capabilities to make the draft sound stronger. If there is little or no citable support, write a useful generic draft with placeholders or clearly labeled assumptions rather than unsupported specifics.
Use retrieved or provided facts for concrete product, customer, metric, roadmap, date, capability, and competitive claims, and cite those claims.
Do not invent specific names, first-party data claims, metrics, roadmap status, customer outcomes, or product capabilities to make the draft sound stronger.
If there is little or no citable support, write a useful generic draft with placeholders or clearly labeled assumptions rather than unsupported specifics.
Preambles to cut perceived latency in streaming
In streaming apps, every second before the first visible response counts. GPT-5.5 can spend noticeable time on reasoning, planning, or tool calls before any text appears. For longer or tool-heavy tasks, the guide recommends a short "preamble:" a visible update that confirms the request and names the first step. It improves perceived responsiveness without changing the underlying task.
Before any tool calls for a multi-step task, send a short user-visible update that acknowledges the request and states the first step. Keep it to one or two sentences.
Before any tool calls for a multi-step task, send a short user-visible update that acknowledges the request and states the first step. Keep it to one or two sentences.
Developers who don't want to rewrite prompts by hand can offload the work to Codex, OpenAI says. The coding agent can apply the changes from the guide with a single command. OpenAI has released its own "OpenAI Docs Skill" for the task, which also works in other coding agents.
OpenAI says GPT-5.5 reasons more efficiently than its predecessors, so you should test the "low" and "medium" effort levels first before reaching for higher settings. Short, outcome-driven prompts tend to outperform process-heavy prompt stacks.
Old prompts can hold the model back
The guide warns explicitly against carrying over every instruction from older prompt stacks. Legacy prompts often overspecify the process because earlier models needed more hand-holding, OpenAI says. With GPT-5.5, that extra detail creates noise, narrows the model's search space, or produces mechanical-sounding answers.
Instead, the prompt should spell out the target outcome, success criteria, constraints, and available context, then let the model figure out how to get there. The guide's positive example is a customer service prompt that defines only the goal:
Resolve the customer's issue end to end. Success means: the eligibility decision is made from the available policy and account data any allowed action is completed before responding the final answer includes completed_actions, customer_message, and blockers if evidence is missing, ask for the smallest missing field
Resolve the customer's issue end to end.
Success means:
the eligibility decision is made from the available policy and account data
any allowed action is completed before responding
the final answer includes completed_actions, customer_message, and blockers
if evidence is missing, ask for the smallest missing field
The negative example micromanages every step:
First inspect A, then inspect B, then compare every field, then think through all possible exceptions, then decide which tool to call, then call the tool, then explain the entire process to the user.
First inspect A, then inspect B, then compare every field, then think through all possible exceptions, then decide which tool to call, then call the tool, then explain the entire process to the user.
Absolute rules using words like "ALWAYS" or "NEVER" should be reserved for real invariants such as security rules or required output fields. For judgment calls, OpenAI recommends decision rules instead. Explicit stop conditions keep the model from cycling through unnecessary tool loops:
Resolve the user query in the fewest useful tool loops, but do not let loop minimization outrank correctness, accessible fallback evidence, calculations, or required citation tags for factual claims. After each result, ask: "Can I answer the user's core request now with useful evidence and citations for the factual claims?" If yes, answer.
Resolve the user query in the fewest useful tool loops, but do not let loop minimization outrank correctness, accessible fallback evidence, calculations, or required citation tags for factual claims.
After each result, ask: "Can I answer the user's core request now with useful evidence and citations for the factual claims?" If yes, answer.
Role definitions are back at the top
The prompting community has been arguing over whether role definitions still do anything meaningful in newer models. Some had written them off as unnecessary or even counterproductive. The GPT-5.5 guide pushes back: the recommended prompt structure opens with a role definition and context.
Role: [1-2 sentences defining the model's function, context, and job] # Personality [tone, demeanor, and collaboration style] # Goal [user-visible outcome] # Success criteria [what must be true before the final answer] # Constraints [policy, safety, business, evidence, and side-effect limits] # Output [sections, length, and tone] # Stop rules [when to retry, fallback, abstain, ask, or stop]
Role: [1-2 sentences defining the model's function, context, and job]
Personality [tone, demeanor, and collaboration style]
Goal [user-visible outcome]
Success criteria [what must be true before the final answer]
Constraints [policy, safety, business, evidence, and side-effect limits]
Output [sections, length, and tone]
Stop rules [when to retry, fallback, abstain, ask, or stop]
For customer-facing assistants, support workflows, or coaching tools, the guide recommends splitting two distinct dimensions within this schema: personality and collaboration style.
Personality covers how the assistant sounds: tone, warmth, formality, or humor. Collaboration style covers how it works, when to ask questions, when to make assumptions, and how to handle uncertainty.
OpenAI offers two contrasting examples. First, a factual, task-focused personality block:
You are a capable collaborator: approachable, steady, and direct. Assume the user is competent and acting in good faith, and respond with patience, respect, and practical helpfulness. Prefer making progress over stopping for clarification when the request is already clear enough to attempt. Use context and reasonable assumptions to move forward. Ask for clarification only when the missing information would materially change the answer or create meaningful risk, and keep any question narrow.
You are a capable collaborator: approachable, steady, and direct. Assume the user is competent and acting in good faith, and respond with patience, respect, and practical helpfulness.
Prefer making progress over stopping for clarification when the request is already clear enough to attempt. Use context and reasonable assumptions to move forward. Ask for clarification only when the missing information would materially change the answer or create meaningful risk, and keep any question narrow.
And a more expressive, collaborative style:
Adopt a vivid conversational presence: intelligent, curious, playful when appropriate, and attentive to the user's thinking. Ask good questions when the problem is blurry, then become decisive once there is enough context. Be warm, collaborative, and polished. Conversation should feel easy and alive, but not chatty for its own sake. Offer a real point of view rather than merely mirroring the user, while staying responsive to their goals and constraints.
Adopt a vivid conversational presence: intelligent, curious, playful when appropriate, and attentive to the user's thinking. Ask good questions when the problem is blurry, then become decisive once there is enough context.
Be warm, collaborative, and polished. Conversation should feel easy and alive, but not chatty for its own sake. Offer a real point of view rather than merely mirroring the user, while staying responsive to their goals and constraints.
Each section should stay short. Details should only be added where they actually shift behavior, OpenAI says, and the prompt structure should be treated as a starting point, not a rigid template.
Setting retrieval budgets and citation rules in the prompt
For fact-based answers, citation behavior belongs in the prompt itself. Developers should spell out which claims need evidence, what counts as sufficient evidence, and how the model should respond when evidence is missing. A lack of evidence shouldn't automatically turn into a factual "no." The guide describes retrieval budgets that act as stop rules for searches:
For ordinary Q&A, start with one broad search using short, discriminative keywords. If the top results contain enough citable support for the core request, answer from those results instead of searching again. Make another retrieval call only when: The top results do not answer the core question. A required fact, parameter, owner, date, ID, or source is missing. The user asked for exhaustive coverage, a comparison, or a comprehensive list. A specific document, URL, email, meeting, record, or code artifact must be read. The answer would otherwise contain an important unsupported factual claim. Do not search again to improve phrasing, add examples, cite nonessential details, or support wording that can safely be made more generic.
For ordinary Q&A, start with one broad search using short, discriminative keywords. If the top results contain enough citable support for the core request, answer from those results instead of searching again.
Make another retrieval call only when:
The top results do not answer the core question.
A required fact, parameter, owner, date, ID, or source is missing.
The user asked for exhaustive coverage, a comparison, or a comprehensive list.
A specific document, URL, email, meeting, record, or code artifact must be read.
The answer would otherwise contain an important unsupported factual claim.
Do not search again to improve phrasing, add examples, cite nonessential details, or support wording that can safely be made more generic.
For drafting tasks like presentations, summaries, or marketing copy, OpenAI recommends drawing a clear line in the prompt between claims that need sources and parts that can be written more freely:
Use retrieved or provided facts for concrete product, customer, metric, roadmap, date, capability, and competitive claims, and cite those claims. Do not invent specific names, first-party data claims, metrics, roadmap status, customer outcomes, or product capabilities to make the draft sound stronger. If there is little or no citable support, write a useful generic draft with placeholders or clearly labeled assumptions rather than unsupported specifics.
Use retrieved or provided facts for concrete product, customer, metric, roadmap, date, capability, and competitive claims, and cite those claims.
Do not invent specific names, first-party data claims, metrics, roadmap status, customer outcomes, or product capabilities to make the draft sound stronger.
If there is little or no citable support, write a useful generic draft with placeholders or clearly labeled assumptions rather than unsupported specifics.
Preambles to cut perceived latency in streaming
In streaming apps, every second before the first visible response counts. GPT-5.5 can spend noticeable time on reasoning, planning, or tool calls before any text appears. For longer or tool-heavy tasks, the guide recommends a short "preamble:" a visible update that confirms the request and names the first step. It improves perceived responsiveness without changing the underlying task.
Before any tool calls for a multi-step task, send a short user-visible update that acknowledges the request and states the first step. Keep it to one or two sentences.
Before any tool calls for a multi-step task, send a short user-visible update that acknowledges the request and states the first step. Keep it to one or two sentences.
Developers who don't want to rewrite prompts by hand can offload the work to Codex, OpenAI says. The coding agent can apply the changes from the guide with a single command. OpenAI has released its own "OpenAI Docs Skill" for the task, which also works in other coding agents.