Token-Efficient Intent Detection Prompt for High-Volume Routing

This playbook is for AI platform engineers and infrastructure teams processing millions of requests daily where prompt token cost is the dominant operational expense. The prompt produces intent labels with minimal token overhead by using compressed instructions, a constrained output format, and a strict token budget variable. Use this when your routing middleware needs to classify user input before dispatching to downstream models, tools, or queues, and every token of system prompt overhead directly impacts your unit economics.

This prompt is not a general-purpose classifier. It trades verbose reasoning and rich output for raw throughput and cost efficiency. If you need detailed explanations, multi-intent disambiguation, or high-confidence scoring, pair this with a separate confidence assessment prompt or use a more expressive classification template. The prompt assumes you have already defined a stable intent taxonomy and that your downstream routing logic can act on a single label without additional context. Do not use this prompt when the cost of misclassification is high and you lack a fallback or human review path—silent misroutes at scale compound quickly.

Before deploying, run ablation tests comparing accuracy against token count across your intent taxonomy. Measure both classification accuracy and the downstream impact of misclassification (wrong queue, wrong model, wrong tool). If accuracy drops below your operational threshold, increase the token budget variable or add a lightweight confidence gate. The next section provides the copy-ready template with all required placeholders.

This template is designed to be the entire system prompt for a classification-only model call. It uses a compressed instruction format, a strict output schema, and a hard token budget to minimize per-request cost. The prompt assumes you have already extracted the user's raw input and placed it into the [USER_INPUT] variable. The taxonomy in [INTENT_TAXONOMY] should be a flat or shallow list of intent labels with brief, distinguishing descriptions. Avoid deep hierarchies or verbose definitions, as they consume the token budget without proportionally improving accuracy.

textCopy
System: You are an intent classifier. Your entire output must be a single JSON object with exactly two keys: "intent" and "confidence". Do not output any other text.

Taxonomy:
[INTENT_TAXONOMY]

Constraints:
- "intent" must be one of the labels from the Taxonomy.
- "confidence" must be a float between 0.0 and 1.0.
- If the input is ambiguous or fits multiple intents, choose the single best match and set confidence accordingly.
- If the input does not fit any intent, set "intent" to "OTHER" and confidence to your certainty that it is out-of-scope.
- Your total response must not exceed [MAX_OUTPUT_TOKENS] tokens.

User Input:
[USER_INPUT]

To adapt this template, replace the square-bracket placeholders. [INTENT_TAXONOMY] should be a compact list like ACCOUNT_ISSUE: Problems with login, billing, or account settings. TECHNICAL_SUPPORT: Errors, bugs, or service outages. GENERAL_INQUIRY: Questions about features, pricing, or policies. Keep descriptions under 10 words. Set [MAX_OUTPUT_TOKENS] to a value that allows the JSON to complete, typically 50-75 tokens. Before deploying, run this prompt through your target model's tokenizer to verify it fits within your [TOKEN_BUDGET]. A common failure mode is exceeding the budget due to a verbose taxonomy, which silently increases cost and latency. If you need to add few-shot examples, append them after the taxonomy using a compressed format like Example: input -> {"intent": "LABEL", "confidence": 0.95} to minimize token spend.

This prompt is designed to be the first decision point in a high-volume request pipeline. It should be deployed as a lightweight pre-processing step before any expensive model calls, tool dispatches, or context assembly. The implementation harness must treat this prompt as a deterministic classifier with a strict output contract: a single JSON object containing an intent label and a confidence score. Any deviation from this contract should trigger a fallback path rather than a repair loop, because the cost of repairing a malformed classification often exceeds the cost of routing to a default queue.

Wire the prompt into your application as a standalone function with the following signature: classify_intent(user_input: str, taxonomy: dict, token_budget: int) -> dict. The function should construct the prompt by injecting the [TAXONOMY] variable as a compact JSON mapping of intent labels to descriptions, and the [TOKEN_BUDGET] variable as a hard instruction. Validate the model's response against a JSON schema that requires intent to be one of the provided taxonomy keys and confidence to be a float between 0.0 and 1.0. If validation fails, log the raw output and route to a fallback queue. Do not retry with the same prompt; instead, use a simpler fallback classifier or a default routing rule. For model selection, prefer a fast, cheap model (e.g., GPT-3.5 Turbo, Claude Haiku, or a fine-tuned small open-weight model) since the prompt is optimized for token efficiency and does not benefit from larger reasoning capacity.

Implement structured logging that captures the intent, confidence, token_count, latency_ms, and validation_passed boolean for every classification call. This data feeds two critical observability loops: a cost dashboard that tracks token consumption against your budget, and an accuracy monitoring pipeline that compares classified intents against downstream outcomes (e.g., did the routed workflow succeed, did the user escalate, did a human reviewer override the classification). Set up a weekly ablation test that runs a held-out evaluation set through the prompt at different token budgets (e.g., 50, 100, 200 tokens) to measure the accuracy-vs-cost curve and detect drift. If confidence scores for a particular intent class drop below a threshold (e.g., 0.7), flag that class for taxonomy review or few-shot example updates.

For high-risk domains where misclassification carries regulatory or safety consequences, insert a human review step for low-confidence predictions. Configure the harness to route any classification with confidence < 0.8 to a review queue rather than directly to automated processing. The review interface should display the original user input, the model's top intent and confidence, and the full taxonomy for context. Log all human overrides to build a feedback dataset for future fine-tuning or prompt improvements. Avoid the temptation to add complexity to the prompt itself—keep it token-efficient and push decision logic into the harness where it can be tested, versioned, and monitored independently.