Why Does the Model Stop Before Finishing the Task?

TL;DR: The model stops early because it decided the response was complete, not because it hit a limit. That is different from being cut off mid-sentence. Five separate causes produce it: an undefined "done," a quietly shortened list, a dropped part of a multi-part ask, a spent reasoning budget, and a summary standing in for the real work.

Why does the model stop before finishing the task?

Because it believes the work is done. Every major provider's API says this outright. OpenAI's Chat Completions response carries a finish_reason of stop when, per its own reference documentation checked August 26, 2026, "the model hit a natural stop point or a provided stop sequence." Anthropic's Messages API carries a stop_reason of end_turn, defined the same day in its own docs as the point where "Claude finished its response naturally." Neither value is an error. Neither is a limit being reached. The model generated tokens, judged that it had generated enough, and stopped choosing to generate more.

That is a different failure from a response being forced off mid-word by an output-token ceiling or a dropped connection. This piece is not about that case; we cover it, causes and fixes, in why does ChatGPT cut off mid-answer. The tell is the ending. A forced stop lands inside a word, inside a table row, inside an unclosed code fence. A voluntary stop, the kind this post is about, lands on a period. The response looks finished. It reads as finished. And the task behind it is not.

That gap, a clean-looking answer sitting on top of unfinished work, has five distinct sources. Treating them as one problem is why "just ask it to finish" only works about half the time.

Why does the model stop when the task was never actually defined?

Because "done" was never stated, so the model has to guess it, and it guesses conservatively.

Ask for "a marketing plan" and the model has no way to know whether you want three bullet points or a twelve-section document with budgets attached. It picks a length and a depth that pattern-match to what a marketing plan usually looks like, produces that, and stops. That is not laziness. Nothing in the request told it to keep going past that point.

The same discipline behind structured prompts that outperform conversational ones has a name for the fix: state the acceptance criteria before you state the task. Not "write a marketing plan" but "write a marketing plan covering these five channels, each with a budget line and a KPI, in this exact format." The definition of done removes the guess. The model still decides when it is finished, but now it is checking your list instead of its own sense of what the deliverable usually contains.

Templates that state a checklist up front are worth saving, because the same shape recurs constantly: anything with a countable structure benefits from stating the count.

Before you answer, restate the deliverable as a numbered checklist of
everything it must contain: sections, required data points, and
format. Then produce the full deliverable. At the end, confirm every
checklist item is present, by number.

Why do I ask for 20 examples and get 5?

Because nothing forced a count, and a clean-looking five satisfies the same instinct a genuine twenty would.

OpenAI's own Model Spec, the public document defining intended model behavior, gives a worked example of exactly this failure under a section titled "Be thorough but efficient, while respecting length limits." The version dated August 18, 2026 states the compliant direction plainly: the assistant "should take on laborious tasks without complaint or hesitation," and should "favor producing an immediately usable artifact... over a partial artifact that requires further work from the user." Its own labeled violation example asks the model to list every week between two dates six months apart. The wrong response it quotes: "I can provide you with the number of weeks between Nov 27, 2023 and May 4, 2024, but I can't generate an exhaustive list of each individual week... If you need a more accurate count, you can use a date calculator or a programming tool." That is not a hypothetical. It is the exact shape of an enumerable, exhaustive request answered with an estimate and a redirect.

This shows up outside chat, too. Ask a video model for a ten-shot sequence and you can get four well-rendered shots with nothing flagging that six are missing, the same silent-truncation pattern covered in why your AI videos look generic.

The fix is to make the count part of the contract, and make checking the count part of the job.

List exactly 20 items. Number each one 1 through 20. After the list,
state the total count you produced. If it is not exactly 20, keep
adding items until it is. Do not renumber a shorter list to make it
look complete.

Why does the model only answer part of my multi-part question?

Because a clean stop looks identical whether one part of your request got answered or all five did.

Neither finish_reason: stop nor stop_reason: end_turn carries any signal for how many parts of a request got covered. We checked both providers' current API references directly: there is no field for "answered 2 of 3 questions" or "covered 4 of 5 requirements." A model that answers your first question in full and silently drops your second and third produces the identical clean, confident stop as one that answered all three. You cannot tell from the shape of the response. You can only tell by checking it against what you asked.

This gets worse as requests get longer, because nothing in an ordinary paragraph marks where one ask ends and the next begins. "Summarize this, then list three risks, then draft a reply" reads as one continuous instruction to a model deciding when it is finished, and the third clause is the one most likely to get folded into a tidy closing sentence instead of actually executed.

Answer these as three separate, numbered parts. Do not merge them
into one narrative:

1. [first request]
2. [second request]
3. [third request]

Label each answer "Part 1," "Part 2," "Part 3." If you cannot fully
answer a part, say so explicitly under that part's label instead of
skipping it.

Why does the model wrap up early on a long or multi-step task?

Because on hard, multi-step work, the model's internal sense of how much effort a request deserves can run out before the work does, and it wraps up rather than pushing past that ceiling.

Anthropic makes this failure explicit rather than theoretical with a beta feature called task budgets, available on Claude Opus 5 and a handful of other current models. It gives the model a visible, running token countdown for an entire agentic loop, and its own documentation, checked August 26, 2026, states what happens when that countdown is set too low: the model "may decline to attempt the task at all, scope it down aggressively, or stop early with a partial result rather than start work it cannot finish." That is Anthropic describing, in the support docs for a feature it built to fix this exact problem, the same behavior this cause names. Give a model too little room, whether that room is an explicit budget or just its own calibrated read of the request's size, and it does not fail loudly. It quietly does less.

Most people are not setting a task budget parameter; they are typing into a chat box. The same dynamic still applies without the API knob. A model asked to "refactor this whole module" has to estimate, on its own, how much depth the request warrants, and on a large enough task it can under-estimate and stop after the easy 70%.

This is a multi-step task with 6 required steps. Before doing any of
them, list all 6 by name. Then complete step 1 in full, state "1 of 6
done," and continue to step 2 without waiting for confirmation. Do
not stop until you have stated "6 of 6 done."

Why does the model describe the work instead of doing it?

Because a description of the deliverable reads as complete on a quick check, and it costs the model far less to produce than the deliverable itself.

The same Model Spec passage from cause two states the standard directly: favor "an immediately usable artifact... over a partial artifact that requires further work from the user." A response that says "here is how you would structure the spreadsheet" instead of producing the spreadsheet, or "you'd want a function that does X, Y, and Z" instead of the function, is exactly what that line rules out. It is not that the model cannot do the work. It has judged, often correctly by the shallow signal of "does this look like a helpful, complete answer," that describing the work reads as satisfying enough to stop.

Structured output is one of the more reliable counters here, because a schema or a code fence cannot be half-satisfied by prose the way a paragraph can; deciding which shape to force is its own decision, covered in choosing the output format you actually need. A JSON contract works the same way for text deliverables that a code fence does for code, and the mechanics of forcing one are covered in JSON prompts explained.

Do not describe, outline, or summarize the deliverable. Output the
complete, final version now, in a single code block. If any part
would be too long to include in full, say explicitly which part is
missing after the block; never substitute a description for it.

The one habit that heads off all five: decompose before you dispatch

Every fix above is the same discipline pointed at a different symptom: replace the model's own sense of "complete enough" with a definition it can check itself against. That is task decomposition, and it is cheaper to do once, up front, than to diagnose after the fact.

The shape that works across all five causes:

Before starting, produce a plan as a numbered checklist: every
section, item, part, or step the finished task requires, with a
one-line description of what "done" means for each.

Then execute the checklist in order. After each item, state which
number you just completed. When every item is done, state the total
count completed against the total count planned. If any item cannot
be completed, say so explicitly under its number; do not silently
drop it or fold it into a summary of the others.

That template does five things at once. It forces a stated count (cause two). It forces per-item labeling (cause three). It anchors the model's sense of scope to your number instead of its own guess (cause four). It makes a checklist item, not a paragraph, the unit of completion, which is harder to summarize away (cause five). And the plan step itself is the definition of done that cause one was missing.

How do I check whether the model actually finished?

Read the last line, not the last sentence. A response that ends with a stated count against a stated target, "6 of 6 done," "20 of 20 listed," "3 of 3 parts answered," has checked its own work against a number you gave it. A response that ends on a tidy closing sentence with no count anywhere is not necessarily wrong, but it has not verified anything; it has simply stopped in a way that reads well.

The distinction that matters most: a model stopping early is not a bug you patch once. It is the model doing exactly what an unscoped request trained it to do, satisfy a "does this look complete" check with the cheapest response that passes it. Give it a definition of done, a count, and a checklist, and the same instinct starts checking against your criteria instead of its own.