Why Your AI Automation's Answer Gets Cut Off

Your AI automation's answer gets cut off because the response hit the model's maximum output token limit, a cap on how much text the model can generate in a single reply. That cap is separate from, and much smaller than, the context window that governs how much you can feed in. The failure is silent: the API returns a normal HTTP 200 with a body that looks fine until you read it. The only signal that the answer was truncated lives in the stop reason field, which reads max_tokens on Anthropic and length on OpenAI, and most no-code platforms never surface it. So the fix is not a better prompt and not blindly raising the number. It is to read that stop reason, treat a truncated run as a failure, and size the output budget to the task.

Most advice on this problem tells you to increase the limit until the answer fits. That works until an unusually long input shows up on a busy Tuesday and quietly saves half a summary to your CRM. The durable fix is to catch the truncation, not to guess a number big enough to never hit it.

The output limit is not the context window

These are two different limits and operators almost always blame the wrong one.

The context window is the total token budget the model can hold at once, spanning your input and its generated output together. Modern models advertise large ones, 200,000 tokens and up, some past a million. That number is what lets you stuff a long contract or a big support thread into a single call.

The maximum output tokens is a separate cap on only the tokens the model generates back. As of mid-2026 those caps commonly sit far below the context window, often somewhere between 4,000 and 64,000 tokens depending on the model. Check your specific model's card, because the two numbers are not related and the output cap is the one that truncates you. A 90-page document fitting inside the context window does not mean the model can write a 90-page answer.

There is a platform difference worth knowing. On Anthropic's Messages API, max_tokens is a required parameter on every request, so if your automation template ships with a low default like 1,024, a long summary gets clipped and you did it to yourself. On OpenAI the parameter is optional and the naming has moved: max_tokens is deprecated in favor of max_completion_tokens on the chat completions API, and max_output_tokens on the Responses API and the newer models. Leaving it unset does not mean unlimited; it means a model-specific default you did not choose.

The failure is silent because the signal sits in a field you never read

When a model runs out of output budget, it does not throw an error. It returns success with a partial answer, and it tells you what happened in a metadata field next to the text.

On Anthropic, the response carries stop_reason. A healthy answer ends with end_turn. A truncated one ends with max_tokens. On OpenAI's chat completions API, the field is finish_reason, where stop is healthy and length means truncated. On the Responses API the response comes back with a status of incomplete and an incomplete_details.reason of max_output_tokens. In every case the HTTP status is 200.

Here is why it bites in automations specifically. A no-code builder maps the AI response to its text content and drops the rest of the payload. The stop reason is right there in the raw response, but the node hands your next step only the string. So the JSON that failed to parse, the note that ends mid-sentence, the list that came back three items short: none of them fire an error, because from the platform's point of view the call succeeded.

This is a different failure from two it gets confused with. It is not broken JSON from a formatting problem, where the model wraps valid output in prose or code fences; that call stops normally. And it is not a timeout, where the step never returns at all. Truncation returns, returns fast, and returns wrong.

What truncation looks like by output type

The same root cause shows up in different disguises depending on what the step was asked to produce. This is the table to keep in mind when a run looks off but nothing errored.

Output type	What truncation produces	Downstream effect
Free-text summary or note	Text stops mid-sentence, sometimes mid-word	A half-written summary saved as if complete
JSON object	Missing closing brace or quote	Parse error that reads like a formatting bug
List or array of records	List ends early, last items absent	Records silently dropped, counts look plausible
Short label or classification	Rarely truncates, output is tiny	Usually fine; not where you look first
Reasoning-model answer	Empty string with no visible text	Looks like the model returned nothing at all

The pattern to notice: the more open-ended the output, the more likely truncation is your problem, and the less likely it is to announce itself.

The reasoning-model trap: an empty answer with the budget spent on thinking

Reasoning models are where truncation gets genuinely strange. Models in the o-series, the GPT-5 family, and Claude with extended thinking spend internal reasoning tokens before they write any visible answer. Those reasoning tokens are not shown to you, but they are billed as output and they count against the same output budget you set.

Set the limit too low and the model can spend the entire budget reasoning and return with nothing visible, a stop reason of length, and an empty content field. It did not fail to understand the prompt. It ran out of room after the thinking and before the writing. OpenAI's own guidance is to reserve at least 25,000 tokens for reasoning plus output when you start experimenting, then tune down once you see how many reasoning tokens your prompts actually consume. That count is visible in the response's usage details.

The practical lesson: when a reasoning step "returns blank," check the output budget before you touch the prompt. We have watched teams rewrite a perfectly good prompt for an hour when the real fix was one number.

How to set the limit and catch truncation

Three moves turn a silent truncation into a caught error.

First, read the stop reason on every AI step. In an n8n Code or HTTP node, inspect the full response object and branch on response.stop_reason or choices[0].finish_reason. If it comes back max_tokens, length, or an incomplete status, treat the run as failed: do not save the partial output, route it to a retry or a human queue, and log it. This is the single highest-value change, because it converts an invisible data-quality problem into a visible failure you can act on. It belongs in the same family as the other silent failure modes worth guarding against.

Second, size the output budget to the task rather than to a template default. Look up your model's real maximum output cap, then set the limit above the longest answer the task legitimately needs, with headroom. For a fixed-shape extraction, that number is small and predictable. For a summary of variable-length input, budget for the worst case you actually see. For reasoning models, add the reasoning reserve on top.

Third, when a genuinely long output will not fit, do not raise the number to the ceiling. Split the work so each call stays well inside the cap. Summaries map-reduce cleanly: summarize sections, then summarize the summaries. Long lists paginate: ask for records in ranges and stitch them. This is the same discipline that governs running a long document through a model, applied to the output side instead of the input side. A call that never approaches its limit never truncates.

What to do next

Audit your AI steps for an unread stop reason. Pick the flow that produces the longest or most variable output, open its raw response, and confirm whether anything downstream checks stop_reason or finish_reason. If nothing does, add that one guard first, then work down the list. Most automations have this gap and most owners have never seen it, because the failure never sent an alert.

If you want a second set of eyes on where your AI steps can quietly return partial data, that is the kind of review we do when we build workflow automation systems. Tell us the flow and the model you are on and we will walk through where it can truncate.