> Avoid generic brevity instructions

That part is confusing because it's not like they provide an example of how default GPT-5.6 output compares with GPT-5.5 both with default output and prompted for brevity. Whenever I use such prompts, it's usually because I want the model to give me the gist in a few sentences. I'd be stunned if GPT-5.6 was that concise by default. I would think that could "break" a lot of things for developers who didn't know to make prompt changes after upgrading to 5.6. What if you were expecting GPT to be as wordy as it usually is? Then suddenly your output is not wordy enough?

Smells like OpenAI trying its best to stave off financial armageddon for another few months. Then again, I'm not sure why they chose to waste so much output computation on verbal diarrhea all this time up to now.

If you conceptualize this as “there is an appropriate amount of brevity for each situation” then it would be expected for a better model to use different amounts of brevity if it gets better at determining the appropriate amount.

My view is that popular models by default output wildly excessive amounts of prose for nearly every use case, so if this changes in a new model that’s a pure win.

The models don't get better, except when a new one is released. Their performance depends solely on the model training before release and how well you curate the context you feed it. That's it. Contrary to popular belief these things are not intelligent.

This has absolutely nothing to do with the comment you replied to.

>The models don't get better, except when a new one is released.

My brother in Christ this entire thread is talking about the new model that was released

It was edited. Original talked about the model learning. Glad they managed to clarify. Because the models are quite literally stupid.

[dead]

It seems like the way brevity instructions have changed is mis-aligned with how most people would expect to use them or are currently using them.

Here's the example they give:

> Instead of asking for the shortest possible answer, replace brevity instructions with prioritization:

> Lead with the conclusion. Include the evidence needed to support it, any material caveat, and the next action. Omit secondary detail and repetition.

> Keep all required facts, decisions, caveats, and next steps. Trim introductions, repetition, generic reassurance, and optional background first.

Generally speaking, when I ask for a short answer, I want a short answer because I'm not really willing to read through a bunch of bullshit to get to a summary. Putting the onus back on me to assume what the model will return and write a longer prompt detailing exactly what information I want completely misses the point of why I'm asking for a short answer in the first place.

> Lead with conclusion.

I would presume (perhaps falsely?) that an instruction like this would lead to the model presenting a conclusion not supported by the evidence, and potentially backtracking as it then tries to justify said conclusion.

Yes, if deliberation happens, the model should figure out what it wants to say during that phase; but if you're using auto mode, the model is not going to be doing any deliberating half the time. In those cases, the output blathering is the model's only chance for deliberation. It "thinks as it talks", per se.

Given that, I would advise a different approach: let it blather, but then get it to write you a conclusion at the end that the model can guarantee will obviate the need to read any of the blathering.

I.e. advise the model to add an "executive summary" to the end of any non-trivial-in-length response. With some wording to carefully navigate the model between "the summary is itself too long" vs "the summary acts more like clickbait, leaving out necessary detail such that it requires actually reading the blather."

Not sure exactly what that wording would look like. I imagine something like "write your postscript executive summary as if you were a senior CIA intelligence analyst summarizing ground-level reports into a daily digest for the Joint Chiefs of Staff. Take up as little of their time as possible, but ensure that any detail critical to decision-making is retained." (But that phrasing might only be useful if the model is delivering a certain type of response, and actively counter-productive otherwise. This kind of thing is delicate.)

Over hours of experimentation with various LLMs, I've found virtually any system prompt can cause unintended skewing of the model's output. Even just 5 to 8 short, direct words about length, tone or formatting can cause subtle yet significant changes in model output.

Longer, more detailed or conditional prompts always introduce an additional cognitive load as it checks every token it generates against the conditions. Making instructions more absolute (like: "Never do...") can increase the duration of compliance but at the cost of creating a significant center of attentional gravity. This can cause far more output distortion as the model devotes increasing portions of its attention budget to ensure compliance with a heavyweight requirement or prohibition. Every word in a global prompt is a trade-off between attention, compliance, drift, etc.

As someone used to thinking of computers as natural deterministic rule-followers, it's weird having to carefully wordsmith and A/B test even the simplest global prompts. It feels like coaxing a hyper-literal, emotionally sensitive, spectrum-ish toddler to comply but without being so strict it gets 'upset' or spirals into hyper-focusing.

This was a big concern for earlier models, but with modern CoT trained models they should be able to come to the conclusion entirely in the thinking trace.

You are absolutely correct. The second suboptimal part of the prompt is this:

> Trim introductions, repetition, generic reassurance, and optional background first.

It's not possible for the model to "trim" those before they've been output, so this is akin to telling it "not think of an elephant or even take the existence of elephants into consideration while solving this problem".

You may be discounting the tokens generated in the thinking trace but not included in the output to users.

Oh the number of time LLM will, for example, be giving me the list of bugs it found in code, when I ask it for a review, just to decide there’s no big half way through explaining it.

Yes this is an extremely well known result for exactly the reason you guessed. It's not just abcktracking, asking an LLM to present a conclusion and then justify is also an excellent way to provoke hallucination as the model con concts "any justification that plausibly justifies the words it's already said".

This is the actual reason why openai _invented_ reasoning models, to give them time/space to work out a solution, rather than having to magic a correct solution out of thin air from token 1.

It's less important now that all models do reasoning, but it's still almost always better to make the output come out last rather than first.

I wonder if it would help to ask it to write a rough draft and then reorder it?

It would (and does), yes; but this takes a lot more output tokens than asking for a summary would. The summary approach is only helpful insofar as it can be cheaper than using the thinking model. (You're basically tricking the instant model into thinking, which it can do, after a fashion.)

But, unless your desired output is literally a document for others to read, at the point where you're having a model generate a full, lengthy output multiple times over with revisions, you may as well just turn off auto mode and have it always deliberate (i.e. choose the thinking model explicitly from the model selector.) Then it'll be as messy as it needs to be while deliberating, but give you exactly what you want as output.

(And if your desired output is literally a document for others to read, that you want to interactively draft and polish, then (in the case of ChatGPT specifically) you should not only be explicitly forcing the "thinking" model, but also should be asking it to activate the "canvas" feature from the start. My understanding is that revising a canvas document involves the model emitting something like editing gestures, rather than simply re-streaming the updated chunks of text. This saves a lot of output tokens on large documents.)

Why would auto mode turn off thinking?

The "auto" mode is (AFAICT) a per-conversation-turn router. (Presumably via a preliminary pass through a very fast tiny model that spits out an number for how challenging it thinks the next response might be to compute.)

On high-challenge turns, the auto mode routes to the "thinking" model. But on low-challenge turns, it routes to the "instant" model.

And the "instant" model, by design, has no capacity for deliberation. (If it did, it couldn't guarantee that its responses would begin streaming "instantly.")

I don't expect that would be the case. This is what's called BLUF or Bottom Line Up Front: https://en.wikipedia.org/wiki/BLUF_(communication)

The model will still have read the entirety of the document before composing its response. And I believe that even in auto mode, there are thinking tokens behind the scenes.

Replace 2 word instruction ('be concise') with a 38 word instruction.

Human can no longer be concise when asking for a few sentences instead of 20 paragraphs of BS they don't want to read when all they want is a summary to verify the general direction of the prompt-work before digging into the details.

such progress!

I don't know how intentional it is / was, but LLMs in general just love to hear themselves talk!

They do, and I want to encourage them to do so because they think through talking. What I don’t want to do is spend time reading all that.

We will probably just get reader-side affordances for this like auto-folded justification and introduction sections and so on.

Doubtless some chat interface will add this the way they’ve added reasoning folding.

Thinking models think through talking, don't reveal that talking, then answer by again thinking through talking. It's kinda funny in a way.

I always expose reasoning traces. How else can you seriously debug?

> LLMs in general just love to hear themselves talk!

Because that’s what’s in the training set. Reticent humans don’t have blogs.

Interesting idea. I think they're getting more wordy over time, personally, so I think it's more to do with the training than the raw data.

Is it just a coincidence that the companies creating them charge by the token?

The aligned incentive appears to be realigning in favor of the corporation.

Pray they do not realign them further.

There are times I require single word answers. I will use whatever model responds as I desire and at this point those models are just a few.

The cost-per-task benchmarks align incentives toward more efficient output and those are the ones gaining steam.

I think instead of "be concise" you could tell it how long the answer should be. I.e. give the answer in one paragraph. Or in 10 lines max.

At least before it would listen to instructions like this.

> At least before it would listen to instructions like this.

Would it actually follow them? IME LLMs are incapable of estimating the length of their own output, the total length of the current context, etc. They just make stuff up unless they have external tools that can inspect those things for them.

That was the case for early models (Llama etc), but they got much better since then. Not perfect, but good enough.

This is from Ministral 3 14B, a 2025 model without reasoning, that you can run on your PC:

> Write a Haiku involving HackerNews, and the capability of large language models like you to reply in an exact number of words or syllables.

    Silicon whispers,
    exact words in code’s embrace—
    Haiku blooms anew.
Across multiple tries it got it wrong a couple times (by ~2 syllables). But syllables are extra tricky (because of how LLMs use tokens) and the point is that for things like "summarize in 5 bullet points" you will mostly get 5 bullet points, maybe 6, but not 10 or 20, and no need for a tool that count bullet points.

[dead]

> could "break" a lot of things for developers who didn't know to make prompt changes after upgrading to 5.6.

How does this differ from the other changes in behavior in 5.6 that will also break things? New models always break things.

It sure is suspicious that both Anthropic (adaptive thinking) and OpenAI (Avoid generic brevity instructions) both seem to be suggesting that the best way to improve outcomes is to entirely leave it to them to decide how many tokens get used.

I mean, it's true that it would be ideal of this stuff did just get figured out optimally behind the API, but there is definitely an incentive on their side to burn more tokens.

Perhaps the incentive is for variable behavior. When there is low GPU demand, burn more, but reduce when there is contention.

[flagged]