XDA’s report on stripping down prompts accurately reflects the central recommendation in OpenAI’s current GPT-5.6 model guidance. OpenAI says its internal coding-agent evaluations saw leaner system prompts improve evaluation scores by roughly 10% to 15%, while cutting total token use by 41% to 66% and estimated costs by 33% to 67%. Those are striking figures, but they come with a restriction that gets lost when the advice is flattened into “write shorter prompts”: OpenAI calls them directional results from its own coding-agent evaluation runs, not a benchmark for every ChatGPT conversation or every enterprise workflow.
The change is less a repudiation of prompt engineering than an admission that the old playbook is now easy to overapply. GPT-5.6 is intended to infer more intent from context, carry out longer multistep work, and operate tools with less step-by-step supervision. If a prompt still contains three generations of defensive instructions—role definition, duplicated prohibitions, lengthy style rules, few-shot examples, and tool descriptions for capabilities the model will never use—each new line is another opportunity to distract it from the actual job.
For users who simply ask ChatGPT to summarize a document or draft an email, the practical gain may be cleaner answers and less fiddling. For organizations sending long system prompts to GPT-5.6 through the API, Codex, or an internal agent, the potential consequence is financial as well as operational: repeated material consumes context, complicates maintenance, and can make model behavior harder to diagnose after a failure.
OpenAI’s newer advice contradicts its older generic playbook—only on the surface
The apparent reversal is real enough to confuse anyone who learned prompting from OpenAI’s older public guidance. Its longstanding prompt-engineering material still recommends putting instructions up front, being specific about output and context, and using examples to demonstrate a requested format. Those recommendations remain valid. GPT-5.6’s model-specific guide does not say “be vague”; it says not to carry instructions that add no measurable value.
That distinction is the heart of the update. A prompt such as “Write a concise, professional, friendly, empathetic, well-structured Windows troubleshooting reply; do not use filler; do not be repetitive; do not add an unnecessary sign-off; keep it short” contains several overlapping controls and leaves important questions unanswered. What counts as short? What must be preserved? Is the response for a help-desk technician or an end user? Should the model suggest registry changes, and if so, should it require approval?
A more useful instruction states the non-negotiable outcome: lead with the fix, list prerequisites and rollback steps, identify destructive commands, and keep the answer to a defined number of steps. That is still detailed prompting. It is simply specific where the task requires control, rather than long because it is trying to anticipate every bad answer the model could possibly produce.
OpenAI’s own wording is particularly important here. It advises teams to retain examples and style guidance when they express a product requirement or fix a measured weakness in model output. If a help-desk agent must always emit a valid JSON schema, distinguish Microsoft 365 from Microsoft 365 Apps, or provide a change ticket number before suggesting an Intune policy modification, an example may be exactly the right control. Removing it merely because it makes the prompt shorter would be cargo-culting the new advice.
The company also advises removing material gradually: take a prompt and tool set that already works, remove one group of instructions, examples, or tools, then rerun the same evaluations. That is a testing discipline, not a writing preference.
The published numbers are useful, but they are not an independent performance result
The 10% to 15% reported improvement is the most attractive claim in the new guidance, and also the one that needs the most care. OpenAI identifies the underlying work only as a sample of internal coding-agent evaluation runs. It does not publish the tested prompt variants, the task mix, the model settings, the scoring criteria, or the distribution of results across workloads in the model guide.
That means the figures cannot tell an IT department whether trimming a 6,000-token system prompt will improve PowerShell remediation, Windows event-log triage, SCCM packaging, endpoint documentation, or a customer-facing support bot. A coding agent with a bloated roster of tools is a good candidate for simplification; a compliance assistant with carefully curated reference examples may not be.
No independent outlet located in this review reported a replicated evaluation of OpenAI’s stated 10% to 15% improvement. XDA’s account is a useful first-person illustration of the approach, but it is not controlled testing. The evidence supports a practical claim—that redundant prompt material can damage GPT-5.6 performance and inflate token use—not a blanket rule that any shorter version of a prompt will be better.
This matters because prompts frequently become long for legitimate reasons. They may encode approved language, legal disclaimers, escalation rules, a corporate writing style, structured-output requirements, or the boundaries between viewing data and changing it. Deleting those controls without a regression test turns optimization into an untracked behavior change.
For a production workflow, the relevant test is not whether the output sounds cleaner. It is whether the agent still identifies the right evidence, makes the right tool calls, preserves required caveats, avoids prohibited actions, and produces an answer in the format downstream systems expect.
Autonomy rules should be compact, not absent
The most consequential part of the guide is not prompt length; it is OpenAI’s recommendation to define autonomy and approval boundaries. GPT-5.6 is designed to be proactive over multistep tasks, and OpenAI says developers should say what actions are safe to perform automatically and which require confirmation.
The company’s model guidance draws a clean line. Reviewing files, inspecting logs, diagnosing a problem, planning work, and running non-destructive validation can often proceed without an approval pause. External writes, destructive actions, purchases, or material scope expansion should require confirmation. For a Windows-focused environment, that may translate to allowing an agent to collect Event Viewer records, inspect installed updates, parse an Intune report, and propose a remediation plan—but requiring authorization before it deletes profiles, changes Group Policy, disables security software, rotates credentials, or pushes a script to endpoints.
OpenAI specifically warns that scattering instructions such as “ask first,” “do not mutate,” and “wait for approval” throughout the prompt can make GPT-5.6 overly cautious. The model may ask for permission before safe work that the user already requested, producing the familiar agent experience of a tool that talks about solving a problem instead of beginning the investigation.
The remedy is not to eliminate guardrails. It is to centralize them and make the action boundary concrete. “Do not make changes without permission” is less useful than “You may read local configuration, logs, and documents; you may edit files only inside the requested repository; require confirmation before external communication, account changes, deletes, purchases, deployments, or changes outside the stated folder.”
That is a material design issue for AI agents with access to Windows administration tools. A model that becomes less hesitant is more productive only when the boundary that contains it is precise.
API controls now replace some prompt workarounds
Some of the new guidance applies directly to developers, not to ordinary ChatGPT users. OpenAI recommends the Responses API’s
text.verbositysetting—low, medium, or high—for consistent default response detail, then asks developers to use the prompt for task-specific requirements. In other words, if an application wants consistently compact replies, it can increasingly express that preference through an API control rather than repeating “be concise” in every system prompt.
GPT-5.6’s guide also recommends defining exactly what must survive shortening. OpenAI’s own example calls for a conclusion, supporting evidence, a material caveat, and a next action, while cutting introductions, generic reassurance, repeated language, and optional background. That is a better pattern for technical output than a bare “keep it brief,” which can result in a response that omits the one detail an administrator needs to act safely.
OpenAI says GPT-5.6 is more concise by default than GPT-5.5, so broad brevity prompts carried forward from a previous deployment may now overshoot. Teams migrating an existing assistant should watch for this specifically: a model can technically follow “be concise” while dropping escalation criteria, a rollback warning, or the evidence behind a diagnosis.
There is also a cost nuance absent from most short summaries of the guidance. GPT-5.6 supports prompt caching, including explicit cache breakpoints, and OpenAI applies a substantial discount to cached-input reads. Cutting repeated text is usually beneficial, but an organization should measure its real bill rather than assume token reduction maps one-for-one to savings. A long, stable system-prompt prefix reused across many calls may be cheaper than its raw length suggests; changing it frequently can also weaken cache reuse.
Treat prompt trimming as a change-control exercise
The sensible first target is not the user’s one-off ChatGPT question. It is the inherited system prompt that has been patched for months: duplicated “do not” clauses, three overlapping tone instructions, old examples from a prior model, and descriptions for tools that are no longer exposed.
A practical GPT-5.6 cleanup should proceed in small steps:
- Remove repeated rules first, especially where the same requirement appears in a persona block, a safety block, and an output-format block.
- Remove tool definitions the agent cannot or should not call for the specific workflow.
- Keep examples that enforce a machine-readable format, a business requirement, or a demonstrated correction to recurring model behavior.
- Convert broad style requests into explicit output requirements, such as mandatory sections, maximum steps, evidence requirements, and prohibited actions.
- Run the old and new prompts against the same representative tickets, documents, repositories, or incident scenarios before deploying the revision.
The final point is the one the “less is more” slogan skips. Prompt length is not the quality metric; successful task completion is. OpenAI’s guide itself says lower token use, fewer calls, or fewer intermediate turns count as improvements only when the final answer still meets the existing quality bar.
GPT-5.6 may need less hand-holding than its predecessors, but it still needs a clear job, the necessary context, and explicit limits on actions that carry risk. The prompt lines worth deleting are the ones that merely repeat themselves. The lines worth keeping are the ones that establish what success looks like—and what the model must never do on its own.