Token Budget Enforcement System Prompt

This prompt is for platform engineers and AI infrastructure teams who need the model itself to participate in context window management. Instead of relying solely on application-layer truncation logic, this system-level instruction makes the model aware of its token budget, capable of prioritizing essential context, and responsible for emitting structured warnings before truncation occurs. The primary job-to-be-done is preventing silent context loss, where critical instructions or conversation state are dropped without the application or user knowing. This is especially valuable in long-running agent loops, multi-turn copilot sessions, and RAG pipelines where tool outputs and retrieved evidence accumulate unpredictably.

Use this prompt when you cannot guarantee deterministic budget control from the application side alone—for example, when tool call responses vary dramatically in length, when user turns are unbounded, or when you need graceful degradation rather than hard truncation. The prompt works best with models that have strong instruction-following capabilities and reliable structured output generation. It is not a replacement for application-layer token counting; it is a defense-in-depth layer that catches budget overruns the application might miss and provides telemetry for observability. Do not use this prompt for single-turn classification or extraction tasks where context is fixed and predictable—the overhead of budget monitoring adds latency and consumes tokens without benefit.

Before deploying, pair this prompt with an application-side token counter that validates the model's self-reported budget estimates. The model's token counting is approximate, not exact, so treat its budget warnings as signals for your truncation logic, not as the sole source of truth. Define clear escalation rules: what happens when the budget warning fires, what gets compressed first, and whether the user should be notified. Test with variable-length tool outputs and multi-turn conversations to ensure the model doesn't prematurely declare budget exhaustion or, worse, silently drop system instructions to stay within budget. The next section provides the copy-ready template you can adapt to your specific budget thresholds and escalation rules.

This system prompt is designed to be placed at the top of the instruction hierarchy for any agent or assistant that must operate within a strict context window budget. It transforms the model from a passive consumer of context into an active budget manager, requiring it to track its own consumption, prioritize what matters, and escalate cleanly when the budget is exhausted. The prompt is model-agnostic but assumes the underlying model can reason about its own context window—it works best with models that have been trained to follow multi-step procedural instructions.

textCopy
<SYSTEM>
You are a context-budget-aware assistant. You have a maximum usable context window of [MAX_TOKENS] tokens. Your current context includes system instructions, conversation history, retrieved evidence, tool outputs, and user input. You must actively manage this budget.

## Budget Rules
1. Estimate your total token consumption before every response. If consumption exceeds [WARNING_THRESHOLD]% of [MAX_TOKENS], emit a structured warning in your response metadata.
2. When consumption exceeds [CRITICAL_THRESHOLD]% of [MAX_TOKENS], you must prioritize essential context and drop or summarize non-essential content before responding.
3. Essential context includes: [ESSENTIAL_CONTEXT_DEFINITION]. Non-essential context includes: [NON_ESSENTIAL_CONTEXT_DEFINITION].
4. If the budget is fully exhausted and you cannot produce a safe or coherent response, emit an escalation signal and request human intervention or session restart.

## Output Format
Every response must include a JSON metadata block before the user-facing content:
```json
{
  "token_estimate": {
    "total_consumed": <int>,
    "budget_remaining": <int>,
    "warning_level": "normal" | "warning" | "critical" | "exhausted"
  },
  "context_actions": [
    {
      "action": "retained" | "summarized" | "dropped",
      "target": "<description of context element>",
      "reason": "<justification>"
    }
  ],
  "escalation": null | {
    "signal": "budget_exhausted" | "unsafe_truncation",
    "message": "<user-facing explanation>",
    "recommended_action": "<next step for the calling system>"
  }
}

Escalation Rules

• If [ESCALATION_CONDITION_1], emit escalation with signal "budget_exhausted".
• If [ESCALATION_CONDITION_2], emit escalation with signal "unsafe_truncation".
• Never fabricate context or guess when essential information has been dropped.

Priority Order for Retention

When budget is tight, retain context in this order:

1. [PRIORITY_1]
2. [PRIORITY_2]
3. [PRIORITY_3]
4. [PRIORITY_4]

Constraints

• Do not drop [PROTECTED_CONTEXT_TYPE] under any circumstances.
• When summarizing, preserve [SUMMARY_PRESERVATION_RULES].
• If user input contains a correction, treat it as priority 1 context. </SYSTEM>

To adapt this template, replace the square-bracket placeholders with your application's specific thresholds, context definitions, and priority rules. For a customer support assistant, [ESSENTIAL_CONTEXT_DEFINITION] might be 'unresolved user questions, account details, and policy constraints,' while [NON_ESSENTIAL_CONTEXT_DEFINITION] might be 'social niceties, redundant confirmations, and already-resolved clarifications.' The [PROTECTED_CONTEXT_TYPE] placeholder should capture anything that must never be dropped—typically system safety policies, user identity claims, or compliance-mandated disclosures. Test the prompt with a range of conversation lengths and verify that the structured metadata block is parseable by your application harness before deploying to production.

The Token Budget Enforcement System Prompt is designed to be injected as a system-level instruction in your model request pipeline, not as a user-facing message. It should be placed at the highest priority in your system prompt assembly, typically after core behavioral policies but before tool definitions and conversation history. The prompt instructs the model to self-monitor its token consumption, prioritize essential context, and emit structured budget warnings before truncation occurs. This is not a post-hoc pruning tool—it is a runtime guard that shifts budget awareness into the model's own reasoning loop, making it an active participant in context management rather than a passive consumer of whatever context you provide.

To wire this into an application, implement a pre-request hook that estimates the current token count for all prompt components (system instructions, history, retrieved evidence, tool outputs) and passes that estimate into the prompt's [CURRENT_TOKEN_COUNT] and [TOKEN_BUDGET] placeholders. Use your model provider's tokenizer (e.g., tiktoken for OpenAI models, the Anthropic token counting API, or a local sentencepiece tokenizer for open-weight models) to get an accurate count—do not rely on character or word approximations. After the model responds, parse the output for the structured budget status block defined in the prompt's [OUTPUT_SCHEMA]. This block should contain fields like budget_remaining, warning_level (none, caution, critical, exhausted), and escalation_action (continue, compress, summarize, refuse, request_guidance). If the model fails to emit this block or emits malformed JSON, implement a retry with a stronger format constraint, but cap retries at 2 attempts to avoid burning tokens on repair loops. Log every budget status block to your observability stack for trend analysis—tracking budget exhaustion frequency per session, per user, and per workflow is essential capacity planning data.

For high-stakes deployments where budget exhaustion could cause dropped context mid-task, implement a circuit breaker in your application layer that intercepts warning_level: critical or warning_level: exhausted statuses before the next turn. When triggered, execute a pre-defined degradation strategy: compress older turns using a summarization model, drop low-signal tool outputs, or inject a user-facing message asking whether to continue with reduced context. Do not rely solely on the model's self-reported budget status for enforcement—the model's token estimates are approximate and can drift. Cross-validate the model's reported budget_remaining against your own tokenizer count at each turn boundary, and if the discrepancy exceeds 15%, override with your application-layer count. This dual-source validation prevents both under-counting (leading to silent context loss) and over-counting (leading to premature degradation). For regulated workflows, ensure that every budget exhaustion event and the resulting degradation action is written to an audit log with the session ID, timestamp, and the specific turns or evidence that were dropped.