Context Compression Retry Prompt Template

This playbook is for platform teams and AI engineers who need to recover from a failed model call caused by context window overflow or token limit exhaustion. Instead of truncating context arbitrarily and losing critical instructions or evidence, this prompt instructs the model to compress the original context into a dense, loss-minimizing summary before re-attempting the task. Use this when a primary task prompt fails with a token limit error and you need an automatic, structured retry that preserves task intent, key entities, and output format requirements.

This prompt is not a replacement for proper context budgeting or caching strategies. It is a recovery mechanism for when those strategies are exceeded. The ideal user is an AI engineer who has already instrumented their application to catch token limit errors (HTTP 400 with 'context_length_exceeded' or equivalent) and needs a deterministic retry path. The required context includes the original task prompt, the full input that caused the overflow, and the specific error message from the model provider. Do not use this prompt for routine context management—use it only when a primary call has already failed and you need to preserve as much task fidelity as possible in a compressed retry.

Before implementing, verify that your application can detect the specific error type and distinguish it from other failures like rate limits or content policy violations. The compression retry should be attempted exactly once before falling back to a different strategy, such as chunked processing or human escalation. If your task involves multiple tool calls, structured output schemas, or strict formatting requirements, ensure those constraints are explicitly preserved in the compression instruction. The biggest risk is losing a critical instruction during compression—always validate the retry output against the original task requirements.

This template instructs the model to first compress the original context into a structured, loss-minimizing summary, then re-execute the original task using only that compressed context. It is designed for platform teams who need to reduce token usage without sacrificing task performance, particularly when a prior attempt failed due to context overflow or when you need to checkpoint state before continuing. The prompt separates the compression step from the execution step so you can inspect the summary for fidelity before committing to the retry.

textCopy
You are a context compression and task re-execution engine. Your job is to recover from a prior failure caused by context overflow or token exhaustion.

## ORIGINAL TASK
[TASK_DESCRIPTION]

## ORIGINAL CONTEXT
[ORIGINAL_CONTEXT]

## ORIGINAL OUTPUT SCHEMA
[OUTPUT_SCHEMA]

## ORIGINAL CONSTRAINTS
[CONSTRAINTS]

## COMPRESSION RULES
1. Preserve all named entities, numbers, dates, and claim-evidence pairs exactly as they appear.
2. Preserve all task-critical instructions, constraints, and output format requirements.
3. Drop redundant, repetitive, or low-relevance content. If two passages convey the same fact, keep the most precise version.
4. Maintain the logical order of events, arguments, or steps.
5. Flag any information that appears contradictory or ambiguous with [CONFLICT] markers.
6. If the original context contains tool call results, preserve the tool name, arguments, and return values verbatim.

## COMPRESSION OUTPUT FORMAT
Produce a single COMPRESSED_CONTEXT block containing the dense summary. Then produce a FIDELITY_CHECK block listing:
- Preserved entities and their values
- Preserved constraints and whether they remain intact
- Any information that was dropped and the reason
- Any [CONFLICT] markers and their source passages

## RETRY INSTRUCTION
After producing the COMPRESSED_CONTEXT and FIDELITY_CHECK, re-execute the ORIGINAL TASK using only the COMPRESSED_CONTEXT. Produce the output in the ORIGINAL OUTPUT SCHEMA format. Do not reference the compression step in the final output.

## FAILURE MODE
If the COMPRESSED_CONTEXT still exceeds reasonable limits or critical information cannot be preserved, respond with:
{"status": "COMPRESSION_FAILED", "reason": "[EXPLANATION]", "preserved_elements": ["[LIST]"], "lost_elements": ["[LIST]"]}

Adaptation guidance: Replace [TASK_DESCRIPTION] with the exact original prompt or task instruction. [ORIGINAL_CONTEXT] should contain the full prior conversation, retrieved documents, tool outputs, or any other context that overflowed. [OUTPUT_SCHEMA] should specify the expected response format—JSON schema, markdown structure, or free text constraints. [CONSTRAINTS] should capture any hard rules like word limits, required sections, or prohibited content. For high-risk domains, add a human review gate between the FIDELITY_CHECK and the retry execution. If the original task involved tool calls, include [TOOLS] and [TOOL_RESULTS] placeholders in the ORIGINAL CONTEXT section. Test the compression output against a golden dataset of known entity-value pairs to verify nothing critical is dropped before deploying this into an automated retry loop.

The context compression retry prompt is not a standalone fix—it must be embedded in a harness that detects context overflow, triggers compression, validates the compressed output, and re-attempts the original task. The harness should intercept model errors or warnings indicating token limit exhaustion (e.g., context_length_exceeded, max_tokens truncation, or incomplete output markers) and route the failed request through a compression pipeline before retrying. Without this orchestration layer, the prompt alone cannot prevent silent truncation or repeated overflow loops.

Implement a retry budget to prevent infinite compression cycles. A typical configuration allows up to 3 compression attempts, each reducing context by a target percentage (e.g., 40% per pass). After each compression, validate the compressed summary against a fidelity checklist: confirm that named entities, numerical values, dates, and explicit constraints from the original context are preserved. Use a lightweight eval prompt or deterministic checks (e.g., regex for key fields) to flag missing critical information. If fidelity drops below a defined threshold—or if the compressed context still exceeds the token budget after the final retry—escalate to a fallback path: either route to a model with a larger context window, request human review, or return a partial result with explicit limitation notes. Log every compression attempt with the original token count, compressed token count, fidelity score, and retry outcome for observability.

Model choice matters. Compression prompts benefit from models with strong summarization and instruction-following capabilities. For high-stakes workflows, prefer a capable model (e.g., GPT-4, Claude 3.5 Sonnet) for the compression step even if the primary task uses a smaller model. The compression step is a one-time cost that prevents repeated failures downstream. Wire the harness to use structured logging that captures: the overflow trigger event, the compression prompt version, input/output token counts per attempt, fidelity check results, and the final retry outcome. This data feeds into prompt observability dashboards and helps tune compression thresholds over time. Avoid silent compression—always surface to the user or downstream system that context was compressed, what was preserved, and what fidelity trade-offs were made.