Last week I deleted half of my favorite prompt and the output got better.
That isn't a humblebrag. It's me admitting I've been wasting tokens — and probably making my results worse — for about two years. The prompt in question had everything the old playbook said a good prompt should have: a role ("you are a senior data analyst"), a long context block, six numbered steps, three worked examples, and a closing paragraph that reminded the model to "think carefully, don't rush, and double-check your work." It was the kind of prompt you'd find in any prompt engineering course from 2024.
Then I read OpenAI's new guidance for GPT-5.6, and it told me to throw most of that away.
The advice stung because I'd paid for it — in time, not just tokens. And the more I sat with it, the more it made sense.
Why the "longer is better" advice finally broke
For two years, the standard prompt engineering advice pointed in one direction: add more. Add a persona. Add context. Add steps. Add examples. Add a final nudge so the model doesn't get lazy. The models were weak enough back then that this actually helped — every extra instruction was scaffolding the model couldn't build for itself.
GPT-5.6 is not that model.
OpenAI's own framing is blunt: newer models are better at inferring your underlying goal and the standard of work you expect from context, without you spelling out each step. When you hand a model turn-by-turn instructions it no longer needs, you're not helping. You're adding noise.
I keep coming back to the same analogy, because it's the clearest way to explain the shift. The old way treated the model like a rookie who needs every movement scripted — left foot, right foot, watch the defender. GPT-5.6 is more like Messi. Yell turn-by-turn instructions at him from the sideline and he just thinks you're an idiot. The player upgraded. The coaching manual didn't.
What OpenAI's numbers actually say
I usually roll my eyes at vendor-published benchmarks, but these are specific enough to take seriously.
In OpenAI's internal coding-agent evals, configurations with leaner system prompts improved evaluation scores by roughly 10–15% while cutting total tokens by 41–66% and cost by 33–67%.
Read that again, because it's the rare case where two things move in your favor at once. Shorter prompts scored higher and cost less. You don't have to trade quality for efficiency. The bloated prompt was losing on both axes.
OpenAI is careful to call these numbers "directional" and tell you to validate on your own tasks. Fair. But the direction is hard to argue with, and it matches what I saw when I actually tried it.
There's a second, less obvious finding buried in the guide, and it's the one that explains a lot of weird failures people are hitting. GPT-5.6 follows a prompt's contract very strictly. Where older models would quietly pick one of two conflicting instructions and ignore the other, GPT-5.6 may try to honor both — burning reasoning tokens and getting slower and more expensive in the process. A prompt that says "be detailed" in one paragraph and "be concise" in another isn't just redundant anymore. It's actively destabilizing.
That reframes a bloated prompt. It isn't merely wasteful. Every extra rule is another chance to contradict a rule you wrote three paragraphs earlier.
A before-and-after that convinced me
I had a real task sitting in front of me when I read all this, so I used it as a test.
The old way — the way I'd been writing prompts for two years:
"First, create a list of all unique transaction descriptions. Then group similar descriptions together and assign each group a category. Build a lookup table of descriptions and categories. Then add a Category column to the transactions sheet and use XLOOKUP to assign each transaction to the right category. Make sure the formula fills down automatically when new transactions are added."
That prompt works. It's also me doing the model's thinking for it — step one, step two, step three, with the tool name thrown in for good measure.
The new way — outcome first:
"I have a list of transactions with inconsistent descriptions. I want to categorize each one automatically, and the solution needs to keep working as new transactions come in. What's the best approach?"
Same goal. Same constraints. But the first prompt tells the model how to walk. The second tells it where I'm trying to get and lets it find the route.
The second one gave me a better answer — and, more importantly, it told me why it picked that approach, which the first prompt never would have. When you stop dictating the method, you sometimes learn something about the method you'd been insisting on.
How to write a leaner prompt without losing what matters
Cutting a prompt isn't the same as gutting it. The stuff that earns its keep is the stuff you can't infer from context: the outcome, the constraints, and what "done" looks like. Everything else is candidate for deletion.
Here's the shape that survives, in practice:
- The result you want. Not the steps. Not the method. What should exist when this is over.
- The constraints. The lines that can't be crossed — don't invent features, don't delete anything, only look at these files.
- The acceptance criteria. How the model checks its own work before it hands it back.
That's usually it. No persona, no "think step by step," no reminder not to be lazy. Those things were scaffolding for a weaker model. GPT-5.6 doesn't need them, and they cost tokens to state.
OpenAI's trim list is worth taping to your monitor: repeated statements of the same rule, style instructions that don't change behavior, examples that don't change behavior, and process instructions for things the model already does reliably. The keep list is short: the user-visible outcome, success criteria, stopping conditions, and safety or evidence constraints.
One practical note if you're actually doing this on a prompt that already works: cut one thing at a time. Remove one group of instructions, rerun the same eval, compare. If you strip everything at once and the output degrades, you won't know which cut was the one that mattered.
It's the same rule I use when testing tools for NSFWAITool: keep the task stable, change one variable, and see whether the result actually improves. Our review methodology is built around that distinction between what a provider claims and what a repeatable test shows.
When detailed instructions still earn their keep
I want to be careful here, because "shorter is better" becomes its own kind of cargo cult if you apply it blindly.
OpenAI's guide still says to keep examples and style guidance when they encode a real product requirement or correct a measured gap. If your output has to hit a specific voice, a specific format, or a specific legal constraint, that stays. If a few-shot example is the only reliable way to teach a format, keep it. You're not aiming for the fewest tokens; you're aiming for the fewest tokens that still do the job.
You can see why this matters once you leave general-purpose chatbots. An AI companion may genuinely need character, tone, and memory context, while an AI video generator needs concrete visual and motion constraints. Cutting both prompts to the same three-line formula would be missing the point. The useful prompt is the shortest one that preserves what that particular tool needs.
The real shift is sequencing. The old reflex was to front-load everything — put every instruction in the opening prompt, just in case. The new reflex is "let go first, tighten later." Give the model the task, watch how it handles it, and only add instructions where it actually falls short. It's faster than writing a thousand-word prompt up front, and it tells you which instructions were pulling weight in the first place.
The distinction everyone gets wrong: persona vs. path
Since the guide dropped, I've seen people swing too far the other way — assuming this means the persona is dead. It isn't, and conflating the two ideas causes real mistakes.
A persona controls how the output sounds. Tone, register, role, the voice on the page. A step-by-step instruction controls how the model gets there — the execution path. Those are different levers.
The new guidance is telling you to stop over-specifying the path. It says nothing about giving up control of the voice. If you're writing customer-facing copy and you want it to sound like a specific brand, you still say so — that's a product requirement, not a step-by-step script. Style is yours to set. The path is the model's to choose.
Put another way: give the model the destination and the guardrails, then stop telling it how to drive.
Start shorter, not longer
If you take one thing from all of this, make it the sequence. Write the result you want and your acceptance criteria first. Then cut the word count in half. Then cut it in half again. If you're still nervous, send it and see what comes back — you can always add a line back in where the output actually falls short.
That's the part I had to learn the hard way. Most of the instructions I was adding weren't helping the model. They were reassuring me. And GPT-5.6 is good enough now that my reassurance is just noise between me and the answer.
The 2023 lesson was how to write longer prompts. The 2024 lesson was how to manage the context window. The 2026 lesson is simpler, and harder: learn to shut up, describe the outcome, and let the model do the job it was built for.
Frequently asked questions
Are shorter prompts always better on GPT-5.6?
No—and this is where the headline can turn into bad advice. Shorter prompts won in OpenAI's sample of internal coding-agent evals, but OpenAI calls the result directional. If removing a line makes your real task worse, put the line back.
What should I cut first?
Start with the embarrassing stuff: the same rule stated twice, generic roles that change nothing, examples the model no longer needs, and reminders to think carefully. Leave the outcome, constraints, and definition of done alone.
When is a long prompt still justified?
When the length carries information the model genuinely needs—a house style, a fixed output schema, specialist context, legal boundaries, or examples that correct a failure you have actually observed. Long is not the problem. Unnecessary is.
Should I stop using personas?
Only if the persona is decorative. If it controls the voice, audience, or professional standard of the answer, it is doing real work. The thing to question is the scripted path, not your control over the output's personality.
Does the same advice apply to AI chat, image, and video tools?
Not automatically. Those products read prompts differently and fail in different ways. A chat tool may need relationship and memory context; a video tool may need precise action and camera constraints. Test each workflow instead of carrying over one universal template.
How do I test whether a shorter prompt is actually better?
Use the same set of tasks, remove one instruction group, and compare quality, failures, token use, latency, and cost. One lucky answer proves almost nothing. The prompt earns the cut when the improvement survives repetition.