How to Get Longer, Deeper Answers from ChatGPT

TL;DR: You get longer responses from ChatGPT by specifying what must be in the answer, not how many words it should have. The model has no running word counter, so a size demand is a guess it aims near and misses. A list of required sections, examples and failure modes is a target it can actually hit.

How do I get ChatGPT to give longer responses?

Give it more things it has to write. Not more instructions about size.

That sounds like a word game until you look at what the model can and cannot check while it works. It cannot check length. It can check whether it has produced the five sections you named, the worked example you required in each, and the closing table you asked for. One of those is a target. The other is a mood.

So the practical move is an inversion. Stop writing prompts that describe the finished object's dimensions, and start writing prompts that enumerate its parts.

Both columns can produce a long answer. Only one produces a long answer made of things you wanted.

Why does "write 2,000 words" fail?

Because the model is not counting while it writes, and there is nothing in the generation loop that could tell it to stop at a number.

Text comes out one token at a time, and a token is not a word. There is no odometer the model consults between tokens. You can see this in the shape of OpenAI's own tooling: the token count for a response arrives afterwards, in the usage object of the completed response, alongside a separate reasoning_tokens figure. Nothing reports progress mid-generation, because nothing is tracking it.

What the model has instead is a learned sense of what a "2,000-word" request usually looks like. It aims in that direction. That is why the misses are wide and go in both directions: a request for 2,000 words can come back at a third of that, and a request for 500 can overshoot badly. If your prompts routinely come back thinner than you expected, why your ChatGPT answers are bad covers the other common causes.

There is a real length control, but it is a dial rather than a target. In the OpenAI API, text.verbosity accepts low, medium or high, and the reference says plainly that lower values produce more concise responses and higher values more verbose ones, with medium as the default. Note what it does not say. It does not name a number, because there is not one. It shifts a tendency.

What is the difference between a long answer and a deep one?

A long answer has more words. A deep answer has more distinctions.

This matters because "make it longer" reliably produces the wrong one. Told to expand, a model reaches first for the cheapest filler available: an introduction restating the question, transitions between sections, a summary of what it just said, and hedges around every claim. All of that is length. None of it is information you did not already have.

Depth comes from a short list of specific moves. Ask for these by name and you get substance. Ask for "more detail" and you get connective tissue.

• A worked example using your actual numbers, names and constraints, not a generic one.
• A counter-example, meaning a case where the advice in that section is wrong.
• A failure mode, meaning what it looks like when this goes badly and how you would notice.
• A decision rule with a threshold in it, so the reader knows which branch applies to them.
• A number, sourced or clearly labelled as an estimate.
• An edge case the obvious version of the advice does not handle.

Six moves. If you require three of them per section across five sections, you have specified fifteen units of substance, and the answer cannot be short. The length is a consequence, and every word of it is carrying something.

How do I write a depth specification?

Name the sections, name what goes in each one, and ban the padding explicitly. Then let the arithmetic do the rest.

Here is the shape. Everything in brackets is yours to replace, and the structure is what does the work.

[Task, with the specific audience, situation and constraint]

Cover these sections, in this order:
1. [section]
2. [section]
3. [section]
4. [section]
5. [section]

For every section, include all three of:
- a direct answer in two sentences or fewer
- one worked example using [my specific situation]
- one failure mode: what it looks like when this goes wrong, and the
  first sign you would notice

Then close with [a table / checklist / decision tree].

Do not write an introduction. Do not summarise at the end. Do not
restate the question. If a section does not apply to my situation,
say so in one line and move on rather than padding it.

The three "do not" lines are not stylistic. Preamble and summary are exactly what a model produces when it has run out of specific things to say, which makes them the load-bearing filler in most over-long answers. Banning them forces the required blocks to carry the whole response.

A filled-in version, so you can see the density:

I run a 40-seat dental practice in Manchester. We currently book
appointments by phone only, with two receptionists, and we lose
roughly 30 no-shows a month. I am evaluating whether to add online
booking.

Cover these sections, in this order:
1. What online booking actually changes about no-show rates
2. What it changes about the receptionists' workload, hour by hour
3. Integration with existing practice management software
4. What patients over 65 do when you move booking online
5. How I would measure, at 90 days, whether it worked

For every section, include all three of:
- a direct answer in two sentences or fewer
- one worked example using a 40-seat practice with two receptionists
  and 30 monthly no-shows
- one failure mode: what it looks like when this goes wrong, and the
  first sign I would notice

Then close with a 90-day decision table: metric, baseline, target,
and what I do if the target is missed.

Do not write an introduction. Do not summarise at the end. If a
section does not apply to a practice this size, say so in one line.

Count the requirements: five sections, three elements each, plus a four-column table. Sixteen things. There is no version of that answer that fits in six paragraphs, and you never mentioned a word count. If you want the general framework this pattern sits inside, how to write better ChatGPT prompts covers the components. Deciding whether the closing artifact should be a table, a checklist or prose is its own decision, and how to choose an output format walks through it.

This is also, more or less, what OpenAI tells developers to do. Its current guidance for reasoning-capable models says they work best when you give them "a clear goal, strong constraints, and an explicit output contract without prescribing every intermediate step." Output contract is the phrase to hold onto. A word count is not a contract, because neither side can tell whether it was met.

Should I ask for one section at a time?

Past roughly 1,500 words, yes. Below that, one turn is usually fine and faster.

The reason is not a hard limit. It is that a single enormous request spends one budget on nine jobs, and the model allocates that budget by feel. Sections one and two come out generous, section seven comes out as three bullets, and you cannot tell it to rebalance without regenerating everything.

Serialising fixes that. Two turns of setup, then one turn per section:

Turn 1 — lock the outline
"Before writing anything, give me the outline only: the five section
headings, plus one line under each saying what that section will
argue. Do not write the sections."

Turn 2 — approve or edit
"Good, but swap sections 3 and 4, and section 5 should be about
measurement rather than tooling. Confirm the revised outline."

Turn 3 onward — one section per turn
"Now write section 1 only, to the spec below. Do not preview
section 2, and do not recap the outline.
[paste the three required elements]"

Three practical wins from this. Each section gets a full response budget for a much smaller job, so nothing gets rationed. You catch drift after section two rather than after section nine. And because no single response is near any ceiling, nothing gets truncated mid-sentence.

The cost is real: more turns, more of your attention, and a risk that the voice wanders between sections. Fix the last one by pasting a two-line style note into each turn rather than trusting the model to remember it from turn one. If you find yourself pasting the same spec repeatedly, that is exactly the case for saving it as a reusable prompt template with the variable parts marked, rather than retyping it.

What do I say instead of "continue"?

Quote the last complete sentence back, then tell it to resume from there.

"Continue" is the default thing everyone types and the worst available option, because it gives the model no anchor. It has to infer where it stopped from a conversation history it may have partially lost, and the two failure modes are predictable: it repeats the last paragraph in slightly different words, or it skips ahead and you lose a chunk you never see.

An anchored continuation removes the guess entirely.

Resume writing from exactly this point. The last complete sentence
you wrote was:

"The 90-day review should compare no-show rate against the pre-launch
baseline, not against the industry average."

Continue from the next sentence. Do not restate anything above.
Do not summarise. You still owe me sections 4 and 5, each with the
three required elements.

Three things are doing work there. The quoted sentence is an unambiguous cursor. "Do not restate anything above" blocks the re-summarising reflex, which is the model's default recovery behaviour when it is unsure. And naming what is still outstanding restores the contract, which is the part that usually gets dropped when a response is cut off.

Does more reasoning make the answer longer?

No. In the API it can make the visible answer shorter, and in the worst case remove it entirely.

This is the single most useful thing to understand about long outputs, and almost nobody writes it up. Reasoning models generate invisible tokens to think with before they generate the tokens you read. OpenAI bills those reasoning tokens as output tokens, and max_output_tokens caps everything the model generates: reasoning, visible text, and non-visible formatting tokens that never appear in the message content.

Which means thinking and writing compete for one budget. OpenAI's documentation states the consequence directly: if generation hits the limit, you get a response with a status of incomplete, and "this might occur before any visible output tokens are produced, meaning you could incur costs for input and reasoning tokens without receiving a visible response." Its remedy is a floor, not a ceiling. Reserve at least 25,000 tokens for reasoning and output combined when you start, then tune down once you know what your prompts actually consume. The token-counting guide adds the rule of thumb: leave headroom in these limits when you need a specific amount of visible output.

That number is worth staring at, because it is not the same shape as the context window next to it. Older models are tighter still: GPT-4.1 publishes 32,768 max output tokens against a context window of over a million. Room to read is not room to write. If you want the full parameter picture across providers, we keep the LLM parameter cheat sheet as a single page.

In the ChatGPT app you do not set token budgets, but you do choose an effort level, and since June 10, 2026 that lives in the model picker as Instant, Medium and High, with Extra High, Pro Standard and Pro Extended restricted to Pro plans. Moving that slider up buys you better reasoning. It does not buy you more words. If you want both, raise the effort and specify the content; the effort setting alone will give you a more considered answer of roughly the same length.

OpenAI's own migration guidance makes the same point from the developer side, and it is a good habit to borrow: before increasing reasoning effort, check whether the prompt is missing a success criterion or a verification loop. Most of the time the prompt is the problem and the dial is not.

What if the answer is long but still thin?

Then you have a padding problem, not a length problem, and the fix is a second pass rather than a bigger first one.

Models are better at deepening a draft than at producing depth on the first try, because the draft gives them something concrete to interrogate. Three prompts that work on an answer you already have:

1. Find the weak claim
"Which claim in what you just wrote is the least supported? Quote it,
say what evidence would be needed to support it, and rewrite that
paragraph with the evidence or with an honest caveat."

2. Expand one section only
"Section 3 is thinner than the others. Rewrite section 3 alone, to
double its substance: add one more worked example and one edge case
this advice does not handle. Leave every other section untouched."

3. Strip and replace
"Delete every sentence that restates something said elsewhere or
that could appear in any article on this topic. Tell me how many
sentences you removed, then replace that volume with specifics about
my situation."

The third one is the interesting one. It holds length roughly constant while raising the information density, which is the actual goal that "make it longer" was standing in for.

And sometimes the honest answer is that you do not want a longer response at all. Often, a request for depth is really a request for the model to stop being vague, which is a different fix and often a shorter one. Our companion piece on getting shorter, sharper answers is the mirror of this page, and the technique is the same in reverse: constrain the content, not the size.

Where this gets tedious, and what we built

Everything above works. It is also, written out by hand, a lot of typing for a single question, and that is the honest catch. A full depth specification runs well over a hundred words before you have said anything about your actual problem, and most people will write it once, get a good answer, and then not write it again on Tuesday.

That repetition is the problem Prompt Architects exists to remove. Paste a plain request and the enhancer restructures it into Role, Task, Format, Constraints and Tone, which is the same skeleton as the specification above, in under two seconds. Save the ones that work to your Prompt Library, mark the situation-specific parts as variables, and the fifteen-block spec becomes something you fill in rather than something you compose. It works inside ChatGPT, Claude, Gemini and the other platforms our extension supports, so the same saved spec travels with you.

What it does not do, and I would rather say so here than have you discover it: it does not set text.verbosity for you, because the consumer ChatGPT app has no such control to set. It does not raise your reasoning level. It structures the prompt, which is the lever you actually have. There is a free plan if you want to test that claim against your own prompts before paying anything.