Multi-Turn Continuation Request Prompt Template

This prompt is for production engineers and chat application developers who need to recover a truncated assistant response across multiple API calls. The core job-to-be-done is resuming generation when a model output is cut off by token limits (max_tokens), streaming interruptions, or early stopping, and you cannot simply increase the token budget. The ideal user is someone wiring a chat product into a backend where a single-turn response is insufficient for long-form reasoning, code generation, or document drafting. You need the continuation to preserve the original task context, prior reasoning steps, and output format without repeating content or losing coherence.

Use this prompt when you have a partial assistant message that was cut mid-sentence or mid-structure, and you must request the next part in a new API call. The required context includes the full conversation history up to the truncation point, the exact partial output that was cut off, and any schema or format constraints the original response was following. This prompt is not for repairing malformed JSON or fixing broken syntax—those are separate repair playbooks. It is also not a substitute for proper streaming reconnection logic at the transport layer; this is an application-level recovery pattern for when the model output itself is incomplete.

Do not use this prompt when the truncation is caused by a stop sequence match rather than a token limit, as the model intentionally stopped and resuming may produce hallucinated content. Avoid it when the partial output is so short that no meaningful context exists for continuation—in those cases, retry the full generation with higher max_tokens. Also avoid this pattern in high-stakes regulated workflows without adding human review of the stitched output, because the model may change its reasoning or conclusions across turn boundaries. Before implementing, ensure your eval harness checks for turn-coherence (no contradiction with prior turns), non-repetition (no duplicated paragraphs), and format consistency (the continuation matches the original output structure).

This prompt template is designed to be injected as the next user message after an assistant response has been cut off by token limits, streaming interruptions, or model early-stopping. It instructs the model to resume from the exact truncation point while preserving the original task context, reasoning chain, output format, and tone. The template uses square-bracket placeholders that your application must populate before sending the request.

textCopy
You are continuing a response that was cut off mid-generation.

Below is the complete conversation history up to the truncation point, followed by the partial assistant response that needs to be completed.

[CONVERSATION_HISTORY]

--- PARTIAL RESPONSE (DO NOT REPEAT THIS CONTENT) ---
[PARTIAL_RESPONSE]
--- END PARTIAL RESPONSE ---

[OUTPUT_FORMAT_INSTRUCTIONS]

[CONSTRAINTS]

Instructions:
1. Read the conversation history and the partial response carefully.
2. Continue the partial response from the exact point where it was cut off.
3. Do not repeat, summarize, or paraphrase any content already present in the partial response.
4. Maintain the same tone, style, reasoning depth, and output format as the partial response.
5. If the partial response ends mid-word, mid-sentence, or mid-structure, complete that word, sentence, or structure naturally before continuing.
6. Do not add introductory phrases like "Continuing from where I left off..." or "Here is the rest of the response..."
7. If the original task required a specific output schema, ensure the continuation respects that schema.
8. If you cannot determine how to continue coherently, state that the continuation point is ambiguous and request clarification.

Begin continuation now:

Adapt the placeholders as follows: [CONVERSATION_HISTORY] should contain the full message array from the start of the session through the user's last request, formatted as turn-paired text or structured dialogue. [PARTIAL_RESPONSE] is the truncated assistant output exactly as received—preserve all whitespace, line breaks, and partial tokens. [OUTPUT_FORMAT_INSTRUCTIONS] should restate the original schema, format, or structure requirements (e.g., 'Continue the JSON object' or 'Complete the markdown table'). [CONSTRAINTS] is where you add domain-specific rules such as 'Do not introduce new entities not present in the conversation history' or 'Preserve citation IDs from the partial response.' For high-risk domains like healthcare or finance, add an explicit instruction to flag any unrecoverable ambiguity rather than guessing. After copying the template, test it against at least three truncation scenarios—mid-word, mid-JSON field, and mid-list-item—to verify that the model does not repeat content or drop context.

Integrating a multi-turn continuation request into a production system requires treating the prompt as a recoverable state machine, not a one-off text generation call. The application must detect truncation, capture the exact cut point, preserve the full conversation context, and issue a follow-up request that the model can stitch seamlessly into the prior turn. This harness is most critical in streaming chat interfaces, long-form content generation pipelines, and agent loops where a single max_tokens limit or network interruption can leave a response incomplete mid-sentence. The implementation must handle three distinct phases: truncation detection (identifying that the assistant's last message was cut off), context preservation (packaging the truncated message and conversation history into a continuation request), and output stitching (concatenating the original partial output with the continuation without duplication, overlap, or context loss).

The continuation request itself should be constructed as a new user turn that includes the full conversation history up to and including the truncated assistant message, followed by a structured continuation instruction. In practice, this means the application appends a system-level or user-level message containing the [PARTIAL_OUTPUT] and a clear directive such as 'Continue from exactly where you stopped. Do not repeat any prior content. Preserve the original format, tone, and structure.' The model's response should then be concatenated directly to the end of the truncated message. To prevent duplication, implement a boundary alignment check: compare the last ~20 tokens of the original partial output with the first ~20 tokens of the continuation response. If they overlap, strip the overlapping prefix from the continuation before stitching. For streaming implementations, buffer the continuation response and apply the alignment check before emitting the first new token to the user. Log every continuation event with the conversation_id, turn_index, truncation_point (character offset), continuation_prompt_tokens, and overlap_detected flag for observability.

Model choice and retry logic are critical failure-mode mitigations. Continuation requests are inherently fragile—models may hallucinate a restart, repeat content, change tone, or produce a continuation that contradicts the partial output. Use a model with strong instruction-following and long-context handling (e.g., Claude 3.5 Sonnet or GPT-4o) for continuation tasks. Implement a retry budget of 2 attempts with exponential backoff. On each retry, vary the continuation instruction slightly (e.g., add 'Begin your response with the exact next character after the cut-off point') to break repetition loops. If both retries fail the overlap or coherence checks, escalate to a fallback: either return the partial output with a [TRUNCATED] marker and an apology to the user, or route to a human reviewer if the content is high-stakes. For high-risk domains (legal, medical, financial), always require human review of stitched outputs before they reach end users. Wire the harness into your existing eval framework by running the continuation prompt against a golden dataset of known truncation cases and measuring stitch accuracy (exact character match at boundary), non-repetition rate, and format preservation score before deployment.