Why Does ChatGPT Cut Off Mid-Answer?

TL;DR: ChatGPT cuts off mid-answer for five distinct reasons: the reply hit the model's output-token ceiling, the conversation filled the context window, the streaming connection dropped, the client failed to render the whole message, or your prompt implied a shorter deliverable. Each has a different fix. Diagnose first, retry second.

Why does ChatGPT cut off mid-answer?

Because generation stopped for one of five reasons, and only one of them is a length limit. The other four get misdiagnosed as a length limit constantly, which is why "just type continue" works about half the time and quietly wastes the other half.

Most articles on this topic collapse everything into "you hit the token limit". That is wrong often enough to matter. A dropped websocket and a full context window produce a similar-looking stump of text, but the fixes point in opposite directions: one wants a retry, the other wants a new chat.

Here is the triage. Spend thirty seconds here before you touch the keyboard.

The single most useful diagnostic is the last character. A model that finished on its own ends on punctuation. If the answer ends mid-word, inside a table row, or with an unclosed code fence, generation was interrupted rather than concluded.

Cause 1: the reply hit the model's output-token ceiling

Every model has a maximum number of tokens it can produce in a single response. Cross it and generation halts wherever it happens to be, including mid-word.

OpenAI publishes these figures for API models. As of August 26, 2026, its model reference lists GPT-5.6 Sol, GPT-5.6 Terra and GPT-5.6 Luna each with a 1,050,000 context window and 128,000 max output tokens. The older GPT-5 page lists a 400,000 context window and the same 128,000 max output tokens.

Now the part almost every listicle gets wrong.

Those numbers describe the API, not the ChatGPT apps. OpenAI does not publish a per-message output cap for ChatGPT on web, iOS or Android. Its own help article on controlling response length points developers to the model documentation for output caps, and that documentation is written for API model IDs. The consumer product routes between models, applies its own settings, and shares the window with system instructions and memory. Treat any specific "ChatGPT maxes out at N words" figure you see quoted as unsourced unless it links to an OpenAI page.

What we can say with confidence: the ceiling in ChatGPT is meaningfully lower than 128,000 tokens, and it is lower still on Free.

Two practical consequences.

Code hits the ceiling faster than prose. OpenAI's tokenization guidance puts one token at roughly four characters, or about three-quarters of a word, with 100 tokens landing near 75 words. Indentation, brackets, and long identifiers push code well past that average. A large file burns budget several times faster than the same line count of English.

Reasoning models can burn the budget before you see anything. OpenAI's reasoning guide states that reasoning tokens "still occupy space in the model's context window and are billed as output tokens", and warns that hitting the limit "might occur before any visible output tokens are produced". A hard thinking task can therefore return almost nothing, having spent the entire response budget on invisible work.

The fix: ask for less per turn. Not less overall, less per turn. Section-by-section generation is covered further down and it is the only reliable answer to this cause.

Cause 2: the conversation filled the context window

The context window is the total budget for a single request: everything you sent, everything the model has already said in that chat, plus everything it is about to generate. It is shared. A long conversation eats the room your answer needs.

OpenAI publishes per-plan context windows on the ChatGPT pricing page. Checked August 26, 2026:

The same page carries a footnote that explains the symptom better than any third-party guide:

ChatGPT manages a shared context window to understand your request, track the conversation, retrieve relevant information, and generate responses. The portion available for user input is smaller than the total window, as space is also used for system instructions (including tools and personality), memories (if enabled), and internal processing (reviewing information, reasoning, and response generation).

Read the parenthetical at the end. Response generation shares the window with your input, the chat history, and memory. Which is exactly why the twentieth message in a thread gets truncated when the second one did not.

On the API side, OpenAI's conversation state guide is blunter: "Tokens generated in excess of the context window limit may be truncated in API responses."

The tell for this cause is a cluster of symptoms rather than a single one. Answers stop early and get vaguer. The model forgets a constraint you set twenty messages ago. It reintroduces something it already covered. That combination is context pressure, not a length ceiling.

The fix: start a new chat and bring only what matters. Not the transcript. A short brief: the goal, the constraints, the two or three facts the model actually needs, and the last good output. OpenAI's own troubleshooting article recommends starting a new chat "if the conversation is long or has many turns".

This is the single highest-value habit in this post, and it is the one people resist most, because the old thread feels like progress. It is not. It is ballast.

Cause 3: the connection dropped while the answer was streaming

ChatGPT streams tokens to your browser as they are generated. If that stream breaks, you keep whatever arrived before the break and lose the rest. Nothing was over any limit. The pipe closed.

OpenAI documents this as a connection-level failure with its own error strings. Its troubleshooting article lists "A network error occurred." and "An error occurred while connecting to the websocket." as signs that "your device is unable to establish a reliable connection to our servers", with fixes including disabling VPNs or proxies, trying a different browser or incognito window, and switching network or device.

The corporate-network version is more specific, and it is the one that traps people at work. OpenAI's network recommendations article states that if an organisation blocks websocket traffic by default, "some features may stall, disconnect, or fail to stream updates correctly". It asks admins to allow websocket traffic over TCP port 443 to wss://ws.chatgpt.com for conversation updates, and adds a line worth quoting to your IT team verbatim:

If sessions connect but later stall or disconnect, check idle timeout and maximum frame or message-size policies for WebSocket traffic.

Idle timeouts and message-size caps are precisely the settings that kill long answers and leave short ones alone. If your truncation is worse on the office wifi than at home, and worse for long answers than short ones, that sentence is your diagnosis.

The fix: retry first, since transient drops are common. If it repeats, test on a different network before blaming the prompt. Check status.openai.com. If it only happens on one network, send your IT team the websocket paragraph above.

Cause 4: the answer finished, but your client did not show all of it

Sometimes the model produced the whole thing and the interface let you down. Long rendered tables, deeply nested lists, very large code blocks, and mid-stream tab switches can all leave you looking at less than arrived.

I want to be straight about the evidence here: OpenAI does not document client-side render truncation as a known behaviour, and I could not find a primary source describing it. What I can give you is a reliable test.

Copy the entire message to your clipboard and paste it into a plain text editor. If more text appears than the screen showed, the generation was complete and the render was not. Reloading the conversation, or opening it on another device, usually resolves it. OpenAI's general guidance for a stuck or misbehaving session covers the same ground: hard refresh, incognito window with extensions disabled, different browser or device.

Cause 5: your prompt told ChatGPT to be brief without you noticing

This is the cause nobody suspects, and it is more common than the network one.

Models take structural cues from the shape of your request. Ask for "a quick overview" and you have set a length. Ask for "the main points" and you have capped the depth. Say "briefly" anywhere in a 200-word prompt and it colours the entire answer. The output then looks tidy and complete, and it is simply too shallow to be useful. That is not truncation. That is compliance.

The reverse is also true, and OpenAI states it plainly in its own guidance on controlling response length: "There is no 'minimum tokens' setting. If you need a minimum length, specify it in your prompt." There is no floor. Only your instructions create one.

That same page recommends asking for the exact length or shape you want, with examples like "List exactly five options" and "Write a 50-word summary". On the API, GPT-5 models expose a verbosity setting of low, medium or high, which OpenAI notes "influences detail level but not hard limits". In the consumer app you get the same lever through wording alone.

The fix: give every long request an explicit length contract, and tell the model what to do when the answer will not fit.

Length contract for this answer:
- Target: about 600 words. Hard ceiling: 800 words.
- If the full answer will not fit in one message, do NOT compress it. Instead:
  1. Write the outline only,
  2. Write section 1 in full,
  3. End with "NEXT: section 2" and stop.
- Never truncate mid-sentence to fit. Never summarise to fit.

That last pair of rules matters more than the numbers. Without them, a model that senses it is running short will compress, and you get a thin answer instead of a clearly incomplete one. Incomplete is better. Incomplete is diagnosable.

This is also the cause a prompt enhancer actually addresses. Turning "write me a launch plan" into an instruction with an explicit Role, Task, Format and Constraints block removes the ambiguity the model was resolving in favour of brevity. It is the same reason structured prompts beat conversational ones generally, which we cover in how to write better ChatGPT prompts and in why your ChatGPT answers are bad.

How do I make ChatGPT continue where it left off?

By giving it an anchor. "Continue" gives it none, so it guesses, and the cheapest guess is to restart the current section with a short recap. You end up with overlap, renumbered lists, and a second partial answer stitched badly to the first.

Paste back the tail of what you received and forbid restatement.

Your last message stopped mid-way. Resume from exactly this point,
continuing the same sentence if it was left incomplete:

"...<paste the final 15-20 words you actually received>"

Rules:
- Do not restate, summarise, or re-introduce anything already written.
- Do not open with "Continuing from where I left off" or any preamble.
- Start with the very next word.
- Keep the same heading levels, numbering, and formatting.
- When you reach a natural section end, stop and write [SECTION END].

For code, be more specific again, because a repeated import block or a duplicated function signature is worse than no continuation at all.

The code block you produced was truncated. Output the remainder only.

Context:
- File: <filename>
- The last complete line I received was:
  `<paste the last full line, exactly>`

Rules:
- Resume from the next line. Do not repeat any line at or above that one.
- Do not re-emit imports, the class declaration, or the function signature.
- Return one fenced block with the same language tag.
- Finish with a comment naming the last line you wrote.

Two things make these work. The verbatim tail removes the guesswork about position. The explicit ban on preambles removes the recap that causes the overlap. Save both as reusable snippets. They are the sort of thing you need weekly and rewrite badly from memory every time.

The structural fix: ask for one section at a time

Every technique above is a recovery. This one prevents the problem.

Stop asking for whole deliverables in a single message. A 3,000-word guide, a full component, a complete report: each of those is a request for an output near or past the practical ceiling, in a thread that is already carrying history. You are asking to be truncated.

Ask for an outline, then request sections individually. Each message stays comfortably inside every limit, you review as you go, and a failure costs you one section rather than an hour.

We are producing <deliverable> together, one section at a time.

Step 1. Output ONLY the outline: numbered section titles, each with a
one-line purpose and a target word count. Then stop and wait for me.

Step 2. When I reply with a section number, write ONLY that section, in
full, at its target length. Then stop and wait. Do not preview the next
section, do not summarise previous ones, do not write ahead.

Standing rules:
- Never write more than one section per message.
- If a section would exceed its target by more than 25%, split it into
  <n>a and <n>b, tell me, and write <n>a only.
- If I say "next", write the next unwritten section.

The word-count target per section is doing real work. It converts a vague "write section 3" into a bounded request, which is the cause-5 fix and the cause-1 fix at the same time. Deciding what shape each section should take is its own skill, and choosing the output format you actually need covers it properly.

What this looks like in the API

If you are building on the API rather than typing into ChatGPT, truncation stops being a guessing game, because the response tells you.

Set max_output_tokens to cap generation. If the cap is reached, the response comes back with a status of incomplete and incomplete_details.reason set to max_output_tokens. The only other documented reason value is content_filter.

resp = client.responses.create(
    model="gpt-5.6-sol",   # check the current model ID in OpenAI's model reference
    input=prompt,
    max_output_tokens=8000,
)

if resp.status == "incomplete" and resp.incomplete_details.reason == "max_output_tokens":
    # Partial text may still be present in resp.output_text.
    # Resume from the tail rather than regenerating the whole response.
    ...

Three notes worth carrying into production. Reasoning tokens count toward max_output_tokens, so a tight cap on a reasoning model can return incomplete with nothing visible in it; OpenAI recommends reserving at least 25,000 tokens for reasoning and outputs when you start experimenting with these models. Input, output and reasoning tokens all count against the same context window total. And max_output_tokens is a ceiling, never a floor, for the same reason there is no minimum-tokens setting in the app.

For how max_output_tokens compares with max_tokens, max_completion_tokens and every other provider's version of the same idea, we keep a one-page reference in the LLM parameter cheat sheet. Sampling parameters are a separate axis and they do not cause truncation, though they are routinely blamed for it; temperature, top-p and top-k explained covers what they actually control.

The one-line version

If the text ends mid-word with no error, you hit a length limit: resume from the tail. If answers are also getting vaguer, your context window is full: start a new chat. If there is an error banner or a dead spinner, it is the connection: retry, then test another network. If copying the message gives you more text than the screen did, it rendered badly: reload. And if the answer looks complete but shallow, nothing was cut off at all. You asked for less than you meant to.