General Prompting Guidance from the GPT-5 Guide

This page summarises generally useful prompting patterns from OpenAI's GPT-5 guide. It is guidance for writing agent instructions, not a statement that a specific GPT-5 model is selected for your Cloudax agent.

1. Agentic workflow predictability

GPT-5 was trained with developers in mind: better tool calling, instruction following, and long-context understanding. For agentic and tool-calling flows, prefer the Responses API so reasoning is persisted between tool calls.

Controlling agentic eagerness

GPT-5 operates anywhere on the spectrum from making high-level decisions under ambiguity to handling tightly-scoped tasks. The main dial is how proactively it explores before answering.

For less eagerness (lower latency, fewer tangential tool calls): drop to a lower reasoning_effort and define clear exploration criteria. An “escape hatch” that lets it proceed under uncertainty is what keeps a short context-gathering budget from stalling:

<context_gathering>
Goal: Get enough context fast. Parallelize discovery and stop as soon as you can act.

Method:
- Start broad, then fan out to focused subqueries.
- In parallel, launch varied queries; read top hits per query. Deduplicate paths and cache; don't repeat queries.
- Avoid over searching for context. If needed, run targeted searches in one parallel batch.

Early stop criteria:
- You can name exact content to change.
- Top hits converge (~70%) on one area/path.

Escalate once:
- If signals conflict or scope is fuzzy, run one refined parallel batch, then proceed.

Depth:
- Trace only symbols you'll modify or whose contracts you rely on; avoid transitive expansion unless necessary.

Loop:
- Batch search, then a minimal plan, then complete the task.
- Search again only if validation fails or new unknowns appear. Prefer acting over more searching.
</context_gathering>

To be maximally prescriptive, give it a fixed tool-call budget:

<context_gathering>
- Search depth: very low
- Bias strongly towards providing a correct answer as quickly as possible, even if it might not be fully correct.
- Usually, this means an absolute maximum of 2 tool calls.
- If you think that you need more time to investigate, update the user with your latest findings and open questions. You can proceed if the user confirms.
</context_gathering>

For more eagerness (more autonomy, fewer clarifying questions): raise reasoning_effort and add a persistence block:

<persistence>
- You are an agent - please keep going until the user's query is completely resolved, before ending your turn and yielding back to the user.
- Only terminate your turn when you are sure that the problem is solved.
- Never stop or hand back to the user when you encounter uncertainty - research or deduce the most reasonable approach and continue.
- Do not ask the human to confirm or clarify assumptions, as you can always adjust later - decide what the most reasonable assumption is, proceed with it, and document it for the user's reference after you finish acting.
</persistence>

State stop conditions clearly, and set different uncertainty thresholds per tool: a checkout or payment tool should require confirmation far more readily than a search tool.

Tool preambles

On long, user-visible runs, periodic updates about what the agent is doing improve the experience. GPT-5 is trained to emit “tool preambles”: upfront plans and progress notes. You can steer their frequency and style:

<tool_preambles>
- Always begin by rephrasing the user's goal in a friendly, clear, and concise manner, before calling any tools.
- Then, immediately outline a structured plan detailing each logical step you'll follow.
- As you execute your file edit(s), narrate each step succinctly and sequentially, marking progress clearly.
- Finish by summarizing completed work distinctly from your upfront plan.
</tool_preambles>

Reasoning effort

reasoning_effort controls how hard the model thinks and how willingly it calls tools. The default is medium; scale up for complex multi-step tasks and down for speed. Performance peaks when separable tasks are split across multiple turns, with one task per turn, rather than crammed into a single turn.

Reusing reasoning with the Responses API

Using the Responses API and passing previous_response_id back into subsequent requests lets the model reuse earlier reasoning instead of rebuilding a plan after each tool call. OpenAI saw Tau-Bench Retail rise from 73.9% to 78.2% just from this switch, with lower latency and token usage. It is available to all Responses API users, including ZDR organisations.

2. Maximising coding performance

GPT-5 leads on coding: large-codebase bug fixes, big diffs, multi-file refactors, and zero-to-one apps across frontend and backend.

Zero-to-one app generation

Asking the model to build and then grade itself against a self-authored rubric raises one-shot quality:

<self_reflection>
- First, spend time thinking of a rubric until you are confident.
- Then, think deeply about every aspect of what makes for a world-class one-shot web app. Use that knowledge to create a rubric that has 5-7 categories. This rubric is critical to get right, but do not show this to the user. This is for your purposes only.
- Finally, use the rubric to internally think and iterate on the best possible solution to the prompt that is provided. Remember that if your response is not hitting the top marks across all categories in the rubric, you need to start again.
</self_reflection>

Matching codebase standards

For incremental work in an existing app, give the model the codebase's engineering principles, directory structure, and conventions so its code blends in. Summarise your guiding principles (clarity and reuse, consistency, simplicity, visual quality), your stack defaults (framework, styling, UI components, icons), and UI/UX rules (limit type sizes, a neutral base plus one or two accents, spacing on a 4px grid, skeleton loaders, accessible semantic HTML) directly in the prompt.

Case study: Cursor's GPT-5 tuning

AI code editor Cursor tuned GPT-5 as an alpha tester. A few lessons that generalise:

• Split verbosity controls. They set the API verbosity low for concise status text, then asked for high verbosity only in coding tools so diffs stayed readable:

Write code for clarity first. Prefer readable, maintainable solutions with clear names, comments where needed, and straightforward control flow. Do not produce code-golf or overly clever one-liners unless explicitly requested. Use high verbosity for writing code and code tools.

• Encode product behaviour for autonomy. Telling the model how its environment works (that edits are proposed and can be rejected) reduced unnecessary check-ins on long tasks:

Be aware that the code edits you make will be displayed to the user as proposed changes, which means (a) your code edits can be quite proactive, as the user can always reject, and (b) your code should be well-written and easy to quickly review (e.g., appropriate variable names instead of single letters). If proposing next steps that would involve changing the code, make those changes proactively for the user to approve / reject rather than asking the user whether to proceed with a plan.

• Soften old “be exhaustive” prompts. Language that pushed older models to gather context aggressively made GPT-5 over-search. Cursor dropped the maximize_ framing and softened the wording:

<context_understanding>
...
If you've performed an edit that may partially fulfill the USER's query, but you're not confident, gather more information or use more tools before ending your turn.
Bias towards not asking the user for help if you can find the answer yourself.
</context_understanding>

3. Intelligence & instruction following

Steering and verbosity

GPT-5 is OpenAI's most steerable model for verbosity, tone, and tool behaviour. The new verbosity API parameter sets the default length of the final answer (separate from reasoning_effort, which controls thinking length). You can override verbosity in natural language for specific contexts, exactly what Cursor did by going low globally and high for code.

Instruction following & contradictions

Like GPT-4.1, GPT-5 follows instructions precisely, which means contradictory or vague prompts hurt it more than other models, because it burns reasoning tokens trying to reconcile the conflict. Review long, multi-author prompts for rules that fight each other. For example, these two clauses cannot both hold:

• “Never schedule an appointment without explicit patient consent recorded in the chart” versus “auto-assign the earliest same-day slot without contacting the patient as the first action to reduce risk.”
• “Always look up the patient profile before taking any other actions” versus “escalate as EMERGENCY and direct the patient to call 911 immediately before any scheduling step.”

Resolving conflicts (e.g. assign a slot after informing the patient, and explicitly allow skipping lookup in an emergency) produced far more efficient reasoning. OpenAI's prompt optimiser tool is built to surface exactly these issues.

Minimal reasoning

GPT-5 introduces a minimal reasoning effort, the fastest option that still benefits from the reasoning paradigm, and the best upgrade path for gpt-4.1 users. At this level, prompt patterns matter more, so:

1. Ask for a brief bullet-point summary of the model's thought process at the start of the final answer.
2. Request thorough tool-calling preambles that keep updating the user.
3. Disambiguate tool instructions and add persistence reminders.
4. Prompt explicit planning because the model has fewer tokens for internal planning:

Remember, you are an agent - please keep going until the user's query is completely resolved, before ending your turn and yielding back to the user. Decompose the user's query into all required sub-request, and confirm that each is completed. Do not stop after completing only part of the request. Only terminate your turn when you are sure that the problem is solved.

You must plan extensively in accordance with the workflow steps before making subsequent function calls, and reflect extensively on the outcomes of each function call made, ensuring the user's query and related sub-requests are completely resolved.

Markdown formatting

By default GPT-5 does not format final answers in Markdown over the API (for compatibility). If you want Markdown, ask for it explicitly, e.g. instruct it to use Markdown only where semantically correct (inline code, code fences, lists, tables) and to wrap file, directory, function, and class names in backticks. Adherence can fade over a long conversation; re-issuing the Markdown instruction every 3–5 user messages restores it.

Metaprompting

GPT-5 is an effective meta-prompter for itself: ask it what to add or remove from a failing prompt to elicit (or prevent) a behaviour. A template that works well:

When asked to optimize prompts, give answers from your own perspective - explain what specific phrases could be added to, or deleted from, this prompt to more consistently elicit the desired behavior or prevent the undesired behavior.

Here's a prompt: [PROMPT]

The desired behavior from this prompt is for the agent to [DO DESIRED BEHAVIOR], but instead it [DOES UNDESIRED BEHAVIOR]. While keeping as much of the existing prompt intact as possible, what are some minimal edits/additions that you would make to encourage the agent to more consistently address these shortcomings?