Custom instructions and consistent results

Before and after: the house-style example

Here is a generic prompt with no custom instructions:

> You: Write a short update about our APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → rate limit change.

> ChatGPT: Sure! Here's a friendly update you can use:

> "Hi everyone! 🎉 We're excited to share that we've updated our APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → rate limits..."

Enthusiastic, emoji-laden, vague. Now the same prompt with custom instructions filled in.

Box 1 (about you):

Box 2 (how to respond):

Same prompt, new result:

> ChatGPT: Rate limit increase, effective 14 March 2026.

> The default limit on /v2/transactions rises from 100 to 300 requests per minute. Existing integrations need no code changes; the new ceiling applies automatically. If you currently implement client-side throttling at 100 RPM, you may raise it to 300 to improve throughput. Burst limits and the 429 retry-after header are unchanged.

That is your house style, applied automatically, in every new chat, with zero prompt overhead. The model is doing the same work; you have simply removed the ambiguity it would otherwise fill with defaults.

How to write instructions that hold

The mistake is writing aspirational fluff ("be helpful and smart"). The model is already trying to be helpful. Instructions only matter where they resolve a choice the model would otherwise make for you.

Be specific about defaults, not vibes

"Be concise" is weak. The model has no number. Compare:

Encode format, because format is where time is lost

If you always paste output into Slack, Jira, or a CMS, say so:

State what to suppress

Negative instructions are powerful here. "Do not hedge with 'it depends' unless you then give me the deciding factor." "Do not apologise." "If you are uncertain, say so in one line and give your best answer anyway."

Keep them short and orthogonal

These fields share your context windowcontext windowThe context window is the maximum amount of text (measured in tokens) a language model can process at once, including both the input prompt and the generated output.View full definition → with everything else in the chat. Bloated instructions cost tokenstokensA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.View full definition → on every turn and dilute the signal. Aim for tight, non-overlapping rules. A dozen sharp lines beat three paragraphs of prose.

Where custom instructions stop, and Projects begin

Custom instructions are global. They apply to every standalone chat. But your "house style" for client emails is not the same as your house style for SQLSQLSales Qualified Lead: a prospect the sales team has validated as ready for direct outreach and a proposal, having passed clear qualification criteria.View full definition → debugging. Cramming both into the global boxes creates contradictions.

This is what Projects solve. A Project is a workspace with its own instructions, its own uploaded files, and its own chat history, separate from your global settings. Inside a Project, you set project-specific instructions that layer on top of (and can override) your global ones.

A clean division of labour:

• Global custom instructions: who you are, your language, your universal anti-patterns (no emoji, British spelling). The stuff true everywhere.
• Project instructions: the rules for one body of work. "This Project is the Q2 onboarding redesign. Reference the uploaded PRD. Assume the reader is a product manager, not an engineer."

So when you spin up a "Compliance Comms" Project, you do not re-type your tone rules; you inherit them and add the project-specific ones. See help.openai.com on Projects for file and instruction scoping.

When you need more than instructions: Custom GPTs

If you find yourself building the same context, files, and tone for something other people will use, you have outgrown personal instructions. That is a Custom GPT: a packaged, shareable assistant with its own instructions, knowledge files, and optionally Actions (calls to external APIs) and Connectors (access to tools like search or your own dataown dataData collected directly from your own customers and prospects through your own channels: your most reliable and privacy-compliant source.View full definition → sources).

The relationship is a ladder:

| Tool | Scope | Shareable | Best for |

|------|-------|-----------|----------|

| Custom instructions | Every chat, just you | No | Your personal default behavior |

| Project instructions | One workspace, you | Limited | One ongoing body of work |

| Custom GPT | A named assistant | Yes, via link or GPT Store | A repeatable role others will reuse |

The "instructions" field in a Custom GPT is the same idea as Box 2, scaled up: it is the system prompt for that assistant. Everything you learned about writing tight, specific, format-first rules applies directly when you build one.

The same principle in the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →

Custom instructions are ChatGPT's UI for what the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → calls system instructions. When you move from the ChatGPT app to the OpenAI platform, your "how to respond" rules become the instructions parameter on the Responses API, or a system message in Chat Completions.

This is the bridge worth seeing once: the discipline you build writing good custom instructions transfers directly to production code.

from openai import OpenAI

client = OpenAI()

HOUSE_STYLE = (
    "Write in plain, direct English. No emoji, no exclamation marks. "
    "Lead with the change and its effective date. State old and new values. "
    "Default to under 120 words. Use British spelling."
)

response = client.responses.create(
    model="gpt-4.1",
    instructions=HOUSE_STYLE,
    input="Write a short update about our API rate limit change.",
)

print(response.output_text)

Notice HOUSE_STYLE is literally your Box 2 text, lifted into a constant you reuse across every call. That is the point: a good instruction set is a reusable asset, not a one-off.

If you need the output in a fixed shape (not just a tone), you stop describing the format in prose and use structured outputs instead, which constrains the model to a JSON schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → you define. Instructions handle *style*; structured outputs handle *shape*. Use both together: instructions for "be terse and British," a schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → for "return exactly these fields."

A practical audit of your current instructions

Open your settings now and check them against this:

1. Do they resolve real choices? Delete any line the model already does by default ("be accurate").

2. Is there a number anywhere? Length, count of bullets, max examples. If not, the model is guessing.

3. Do they name your output destination? Slack, email, code, a CMS. Format follows destination.

4. Have you said what to suppress? Hedging, apologies, emoji, preamble.

5. Are they global-true? Anything that only applies to one project belongs in a Project, not here.

Run a test: paste an identical prompt with instructions on, then turn them off and run it again. The delta is exactly what your instructions are buying you. If there is no delta, your instructions are not earning their tokenstokensA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.View full definition →.

Key Takeaways

• Write instructions that resolve choices, not vibes. Replace "be concise" with a word count; replace "be professional" with named formatting tied to where the output goes.
• Use negative rules. Telling ChatGPT what to suppress (emoji, hedging, preamble) is often higher-leverage than telling it what to add.
• Split global from project. Keep universal truths (your role, language, anti-patterns) in custom instructions; put per-engagement rules in a Project so they do not contradict each other.
• Treat your instruction set as a reusable asset. The same text you write in Box 2 becomes the instructions parameter in the Responses APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → and the system prompt of a Custom GPT.
• Reach for structured outputs when you need shape, not just style. Instructions govern tone; a JSON schema governs the exact fields. Combine them for production-grade consistency.