Token Budget Exhaustion Escalation Prompt Template

This prompt is the terminal escalation step for platform architects and reliability engineers when an AI task has consumed its entire allocated retry budget and token allocation without producing a complete, valid result. It is not designed for continuing work, attempting a different strategy, or squeezing out a few more tokens. Its sole job-to-be-done is to instruct the model to stop safely, produce a structured partial result artifact, explain its limitations transparently, and prepare a handoff payload for a human operator or a fallback model with a larger context window. The ideal user is an engineer designing an automated AI harness who needs a deterministic, graceful failure mode instead of an unhandled exception or a truncated, unusable output.

Deploy this prompt only after upstream recovery strategies have been exhausted. This includes retries for malformed JSON, invalid tool calls, context window overflow truncation recovery, and context compression retries. The trigger condition is a hard token budget exhaustion event: the model cannot complete the task because the combined prompt, completion, and retry history have hit a predefined ceiling. This ceiling is typically defined by a context window limit (e.g., 128k tokens), a max output token limit, or a cumulative cost budget. Before invoking this prompt, your harness must track the total tokens consumed across all retry attempts for a single task. If the remaining token budget is insufficient for a meaningful completion attempt, this escalation prompt is the correct next step.

Do not use this prompt for transient failures, schema validation errors, or cases where a different model or a simple retry with adjusted parameters could succeed. It is also inappropriate for user-facing chat interactions where a conversational 'I'm sorry, I can't complete this' message is sufficient; this prompt is for machine-to-machine or machine-to-operator workflows where a structured artifact is required for downstream processing. Avoid using it when the task is low-stakes and a null return or default value is an acceptable fallback. The prompt's value is in high-stakes, automated pipelines where an unhandled failure would cause a broken workflow, data loss, or an unrecoverable state.

After executing this prompt, the output must be programmatically validated to ensure it contains the required structured fields: a partial result payload, a limitation explanation, and a handoff artifact. If the model fails to produce this structure even with the escalation prompt, the harness should fall back to a static error template and log the full trace for human review. The next step for the reader is to integrate this prompt into their retry budget tracking logic and define the exact token threshold that triggers escalation.

This template is designed to be the final escalation step in your retry exhaustion handler. It assumes that prior retry strategies—context compression, summarization, sliding windows, and progressive reduction—have already been attempted and failed. The prompt instructs the model to stop trying to complete the full task and instead produce a structured handoff artifact: a partial result with clear boundary markers, a plain-language explanation of what could not be completed, and a routing recommendation. This is not a prompt for continuing work; it is a prompt for graceful failure.

textCopy
SYSTEM:
You are a task execution agent operating under a strict token budget. Your token budget has been exhausted after multiple retry attempts. You must NOT attempt to complete the remaining work. Instead, produce a structured escalation report.

INSTRUCTIONS:
1. Review the [ORIGINAL_TASK] and [WORK_COMPLETED_SO_FAR].
2. Identify exactly what was completed and what remains incomplete.
3. Produce a partial result containing only the completed work, clearly marked with a [COMPLETION_BOUNDARY] marker.
4. Write a [LIMITATION_EXPLANATION] that explains, in plain language, why the task could not be completed (token budget exhaustion) and what remains.
5. Based on [RISK_LEVEL], recommend one of the following [ESCALATION_ACTION] values: ROUTE_TO_HUMAN, ROUTE_TO_FALLBACK_MODEL, or QUEUE_FOR_LATER.
6. If ROUTE_TO_HUMAN, include a [HUMAN_HANDOFF_SUMMARY] with the context a human reviewer needs to resume work.
7. If ROUTE_TO_FALLBACK_MODEL, specify the [FALLBACK_MODEL_NAME] and [FALLBACK_PROMPT] to use.
8. If QUEUE_FOR_LATER, include a [RESUMPTION_INSTRUCTIONS] block with the exact state needed to restart.
9. Output the escalation report in valid JSON matching [OUTPUT_SCHEMA].
10. Do not hallucinate completed work. Only include what was actually finished.

USER:
ORIGINAL_TASK: [ORIGINAL_TASK]
WORK_COMPLETED_SO_FAR: [WORK_COMPLETED_SO_FAR]
RISK_LEVEL: [RISK_LEVEL]
RETRY_ATTEMPTS_EXHAUSTED: [RETRY_ATTEMPTS_EXHAUSTED]
OUTPUT_SCHEMA: [OUTPUT_SCHEMA]

To adapt this template, start by defining your [OUTPUT_SCHEMA] to match your downstream ingestion system. The schema should include fields for partial_result, completion_boundary, limitation_explanation, escalation_action, and the conditional fields for each escalation path. Set [RISK_LEVEL] dynamically based on your application's risk taxonomy—use values like HIGH, MEDIUM, or LOW to control whether the output routes to a human or an automated fallback. The [WORK_COMPLETED_SO_FAR] placeholder should be populated from your application's state tracker, not from model memory. Always validate the output against your schema before routing; a malformed escalation report is itself a failure that needs handling. For high-risk domains, require human review of the escalation report before any automated routing decision takes effect.

This prompt is not a standalone retry instruction; it is a terminal escalation point that fires after a configurable retry budget has been exhausted. The harness must track the number of retries, the cumulative tokens consumed, and the remaining budget before invoking this prompt. Typical integration points include an agent orchestrator's error handler, a model gateway's fallback policy, or a batch pipeline's completion check. The prompt expects the harness to inject the original task, the partial output produced so far, the token budget consumed, and the escalation reason. Without this context, the prompt cannot produce a useful partial result or a meaningful handoff summary.

Wire the prompt into a retry manager that maintains a retry_budget counter and a token_budget_remaining tracker. After each failed attempt, decrement the retry budget. If the retry budget reaches zero or the token budget falls below a minimum threshold (e.g., 500 tokens), invoke this escalation prompt instead of another retry. The harness must pass [ORIGINAL_TASK], [PARTIAL_OUTPUT], [TOKENS_CONSUMED], [RETRIES_ATTEMPTED], [FAILURE_REASON], and [ESCALATION_TARGET] (e.g., a human reviewer queue ID, a fallback model name, or a dead-letter topic). Validate the output by checking for the presence of a partial_result field, an escalation_summary, and a next_step indicator. If any required field is missing or malformed, log the failure and route to a human-operated dead-letter queue rather than retrying again.

For high-risk domains (healthcare, legal, finance), the harness must not auto-escalate to another model without human review. Instead, the escalation output should be written to a review queue with the partial result and a structured summary. A human operator confirms or rejects the escalation before any further automated action. Logging is critical: record the escalation event, the token budget state, the retry count, the model version, and the full prompt and response for auditability. Use structured logging with trace IDs that link the escalation event back to the original request. Model choice matters here—this prompt works best with models that have strong instruction-following and structured output capabilities (e.g., GPT-4o, Claude 3.5 Sonnet). Avoid using smaller or less capable models for escalation prompts, as they may hallucinate completion claims or omit critical handoff details.

What to avoid: Do not invoke this prompt inside a retry loop without a hard limit. An uncontrolled escalation loop can burn tokens and delay resolution. Set a maximum of one escalation attempt per request. If the escalation prompt itself fails, route directly to a human-operated fallback. Do not use this prompt for transient errors like rate limits or temporary model unavailability—those belong in a separate retry-with-backoff path. This prompt is for unrecoverable token exhaustion where further retries cannot produce a complete result. Finally, test the harness with synthetic exhaustion scenarios before production: simulate a task that always exceeds the token budget, verify that the escalation fires after the retry budget is spent, and confirm that the partial result and handoff summary are correctly routed to the designated escalation target.