Runtime Cost Spike Alert Prompt Template

This prompt is designed for FinOps engineers and AI platform operators who need to detect and triage anomalous cost spikes in production LLM traces. It ingests structured trace data, token pricing tables, and budget thresholds to produce a cost attribution report with spike severity scoring. Use this when your observability pipeline already captures per-request token counts, model identifiers, and prompt version tags, but you need a repeatable, automated way to surface cost anomalies before they become budget incidents. This is not a replacement for a real-time metrics dashboard; it is the analytical step that turns raw trace aggregates into an actionable alert payload.

The prompt requires three concrete inputs to function correctly: a structured trace payload containing per-request model_id, prompt_version, input_tokens, and output_tokens; a token pricing configuration mapping each model to its per-token cost; and a budget threshold definition specifying daily or weekly spend limits per model or project. Without these, the prompt will either hallucinate pricing or produce ungrounded severity scores. You should also configure a [BASELINE_WINDOW] parameter—typically 7 or 14 days—so the prompt can distinguish a genuine spike from normal variance. The output is a structured cost attribution report, not a natural-language summary, which makes it suitable for direct ingestion into an alerting webhook or a FinOps dashboard.

Do not use this prompt for real-time per-request cost enforcement, as the analytical window and LLM inference latency make it unsuitable for inline decisions. It is also not a substitute for a proper cost allocation system if your traces lack model or version tags. If your observability data is incomplete, invest in trace instrumentation first. After running the prompt, always validate the output against your source-of-truth billing data to catch pricing configuration drift. For high-severity spikes, route the report to a human reviewer before triggering automated budget freezes.

This section provides a self-contained prompt template you can paste directly into your alert evaluation pipeline. The template is designed to receive structured trace data, token pricing tables, and budget thresholds, then produce a cost spike severity score with attribution to specific models, prompt versions, and sessions. Use this as the core analysis step in a FinOps monitoring workflow where raw cost deviations must be translated into actionable alerts before budgets are breached.

textCopy
You are a FinOps cost spike analyzer. Your task is to evaluate production AI trace data against configured budget thresholds and pricing tables to detect anomalous cost increases.

## INPUT DATA

### Trace Cost Records
[TRACE_COST_RECORDS]

### Token Pricing Configuration
[TOKEN_PRICING_CONFIG]

### Budget Thresholds
[BUDGET_THRESHOLDS]

## OUTPUT SCHEMA
Return a valid JSON object with this exact structure:
{
  "spike_detected": boolean,
  "severity": "critical" | "warning" | "normal",
  "spike_magnitude_percent": number,
  "time_window": string,
  "attribution": [
    {
      "model": string,
      "prompt_version": string,
      "session_id": string,
      "cost_increase_percent": number,
      "token_consumption_delta": number
    }
  ],
  "anomalous_sessions": [
    {
      "session_id": string,
      "cost": number,
      "expected_cost": number,
      "deviation_score": number
    }
  ],
  "recommendation": string
}

## CONSTRAINTS
- Compare current window costs against the rolling 7-day average baseline.
- Classify severity as "critical" if cost exceeds 150% of budget threshold, "warning" if 110-150%, otherwise "normal".
- Attribute cost increases to the model, prompt version, and session level where possible.
- Flag sessions with deviation scores above 2.0 standard deviations from baseline.
- If pricing data is missing for any model, note it in the recommendation field and exclude that model from severity calculation.
- Do not fabricate cost data. If inputs are insufficient, set spike_detected to false and explain in the recommendation.

## EVALUATION CRITERIA
After generating the output, self-check:
1. Are all percentage calculations based on the provided pricing config, not assumed prices?
2. Is the severity classification consistent with the defined thresholds?
3. Are attribution entries traceable to specific records in the input data?

To adapt this template for your environment, replace the square-bracket placeholders with your actual data sources. The [TRACE_COST_RECORDS] should contain per-request token counts, model identifiers, prompt versions, and timestamps from your observability pipeline. The [TOKEN_PRICING_CONFIG] must map each model to its current per-token cost. The [BUDGET_THRESHOLDS] define your acceptable cost ceilings per time window. Before deploying, validate that your trace ingestion pipeline consistently populates all required fields and that your pricing config is updated when model pricing changes. For high-stakes financial alerts, always route the output through a human review step before triggering automated budget freezes or service degradation.

This prompt is designed to be called by an automated monitoring pipeline, not a human chat interface. The implementation harness should trigger the prompt when a cost anomaly is detected by a preceding metric query—typically a spike exceeding 2x the rolling hourly average for a given model or project. The harness is responsible for assembling the [TRACE_DATA], [TOKEN_PRICING], and [BUDGET_THRESHOLDS] inputs from your observability store and cost database before invoking the model. Because this prompt produces a structured severity score and attribution breakdown, the harness must validate the output schema before the alert is routed to an on-call FinOps engineer or a Slack channel.

Wire the prompt into a serverless function or a cron-driven job that queries your trace store (e.g., ClickHouse, BigQuery, or Datadog) for the last hour of token consumption data grouped by model_id, prompt_version, and session_id. Pass the raw aggregation as [TRACE_DATA] in JSON format. Load [TOKEN_PRICING] from a configuration table that maps each model to its current input and output token costs. Set [BUDGET_THRESHOLDS] from your team's approved daily or hourly spend limits. After the model returns a response, validate that the output contains the required fields: spike_severity_score (0-100), cost_attribution (array of objects with model, prompt_version, session_id, cost_delta), and recommended_action. If validation fails, retry once with a stricter [CONSTRAINTS] block that emphasizes schema compliance. Log both the raw prompt and the validated output to your audit trail for post-incident review.

For high-severity spikes (score > 70), the harness should require human approval before sending a page. Route the validated output to a review queue or a Slack message with a deep link to the relevant trace dashboard. Do not auto-escalate without confirmation unless your team has established a runbook for automatic model circuit-breaking. For lower-severity alerts, the harness can log the finding and update a cost dashboard without interrupting anyone. Avoid wiring this prompt directly to a model-routing decision or an auto-scaling rule—cost attribution is diagnostic, not a control-plane action. The next step is to pair this prompt with an alert condition definition that formalizes the spike threshold logic so the harness can decide when to invoke the prompt in the first place.