OpenAI has published a prompting guide for GPT-5.6 Sol in its developer documentation (see the References at the end of this article; because the original URL was confirmed to display differently depending on the access environment as of July 17, 2026, this article relies primarily on the archived version as of July 16, 2026). Drawing on its contents, this article organizes the shift in thinking that is emerging in how prompts are written. We distinguish between what the guide states directly and the interpretation we draw from it.

Conclusion — Write the “outcome, constraints, evidence, and completion bar,” not the steps

The premise of the guide is captured in a single sentence.

GPT-5.6 works best when prompts define the outcome, important constraints, available evidence, and completion bar, then leave room for the model to choose an efficient path.

(GPT-5.6 works best when the prompt defines the outcome, the important constraints, the available evidence, and the completion bar, and then leaves the choice of an efficient path to the model.)

This does not mean writing no steps at all. Steps essential to accuracy or safety—the procedure for obtaining prerequisites needed for correctness, the conditions for using tools, verification methods, retry and stop conditions, when to use parallel versus sequential processing—the guide continues to ask that these be stated explicitly. What changes is the placement of the center of gravity: humans should not finely fix even the work paths the model can judge for itself.

The “Suggested prompt structure” section later in the guide presents a template made up of eight items: Role, Personality, Goal, Success criteria, Constraints, Tools, Output, and Stop rules. Of these, the four items Goal, Success criteria, Constraints, and Stop rules can be read as an almost direct concretization of the outcome, completion bar, and constraints raised at the outset. The remaining element, “evidence,” is not set up as an independent item; it can be read as being concretized in a distributed form across the descriptions of Constraints, Tools, and Success criteria (this mapping is not something the guide states explicitly, but an organization made by this article).

Why “outcomes” rather than “steps” — the effects shown by the internal evaluation

The “Simplify prompts first” section lists what should be cut and what should be kept as follows.

What should be cut:

  • Duplicated statements of the same rule
  • Redundant examples that do not change behavior
  • Step-by-step instructions for behavior that is already performed stably
  • Tools unrelated to the task, and their descriptions

What should be kept:

  • Outcomes visible to the user
  • Success criteria and stop conditions
  • Constraints regarding safety, business, evidence, and permissions
  • Context-dependent tool selection rules
  • The required output format and its verification methods

On that basis, the guide presents the following figures as the result of carrying out this organization.

In a sample of internal coding-agent eval runs, configurations with leaner system prompts improved evaluation scores by roughly 10–15% while reducing total tokens by 41–66% and cost by 33–67%. Results will vary by workload, so treat these ranges as directional and validate changes on representative tasks from your own application.

(In a sample of internal coding-agent evaluation runs, configurations with leaner system prompts improved evaluation scores by roughly 10–15% while reducing total tokens by 41–66% and cost by 33–67%. Because results vary by workload, these figures should be treated as directional reference values and changes should be validated on tasks representative of one's own application.)

As the guide itself states, these figures come from a sample of an internal evaluation aimed at coding agents, and they are not a result demonstrating comparable improvement for other uses such as chat, writing, or research tasks. That said, at least in this evaluation, the result shows that adding instructions does not directly translate into accuracy; rather, cutting them raised the evaluation scores. The guide states the reason as follows.

GPT-5-class models follow prompt contracts closely, so conflicting rules can create more instability than missing detail.

(Because GPT-5-class models follow the prompt's contract faithfully, conflicting rules can create more instability than missing detail.)

The more faithful a model is to what the prompt says, the more readily the contradictions a writer unconsciously embeds surface as unstable behavior. The intuition that writing in more steps makes things safer does not necessarily hold under this relationship.

What “writing the outcome” concretely means

The “Outcome-first prompts and stopping conditions” section explains this idea as follows.

Describe the destination rather than prescribing every step. GPT-5.6 can usually choose an efficient search, tool, or reasoning path when the prompt states what good looks like.

(Describe the destination rather than prescribing every step. When the prompt states what "good" looks like, GPT-5.6 can usually choose an efficient search, tool, or reasoning path on its own.)

What concretizes the completion bar is the stopping conditions, which define when to answer, when to retry, and when to insert a confirmation. The example the guide gives is as follows.

After each result, ask whether the core request can now be answered with useful evidence. If yes, answer.

(After each result, ask whether the core request can now be answered with useful evidence. If it can, answer.)

The guide also recommends avoiding heavy use of absolute rules such as ALWAYS and NEVER, and, in situations that call for judgment—whether to use a tool, whether to continue iterating—writing decision criteria rather than absolute rules.

Taking this article itself as material, let us compare two ways of writing (these are not OpenAI’s examples but were created by this article for comparison).

Step type:

First, search the official site. Next, open three related pages
and summarize each of them. After that, extract the commonalities...

Outcome type:

Using only OpenAI's official information, explain the changes in
GPT-5.6's prompt design. Attach evidence to important claims, and
distinguish anything that cannot be confirmed in the official
information as speculation. The task is complete once the reader
is in a position to revise their existing prompts.

The latter does not fix the number of searches or the order in which pages are viewed. What it settles is the outcome (an explanation of the changes), the evidence (backing for important claims), and the completion bar (the reader being in a position to fix their own prompts). Still, the constraint “base it only on official information” remains, just as in the former.

Autonomy boundaries and narrowing the toolset

The design of “writing the outcome and leaving the path to the model” comes as a set with a line drawn around how far the model may act on its own judgment. The “Define autonomy and approval boundaries” section divides actions that may proceed without approval from actions that require approval as follows.

  • No approval needed (actions within a safe range): reading files, checking logs, editing code within scope, running non-destructive tests, local changes within the requested scope
  • Actions requiring approval: writing externally, destructive operations, purchases, substantially expanding the target scope

Define what level of action each request authorizes so the model can continue safe, in-scope work without unnecessary pauses while stopping before external, destructive, costly, or scope-expanding actions.

(Define what level of action each request authorizes, so that the model can continue safe, in-scope work without unnecessary pauses, while stopping short of actions that are external, destructive, costly, or scope-expanding.)

The “Tool routing” section raises the points of handing over only the tools relevant to the task, and stating explicitly that the prerequisite steps cannot be omitted when accuracy depends on the retrieval procedure. It also holds that “Programmatic Tool Calling” (PTC) should be used only for bounded ranges of processing such as filtering, deduplication, aggregation, and batch processing; in situations that finish in a single call, situations where the next judgment changes based on the result, or situations where the final answer requires a citation, direct calls are said to be more suitable.

Behavior in long-running tasks

The “Long-running workflows and state” section deals with how to report during tasks that span multiple steps. Under a policy of giving a short preamble before the first tool call and thereafter updating only when the situation changes significantly, it states the following.

Do not ask the model to narrate routine tool calls.

(Do not have the model give a running commentary on routine tool calls.)

A single update is kept to stating one thing that has been settled and one thing to do next, and when compressing the conversation history, summarizing at each milestone is recommended.

The body of this guide (archived as of July 16, 2026) did not provide an explanation targeting Codex or ChatGPT Agent. That said, the behavior this section prescribes—“do not give a running commentary on routine calls,” “report only when the situation changes”—can be considered a design commonly required for the kind of autonomous execution that keeps running for long stretches without a person intervening at every step. Note that OpenAI’s documentation has since been updated, and the related current Model guidance now has a “Migrate with Codex” section in which Codex is handled explicitly.

How to view the shift toward “writing the outcome”

The design we have seen so far stands in contrast to the practice of writing a request out as fine-grained steps and guiding the model step by step. However, the guide itself does not compare itself by name with such a practice, and we note that this contrast is an organization made by this article.

What the guide raises as its point of comparison is GPT-5.5 (for the migration of reasoning effort, GPT-5.4 is also listed alongside as a baseline). For example, the “Personality, collaboration, and response length” section states the following.

GPT-5.6 tends to be more concise by default than GPT-5.5.

(GPT-5.6 tends to be more concise by default than GPT-5.5.)

On that basis, it recommends a division of roles in which the default level of detail is set with the text.verbosity parameter (low, medium, high), while task-specific requirements are written on the prompt side. In addition, the “Prompt migration workflow” section raises a procedure for switching models: first take a baseline evaluation while keeping the existing reasoning effort setting, then gradually remove the instructions that were serving as scaffolding while adding fixes targeted only at the measured degradation. This is an ordering meant to avoid moving the prompt rewrite and the model’s behavioral change at the same time.

Taking these together, what the guide presents is not a mere change in writing technique but a division of roles: define the outer frame of the task—outcome, constraints, evidence, and completion bar—and leave the choice of path to get there and the fine judgments to the model. The center of gravity of the work humans take on appears to be moving from “writing instructions to the AI” to “designing the framework of the work entrusted to the AI.”

Summary

  • The GPT-5.6 prompting guide recommends a design that defines the outcome, constraints, evidence, and completion bar, and does not fix the work paths the model can judge
  • In OpenAI’s internal coding-agent evaluation, the result shows that leaner configurations improved evaluation scores by roughly 10–15% and reduced tokens by 41–66% and cost by 33–67% (the guide itself notes that results vary by workload and should be treated as directional reference values)
  • Autonomy boundaries (the line between actions needing no approval and actions requiring approval), narrowing the toolset, and reporting frequency in long-running tasks are also organized as extensions of this design philosophy
  • What the guide raises as its point of comparison is GPT-5.5 (for the migration of reasoning effort, GPT-5.4 is also listed alongside). An explanation targeting Codex or ChatGPT Agent was not found in the body of the guide as of July 16, 2026. The related current Model guidance has a section dealing with Codex
  • The view that the center of gravity of the work humans take on is moving from “writing instructions” to “designing the task” is a consideration by this article

Addendum (July 18, 2026): Of the descriptions in the archived version as of July 16, 2026 that this article used as its main source, the content corresponding to the opening definition sentence, the reasoning about prompt contracts, the stopping-conditions section, and the long-running-tasks section was not found on the current page confirmed as of July 18, 2026. The current page is not a standalone guide but has been consolidated into the broader “Model guidance” page. A detailed comparison is organized in the follow-up article.

References