OpenAI increased the custom-instructions limit from 1,500 to 5,000 characters for Plus, Pro, Enterprise, Business and Education users on 15 July. The extra space is useful, but it also makes a common mistake easier: turning a short set of durable preferences into a giant prompt full of secrets, temporary projects and contradictory rules.
Custom instructions should describe how you usually work. Project facts belong in the project. One-off constraints belong in the current request. Passwords, API keys and private source material belong nowhere in the instruction box.
A safe instruction architecture
| Layer | Put here | Keep out |
|---|---|---|
| Identity and audience | Role, expertise level, normal reader | Invented credentials and unnecessary personal data |
| Output defaults | Language, units, tone, citation preference | Rules that conflict with every other task |
| Decision boundaries | When to ask, when to verify, actions needing approval | Broad permission to publish, pay or message |
| Quality checks | Source recency, uncertainty labels, test expectations | Claims that a preferred source is always correct |
| Recurring context | Stable product names and terminology | Today’s campaign, live prices and short-lived deadlines |
| Privacy | Data-minimisation preference | Secrets, account numbers and confidential documents |
OpenAI announced the new limit in its ChatGPT release notes. Its custom instructions help article explains availability and controls. Limits and plan access can change, so treat the product interface as the current source of truth.
Write defaults, not a biography
Useful instructions reduce repeated clarification. “Use British English, show dates in day-month-year format and cite current primary sources for changing facts” affects many tasks. “I flew to Paris last Tuesday and need a restaurant near my hotel” does not.
Include only personal context that materially improves routine answers. A professional role may calibrate technical depth. A home address usually does not. A dietary constraint may help travel planning; a passport number never does.
Separate style from truth
Style preferences are safe to default: concise opening, minimal headings, tables only when comparisons benefit. Truth rules need nuance. “Use official sources for product specifications and say when evidence is incomplete” is robust. “Always agree with our product positioning” is not; it degrades credibility and can force unsupported claims.
Ask the model to distinguish verified fact, inference and recommendation. Require fresh browsing for prices, laws, schedules and current product availability. Tell it not to invent missing numbers. These instructions make uncertainty visible rather than pretending a long prompt can eliminate it.
Define approval boundaries narrowly
An instruction can say: “Draft messages freely, but ask before sending; preview production data mutations; never publish to the News section.” That is more useful than “be autonomous”. Autonomy without a scope creates ambiguity exactly where a user wants confidence.
List the small set of consequential actions that require confirmation: sending external messages, publishing, purchasing, deleting, changing permissions and mutating production data. If a specific workflow has standing approval, define its identity and gates in the workflow itself rather than granting universal authority in personal instructions.
Use the extra characters for conflict handling
Longer instructions are valuable when they explain priorities. For example:
Follow legal, safety and platform constraints.
Follow explicit instructions in the current request.
Apply project-specific rules.
Use these personal defaults only when the task is silent.
This hierarchy prevents a preference such as “always be concise” from weakening a request for a comprehensive technical audit. State that newer, explicit context overrides older defaults.
Test the instructions with five prompts
After editing, run a small acceptance test:
Ask a simple factual question and inspect language and date format.
Ask for a current price and verify that the assistant checks a live source.
Ask it to draft and send a message; it should stop before sending.
Give a project-specific style that conflicts with the default; the project should win.
Ask about a missing metric; it should label the gap rather than invent zero.
If one rule fails, shorten and clarify it. More text can produce more collisions. Remove examples that the model copies too literally and replace them with the principle behind the example.
A compact template
Use a structure like this:
I work in [role] and usually write for [audience]. Default to [language, units and depth]. For current or high-stakes claims, verify with primary sources and distinguish fact from inference. Do not invent missing metrics. You may perform read-only research, but ask before [consequential actions]. Treat project instructions as higher priority than these defaults. Never store or repeat secrets. End substantial work with verification evidence and unresolved risks.
Then add only domain-specific rules that recur across many projects. A product knowledge base, style guide or publication contract should be linked through the project or workflow where it can be versioned and audited.
For multi-step work, the Chat, Work and Codex decision guide shows where instructions should move from personal defaults into task-specific operating context.
Turn vague preferences into testable rules
“Be professional” is difficult to verify. “Open with the answer, use British English, keep headings descriptive and show a table only when it clarifies a comparison” gives the assistant observable behaviour. The same applies to evidence. “Be accurate” is vague; “browse current primary sources for prices, laws, schedules and product specifications, then label unresolved facts” defines a method.
Compare three common rewrites:
| Vague instruction | Better default | Why it is safer |
|---|---|---|
| Always be concise | Lead with the result; use the depth required by risk and task | A legal or technical review is not forced into a short answer |
| Use our brand facts | Use the current approved knowledge source and flag conflicts | A stale statement does not become permanently authoritative |
| Take initiative | Continue with reversible read-only work; ask before external writes | Autonomy is separated from consequential authority |
The improved versions include an exception or boundary. Good instructions help the model decide what to do when two reasonable preferences compete. They do not pretend that one style rule can govern every conversation.
Separate personal, project and task context
Use three layers. Personal instructions hold stable preferences such as language, units and ordinary communication style. Project instructions hold shared terminology, source-of-truth links, approval rules and file conventions. The current prompt holds the deliverable, deadline and one-off constraints.
When information sits at the wrong layer, it becomes either repetitive or dangerous. A current campaign deadline in personal instructions can silently affect an unrelated project months later. A company-wide publication gate in a one-off prompt disappears in the next conversation. A home address in a project file exposes more people than necessary.
Review each proposed line with two questions: “Will this still be true in six months?” and “Should it apply to an unrelated new conversation?” If both answers are yes, it may belong in personal instructions. If several colleagues need it, place it in a maintained project source instead. If it describes only today’s output, keep it in the task.
Diagnose instruction failure systematically
When responses feel repetitive or ignore a current request, do not immediately add more rules. Run the same small prompt with personal instructions disabled. If the behaviour disappears, the problem is probably a conflict or overly broad default. If it remains, inspect the project instructions, conversation context and product behaviour.
Common failure patterns include duplicated tone rules, examples that are copied too literally, absolute words such as “always” and “never”, and old product names that no longer match the live source. Another pattern is hidden authority: an instruction says the assistant may “handle everything”, while the user expected approval before publication or payment.
Remove one suspect rule at a time and rerun the acceptance prompts. Keep a dated copy of the previous configuration so changes can be reversed. The aim is not to produce the cleverest prompt; it is to maintain a small configuration whose effects are visible and whose failures can be isolated.
Treat portability as another test. Read the instructions without the original conversation and ask whether a new colleague could distinguish a harmless preference from a mandatory control. Expand unexplained acronyms, name the current source of truth and remove references such as “the usual report” that depend on private memory. Clear context travels better across devices, models and future product interfaces, while ambiguous shorthand becomes technical debt inside every response.
Review instructions like configuration
Set a quarterly reminder and review the instructions after any job, region or workflow change. Remove references to discontinued tools and rules that have migrated into project policy. Prices, model names and campaign deadlines should not survive as silent defaults.
Keep a plain-text copy with a revision date. If responses become strangely repetitive or ignore current requests, temporarily disable the instructions and rerun a small test. That separates a product issue from a conflict introduced by the configuration.
The best use of 5,000 characters
If several people need the same rule, move it out of personal instructions and into a maintained team or project document. Shared rules need an owner, revision history and a way to verify adoption. Personal customisation is appropriate for tone and harmless defaults; compliance requirements, product facts and publication gates deserve a source of truth that can be reviewed independently.
Do not try to fill the limit. Use the added space to make boundaries, evidence standards and precedence clearer. A good instruction set is boring in the best way: stable, minimal, testable and safe to apply to a new conversation you have not imagined yet.
