Token Budget Allocation Prompt for Mixed Context

This prompt is designed for AI engineers and operators who need to programmatically allocate a fixed token budget across a mixed context window. The core job-to-be-done is transforming a chaotic assembly of instructions, retrieved evidence, few-shot examples, and tool schemas into a disciplined, priority-ranked prompt that fits within a strict token ceiling. The ideal user is someone building a production RAG pipeline, a coding agent, or a multi-turn copilot who has already identified that context bloat is degrading latency, cost, or answer quality. You should use this prompt when you have a known [MAX_TOKENS] limit and multiple competing context categories that cannot all fit at full fidelity.

To use this effectively, you must provide the prompt with a structured inventory of your context categories, each tagged with a priority level and a minimum token floor. The prompt does not make up priorities—it allocates based on the task definition you supply. For example, in a legal document review task, [EVIDENCE] might have a hard floor of 60% of the budget, while [EXAMPLES] can be dropped entirely. In a customer support copilot, [CONVERSATION_HISTORY] might claim 40% before any evidence is added. The prompt outputs a concrete allocation plan with token counts per category, not a vague suggestion. It also includes a drift detection section that flags when the actual token count of a packed category exceeds its allocation, enabling a preflight check before inference.

Do not use this prompt as a substitute for proper retrieval ranking or evidence selection. If your upstream retrieval is returning mostly irrelevant documents, no allocation strategy will fix the signal-to-noise ratio. This prompt assumes you have already scored, filtered, or compressed your inputs and now need to make a final packing decision. It is also not a replacement for prompt caching strategies—if 80% of your prompt is static system instructions, cache that prefix and apply this allocation logic only to the dynamic remainder. Finally, for high-stakes regulated domains, the allocation plan should be logged as part of your audit trail, and any decision to drop evidence below its stated floor must trigger a human review gate.

The following template is designed to be copied directly into your prompt management system or codebase. It instructs the model to act as a context budget planner, distributing a fixed token allowance across multiple context categories—such as instructions, evidence, examples, and tool schemas—based on the task's stated priorities. The output is a structured allocation plan, not a final answer to the user's task. This separation keeps budgeting logic auditable and allows your application to assemble the final prompt according to the plan.

textCopy
You are a context budget planner for an AI system. Your job is to allocate a fixed token budget across multiple context categories for a given task. Do not perform the task itself. Output only the allocation plan.

## INPUT
Task Description: [TASK_DESCRIPTION]
Task Priority: [TASK_PRIORITY]  // Options: high, medium, low
Risk Level: [RISK_LEVEL]  // Options: high, medium, low

## AVAILABLE CONTEXT CATEGORIES
[CONTEXT_CATEGORIES]  // JSON array of objects: [{"name": "instructions", "description": "...", "min_tokens": 100, "critical": true}, ...]

## CONSTRAINTS
- Total token budget: [TOTAL_TOKEN_BUDGET]
- Minimum allocation per category must be respected if specified.
- Critical categories (marked above) must receive at least their minimum allocation.
- Allocate remaining tokens to maximize task success given the priority and risk level.
- If the budget is insufficient to meet all minimums, flag the shortfall explicitly.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "plan": [
    {
      "category": "string",
      "allocated_tokens": number,
      "rationale": "string"
    }
  ],
  "total_allocated": number,
  "budget_shortfall": boolean,
  "shortfall_details": "string or null"
}

## EXAMPLES
[EXAMPLES]  // Optional few-shot examples of good allocations for similar tasks.

## TOOLS
[TOOLS]  // Optional list of available tool schemas if tool-calling context is part of the budget.

To adapt this template, replace each square-bracket placeholder with runtime values from your application. [TASK_DESCRIPTION] should be a concise summary of the user's goal. [CONTEXT_CATEGORIES] is a JSON array defining every category that will compete for tokens—include min_tokens and critical flags to enforce hard constraints. [TOTAL_TOKEN_BUDGET] is the model's context window minus reserved space for the final response. If you have few-shot examples of successful allocations for similar tasks, inject them into [EXAMPLES] to improve consistency. For tool-heavy workflows, pass the tool definitions in [TOOLS] so the planner accounts for schema overhead. After receiving the allocation plan, your application should validate the JSON structure, check for budget shortfalls, and either proceed with assembly or trigger a fallback (e.g., compression or human review) before sending the final prompt to the model.

This prompt is designed to sit inside a context assembly pipeline, not as a standalone chat interaction. Before any user query reaches the final LLM, your application should call this budget allocation prompt to produce a structured allocation plan. The plan dictates how many tokens to reserve for instructions, evidence, examples, tool schemas, and conversation history. The output is a JSON object that your assembler reads to decide what to include, what to compress, and what to drop. Treat this allocation step as a preflight check that runs before the main inference call, especially when the total available context window is tight or variable across model deployments.

Wire the prompt into your application with a typed function call. The function should accept the required inputs—[TASK_DESCRIPTION], [CONTEXT_CATEGORIES], [TOTAL_TOKEN_BUDGET], [PRIORITY_HINTS], and [CONSTRAINTS]—and return a parsed JSON allocation plan. Validate the output immediately: confirm that the sum of allocated tokens does not exceed the total budget, that every category in the input appears in the output, and that mandatory categories (e.g., safety instructions) received a non-zero allocation. If validation fails, retry once with the validation error injected into the [CONSTRAINTS] field. After two consecutive failures, fall back to a static allocation map defined in your application config and log the incident for review. For high-stakes domains, route the allocation plan to a human approval queue before the assembler acts on it, especially when the plan proposes dropping evidence categories marked as compliance-relevant.

Choose a fast, inexpensive model for this allocation step. The prompt is a classification-and-arithmetic task, not a generation task, so models like GPT-4o-mini, Claude Haiku, or a fine-tuned small model work well. Log every allocation plan with a trace ID, the input parameters, the model version, and the validation result. This observability surface lets you detect budget drift—when the model starts consistently overallocating to one category or underallocating to another. Set a threshold alert: if the allocation for a critical category drops below a configured floor (e.g., safety instructions below 5% of budget), trigger a review. The allocation plan should also be attached to the main inference trace so you can correlate budget decisions with downstream output quality. Avoid using this prompt for single-turn, low-stakes tasks where a static budget is sufficient; the overhead of an extra model call only pays off when context packing decisions materially affect answer quality, cost, or compliance.