Output token limit: why replies truncate and how to continue

"The answer was truncated at the output token limit" and "output token limit reached" are the same event: this generation hit the ceiling. Decide whether continuing can work before raising limits or splitting the task.

Match the three messages first

UI, log, and repeated-continuation messages describe one class of problem.

The difference is whether continuing can work. The first two describe truncation; the third says continuing is ineffective, so the fix shifts from "click continue" to "split the task."

Do not treat them as three failures. Same cause, different surface; one diagnostic order applies.

Four causes of truncation

The limit being too small is only one cause.

1. Single-turn output hits the model maximum. The task itself is long; raising settings only approaches the model ceiling.
2. Compaction squeezed out output. After compaction, continue lacks context and the result is incoherent.
3. Output structure causes repetition. Step-by-step self-checks or repeated elaboration fill the budget; the same paragraph repeats.
4. Request parameters cap length. Session or model settings set a low limit; the cut appears at the same place every time.

Test in order: fixed cut point, compaction, output structure. A fixed cut suggests parameters; a drifting cut suggests the task.

The limit is a capability boundary, not a bug. Continuing extends time, not capacity.

Recovery one: continue

Continue is the cheapest step, with prerequisites.

1. Confirm the full output remains visible and was not collapsed or trimmed.
2. Send continue without restating the question; restating inflates context.
3. Check whether the continuation connects in tone, numbering, and structure.
4. If it repeats earlier text, context is incomplete; switch to splitting.

Continue suits "almost done." Missing a summary or a closing sentence is a good fit; missing half the content rarely connects.

Continue is not unlimited. Two failures mean the task exceeds single-turn capacity.

Recovery two: raise the limit

The limit can be raised, but know the ceiling.

1. Find the output limit in model or session settings; location varies by version.
2. Confirm the model's maximum output; setting more than the model supports is pointless.
3. Increase in small steps; maximum output competes with context and triggers compaction sooner.
4. Verify in a new session; old sessions may keep old parameters.
5. Record where the cut moved to confirm improvement.

Raising has diminishing returns. The model maximum is a hard boundary; configuration can approach it, not exceed it.

More output means less context. The window is shared; long output compresses history faster.

Recovery three: split the task

When a task exceeds a single turn, splitting is the only stable answer.

1. Split by structure: ask for an outline and section titles first, then generate one section per request.
2. Split by input: divide long material into segments, process each, then merge.
3. Split by stage: gather, draft, revise; each stage gets its own turn.
4. Keep interfaces: each segment uses fixed fields or numbering so merging is mechanical.

Splitting costs cohesion. Finer splits need more merging; splitting by structure usually merges better than splitting by word count.

Do not continue after splitting. Each segment is an independent task; continue mixes them.

Two truncated continuations

"Still truncated after two continuations" means the continue strategy failed.

1. Stop continuing and keep the existing output.
2. Decide whether the full text is needed; if only the conclusion matters, ask for a 500-word summary.
3. If full text is required, split by chapter and generate each.
4. Save each segment immediately so compaction cannot consume earlier text.
5. Merge and proofread separately at the end.

Two-stage generation is the compromise. Structure first, content second; structure uses little output, and content can be added in parts.

Do not keep clicking continue. Each attempt increases context pressure, making compaction more likely.

When it is not the output limit

Three cases look like truncation but are not.

1. Streaming connection dropped. Output stops without a limit message; check transport errors in logs.
2. The model stopped intentionally. It judged the task complete; check for a clean ending.
3. Compaction fired. Shortened output is a side effect; handle compaction first.

Check the message and log. A limit message means the limit; silence points to transport or compaction.

Do not assign all three to the limit. Wrong classification makes tuning and continuing useless.

Next steps

Read the message, then continue, tune, or split. For the single-error fix, read DeepSeek Harness output token limit reached. For compaction, read What to do when compaction fails. To separate transport failures, read This turn failed with transport failed.

Sources: DeepSeek Harness docs, dsh CLI README, deepseek-harness repository