True. The real trick, if you have a client-side agent framework to hand, is to prompt it once as "gently" as possible to "just solve the problem"; and then, after its response to that, automatically prompt it again, with a separate prompt, to summarize that response a certain way. That way, the second prompt isn't "in mind" during generation of the first prompt. (And ideally, you don't even present the intermediate result to the user.)

Sadly, you can't do things like this directly using ChatGPT's own "GPTs" abstraction. (For that feature to be useful, they really need some concept of server-side agents as stateful resident IO-stream-reducer actors.)

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

That would be true of non-iterative models that just emit an output from beginning to end.

No reasonable model has worked that way for years.

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.)

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.")

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.

> LLMs in general just love to hear themselves talk!

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

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

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.