Token Consumption Anomaly Alert Prompt Template

This prompt is designed for platform engineers and AI operations teams who need to programmatically evaluate production trace data for anomalous token consumption. Use it when you have a stream of per-request token metrics and a historical baseline, and you need the model to classify whether current consumption represents a significant anomaly requiring alerting. The ideal user has already instrumented their AI application to capture token counts per request—including prompt tokens, completion tokens, and total tokens—and has established a statistical baseline from historical data. The prompt assumes you are feeding it structured trace data, not raw logs, and that you need a machine-readable alert payload as output, not a human-readable summary.

This is not a dashboard query builder or a metric extraction prompt. Do not use it when you need to generate SQL for your observability platform, extract token counts from unstructured logs, or build a visualization. It is also not a cost-attribution prompt; while it may reference cost implications, its primary job is anomaly classification against statistical thresholds. Avoid using this prompt for real-time streaming ingestion where latency is measured in milliseconds—the model's reasoning step adds overhead better suited for near-real-time or batch evaluation windows. If your goal is to define the alert thresholds themselves, use the Alert Threshold Tuning Recommendation Prompt Template instead. This prompt assumes thresholds are already configured and focuses on evaluating current data against them.

Before wiring this prompt into production, ensure you have a reliable pipeline that provides per-request token metrics with consistent schema, a historical baseline covering at least several evaluation windows, and a defined variance threshold that distinguishes normal fluctuation from actionable anomalies. The prompt works best when paired with a validation layer that checks the output schema before the alert payload is forwarded to your incident management system. For high-severity alerts—such as sudden 10x token spikes that could indicate a prompt injection or context window explosion—always include a human review step in the escalation path rather than relying solely on automated classification.

The prompt below is designed to be copied directly into your monitoring harness. It expects a historical baseline, a current observation window, and a set of configurable variance thresholds. Every placeholder is enclosed in square brackets. Before sending this prompt to the model, replace each placeholder with live data from your observability store. The prompt instructs the model to perform a structured classification of the anomaly, attribute it to a specific prompt version or context expansion event, and produce a per-request token attribution breakdown. Do not use this prompt for real-time blocking decisions; it is designed for asynchronous alert generation where a human reviews the output before action is taken.

textCopy
You are an AI observability analyst reviewing production LLM trace data for token consumption anomalies.

Your task is to compare the current observation window against the historical baseline and classify any anomalies detected.

# INPUTS

## Historical Baseline
[BASELINE_TOKEN_STATS]

## Current Observation Window
[OBSERVATION_WINDOW_TRACES]

## Configuration
- Variance Threshold (z-score): [VARIANCE_THRESHOLD]
- Minimum Request Count for Alert: [MIN_REQUEST_COUNT]
- Cost Per 1K Tokens (Input/Output): [TOKEN_PRICING]

# OUTPUT SCHEMA

Return a single JSON object with the following structure:
{
  "alert_triggered": boolean,
  "anomaly_classification": "spike" | "sustained_shift" | "new_pattern" | "none",
  "severity": "critical" | "warning" | "info",
  "summary": "One-sentence description of the anomaly.",
  "attribution": [
    {
      "prompt_version": "string",
      "token_delta_percent": number,
      "likely_cause": "version_change" | "context_expansion" | "tool_call_growth" | "unknown"
    }
  ],
  "per_request_breakdown": [
    {
      "trace_id": "string",
      "prompt_tokens": number,
      "completion_tokens": number,
      "total_tokens": number,
      "cost_estimate": number,
      "anomaly_flag": boolean
    }
  ],
  "recommended_actions": ["string"]
}

# CONSTRAINTS
- Only flag an anomaly if the z-score exceeds [VARIANCE_THRESHOLD] and the request count is at least [MIN_REQUEST_COUNT].
- Attribute token growth to the most specific cause available in the trace metadata.
- If no anomaly is detected, set alert_triggered to false and leave attribution and per_request_breakdown arrays empty.
- Do not invent trace IDs or token counts. Use only the data provided.
- Cost estimates must use the provided [TOKEN_PRICING] configuration.

To adapt this template, start by replacing [BASELINE_TOKEN_STATS] with a structured summary of your historical token consumption, such as mean and standard deviation of tokens per request over the last seven days, segmented by prompt version. Replace [OBSERVATION_WINDOW_TRACES] with the raw trace spans from your current monitoring window, including trace_id, prompt_version, prompt_tokens, completion_tokens, and any context window metadata. Set [VARIANCE_THRESHOLD] to a z-score value appropriate for your traffic pattern—2.0 is a common starting point for general anomalies, while 3.0 reduces false positives for high-variance workloads. The [MIN_REQUEST_COUNT] field prevents alerts on statistically insignificant samples; set it to at least 50 for production systems. Finally, populate [TOKEN_PRICING] with your model's current input and output token costs to enable accurate cost attribution in the per_request_breakdown.

Before deploying this prompt into an automated pipeline, validate the output against a set of known anomaly cases. Confirm that the model correctly distinguishes between a one-time spike caused by a single large request and a sustained shift caused by a prompt version change. Test edge cases where the observation window contains exactly [MIN_REQUEST_COUNT] requests or where the z-score is exactly at the threshold. If the model misclassifies a normal fluctuation as an anomaly, increase [VARIANCE_THRESHOLD] or widen the baseline window. Never send this alert directly to an on-call pager without human review of the first several alert cycles to calibrate thresholds against your actual traffic patterns.

The Token Consumption Anomaly Alert Prompt Template is designed to be called by an automated monitoring service, not a human chat interface. The prompt expects a structured payload containing a historical baseline, a variance threshold, and the current observation window. The application layer is responsible for assembling this payload from your observability store—typically a time-series database or trace analytics platform—and injecting it into the prompt's [BASELINE_STATS], [CURRENT_WINDOW], and [VARIANCE_THRESHOLD] placeholders. The model's job is to classify the anomaly, not to query the data itself.

Implement a pre-flight validation step before calling the LLM. Verify that [BASELINE_STATS] contains at least 7 days of hourly token consumption data, that [CURRENT_WINDOW] is a complete and contiguous time range, and that [VARIANCE_THRESHOLD] is a numeric value between 1.5 and 5.0 standard deviations. If validation fails, log the malformed request and abort the call—do not ask the model to interpret broken data. On a successful response, parse the output against the expected JSON schema. If parsing fails or required fields like anomaly_detected, severity, or attribution are missing, implement a single retry with a simplified re-prompt that includes the raw model output and a terse instruction: The previous output was malformed. Return only valid JSON matching the schema. After one retry, escalate to the on-call channel with the raw trace.

Wire the validated model output into your alerting pipeline. Map the severity field to your incident management tiers: critical triggers an immediate page, warning creates a ticket in the engineering queue, and info appends to a daily digest. The attribution array—which identifies the prompt version, model, or context window event responsible for the spike—should be written as tags on the alert so responders can filter dashboards immediately. Log every prompt invocation, including the full request payload, model response, parse status, and alert routing decision, to a dedicated audit table. This log is essential for tuning the variance threshold over time and for defending alert fatigue complaints during operational reviews.