Introduction

An incomplete model response is usually a workflow problem rather than a model defect. In current OpenAI APIs, the practical approach is to detect why generation stopped, persist the partial output you already received, and then continue from that point with either the Responses API's stateful chaining features or an explicit continuation prompt.

First Identify Why the Response Stopped

Do not treat every truncated output as the same failure. A response may stop because:

• the model hit an output token limit
• the client timed out or the network dropped during streaming
• your own application cancelled the request
• the model refused or otherwise ended for a non-length reason

In the current OpenAI platform, the Responses API exposes response status details and supports chaining via previous_response_id. Older Chat Completions flows typically require checking finish_reason, especially length, and then continuing manually with more conversation context.

Continue a Response With the Responses API

If you are using the newer Responses API, keep the previous response ID and continue from it rather than reconstructing the conversation from scratch each time.

1from openai import OpenAI
2
3client = OpenAI()
4
5response = client.responses.create(
6    model="gpt-5",
7    input="Write a long step-by-step guide to optimistic locking.",
8    max_output_tokens=250,
9    store=True,
10)
11
12text = response.output_text
13print(text)
14
15if response.status == "incomplete":
16    next_response = client.responses.create(
17        model="gpt-5",
18        previous_response_id=response.id,
19        input="Continue from the exact next sentence. Do not repeat prior text.",
20        max_output_tokens=250,
21        store=True,
22    )
23
24    text += next_response.output_text
25    print(text)

This is the cleanest pattern because the API can continue from the stored prior response rather than forcing you to replay a long transcript on every retry.

Recover Cleanly From Streaming Interruptions

If you are streaming output to the user, persist each chunk as it arrives. That way a connection drop does not erase everything the model already produced.

1from openai import OpenAI
2
3client = OpenAI()
4chunks = []
5
6with client.responses.stream(
7    model="gpt-5",
8    input="Explain event sourcing in depth.",
9    max_output_tokens=300,
10) as stream:
11    for event in stream:
12        if event.type == "response.output_text.delta":
13            chunks.append(event.delta)
14            print(event.delta, end="", flush=True)
15
16text_so_far = "".join(chunks)
17print("\n---\nSaved partial output length:", len(text_so_far))

If the stream breaks, store text_so_far and either continue from the saved response ID or, if you are running statelessly, send the saved partial output back with a continuation instruction.

Continuation Without Stored Server State

Sometimes you do not want server-side response state, or you are bridging older code that uses Chat Completions. In that case, include the partial answer in context and ask the model to continue without repeating it.

1from openai import OpenAI
2
3client = OpenAI()
4partial = "Optimistic locking uses a version column to detect conflicting updates."
5
6response = client.chat.completions.create(
7    model="gpt-4o-mini",
8    messages=[
9        {"role": "system", "content": "Continue precisely without repeating prior text."},
10        {"role": "user", "content": "Finish this explanation."},
11        {"role": "assistant", "content": partial},
12        {"role": "user", "content": "Continue from the next sentence only."},
13    ],
14    max_tokens=200,
15)
16
17print(partial + response.choices[0].message.content)

In Chat Completions, inspect finish_reason. If it is length, that usually means the model reached the configured output limit and a continuation call is appropriate.

Prevent Duplicate Text When You Merge Chunks

Even with a careful prompt, continuation calls can overlap slightly with the previous chunk. Add a lightweight overlap merge step before presenting the final answer.

1def merge_with_overlap(existing: str, new_chunk: str, max_overlap: int = 150) -> str:
2    overlap = min(len(existing), len(new_chunk), max_overlap)
3    for size in range(overlap, 0, -1):
4        if existing.endswith(new_chunk[:size]):
5            return existing + new_chunk[size:]
6    return existing + new_chunk
7
8
9first = "The database increments the version field on every successful update."
10second = "version field on every successful update. A stale writer then fails."
11print(merge_with_overlap(first, second))

This avoids duplicated prefixes and makes the output look intentional instead of patched together.

Common Pitfalls

One common mistake is retrying the exact same request after a partial output without giving the model any continuation context. That often produces repeated text rather than a true continuation.

Another issue is assuming every stop means truncation. A refusal, timeout, cancellation, and token limit are operationally different events and should not be handled by one blind retry path.

Developers also often keep continuation loops unbounded. Put hard limits on rounds, total tokens, and elapsed time so a rare failure mode does not become a runaway cost problem.

Finally, do not discard partial output during streaming. Persisting chunks as they arrive is one of the simplest reliability improvements you can make.

Summary

• Detect why the response stopped before deciding how to continue it.
• With the Responses API, prefer chaining with previous_response_id when possible.
• In older stateless flows, send the partial answer back with an explicit continuation instruction.
• Merge resumed chunks carefully to avoid duplicate text.
• Put continuation logic behind clear limits for retries, rounds, and total output size.