Spend-Threshold Alert and Reroute Prompt

This prompt is designed for infrastructure engineers who need automated spend monitoring and rerouting logic embedded in their AI platform's middleware layer. Use it when your system must detect that cumulative spend is approaching a defined threshold and produce a structured alert with actionable reroute recommendations before budget overruns occur. This prompt belongs in the observability and control plane of a multi-model routing architecture, not in the request path itself. It expects real-time or near-real-time spend metrics as input and produces a decision payload that your routing infrastructure can consume programmatically.

The ideal user is an AI infrastructure engineer or platform operator responsible for cost governance across model calls. Required context includes a current spend counter, a defined budget threshold, a known burn rate, and a catalog of available fallback models or routing targets with their associated costs. The prompt is not a forecasting tool; it makes a binary alert decision and recommends a reroute action based on the instantaneous relationship between current spend and the threshold. Wire this into a control loop that polls spend metrics every few seconds or after each billing event, not into a daily batch job.

Do not use this prompt for long-term budget forecasting, capacity planning, or post-hoc cost analysis. It is a tactical, in-the-moment alerting and rerouting tool. It will not reason about monthly trends, reserved instance utilization, or commitment discounts. If your use case requires projecting spend over days or weeks, use a time-series forecasting model or a dedicated cost analytics pipeline. This prompt also assumes that rerouting is possible and that fallback targets are available; if your system has no cheaper alternative path, the prompt should be configured to alert and recommend human intervention instead of an impossible reroute.

This template is designed to be invoked inside your monitoring pipeline every time a new spend data point arrives. It expects live variables from your cost tracking system—current burn rate, projected overage time, and available reroute options—and produces a structured alert decision with an actionable reroute recommendation. The prompt is not a dashboard; it is a decision engine that should be wired to your alerting and routing infrastructure.

textCopy
SYSTEM: You are a cost-control routing engine for an AI infrastructure platform. Your job is to monitor real-time spend against defined thresholds and produce alert decisions with specific reroute recommendations when thresholds are breached or projected to breach within the warning window. You must never recommend a reroute that would violate a hard budget cap. You must always include a confidence score and the evidence you used.

INPUT:
- Current burn rate (USD per minute): [CURRENT_BURN_RATE]
- Hard budget cap (USD): [HARD_BUDGET_CAP]
- Soft alert threshold (USD): [SOFT_ALERT_THRESHOLD]
- Time window for projection (minutes): [PROJECTION_WINDOW]
- Current cumulative spend in window (USD): [CURRENT_SPEND]
- Available reroute targets with cost profiles (JSON array of objects with fields: target_id, cost_per_request_usd, latency_p95_ms, quality_score_1_to_5, capacity_available_boolean): [REROUTE_TARGETS]
- Current primary model identifier: [PRIMARY_MODEL_ID]

OUTPUT_SCHEMA (JSON only):
{
  "alert_triggered": boolean,
  "alert_level": "none" | "warning" | "critical",
  "projected_overage_time_minutes": number | null,
  "recommended_reroute_target": string | null,
  "reroute_justification": string,
  "confidence_score": number (0-1),
  "evidence_summary": string
}

CONSTRAINTS:
1. Trigger "warning" if projected spend reaches [SOFT_ALERT_THRESHOLD] within [PROJECTION_WINDOW] minutes.
2. Trigger "critical" if projected spend reaches [HARD_BUDGET_CAP] within [PROJECTION_WINDOW] minutes.
3. When recommending a reroute target, select the lowest-cost target with quality_score >= 3 and capacity_available == true that keeps projected spend under [HARD_BUDGET_CAP].
4. If no suitable reroute target exists, set recommended_reroute_target to null, alert_level to "critical", and justify with the least-bad option analysis.
5. Confidence must reflect the stability of the burn rate trend. High variance in recent samples should reduce confidence.
6. Never recommend the current primary model if alert_level is "critical".

To adapt this prompt, replace each square-bracket placeholder with live data from your spend tracking system before every invocation. The REROUTE_TARGETS array should be maintained as a configuration object that reflects your current model catalog with accurate pricing and availability. If your monitoring pipeline samples spend data every 60 seconds, set PROJECTION_WINDOW to a multiple that gives enough lead time for rerouting to take effect—typically 5–15 minutes. Before deploying, validate that your spend tracking system can supply accurate CURRENT_BURN_RATE values under load; a stale or averaged burn rate will produce false negatives and budget breaches. For high-risk production environments, add a human approval step when alert_level is "critical" and the recommended reroute target has a quality score below 4.

This prompt is not a standalone chatbot interaction; it is a decision node inside a cost-control pipeline. The implementation harness must treat the prompt as a deterministic function that receives real-time telemetry, produces a structured routing decision, and feeds that decision into a model dispatcher or load balancer. The primary integration points are your observability stack (for burn rate and spend data), your model gateway or router (to enforce the reroute decision), and your alerting system (to notify on-call engineers when thresholds are breached). The harness should never rely on the prompt to fetch its own data—all variables such as [CURRENT_SPEND], [BUDGET_CAP], [BURN_RATE], and [PROJECTED_OVERAGE_TIME] must be injected from upstream systems that own the source of truth.

Validation and enforcement: The prompt output must conform to a strict JSON schema with fields for alert_triggered (boolean), severity (enum: info, warning, critical), recommended_reroute_target (model ID or queue name), and justification (string). Implement a post-generation validator that rejects any response missing required fields or containing invalid enum values. If validation fails, retry once with the error message appended to the prompt context. If the retry also fails, fall back to a hardcoded safe route (e.g., the cheapest available model) and fire an alert to the on-call channel. Logging: Log every decision with the input telemetry, the raw prompt response, the validated output, and the action taken by the router. This audit trail is essential for tuning thresholds and defending cost decisions during post-mortems.

Model choice and latency: This prompt is a low-latency classification task, not a reasoning-heavy generation. Use a fast, cheap model (e.g., a lightweight instruction-tuned model or a small hosted endpoint) to keep the routing overhead below 200ms. The cost of running this prompt should be negligible compared to the spend it prevents. Tool use and RAG: Do not give this prompt access to tools or retrieval. All necessary data must be pre-computed and injected via the template variables. Allowing the prompt to query billing APIs or dashboards introduces latency, non-determinism, and the risk of hallucinated spend figures. Human review: For critical severity alerts, the harness should page the on-call engineer and optionally require manual approval before rerouting production traffic. For warning and info levels, automated rerouting is acceptable if the fallback chain has been tested under load. What to avoid: Never use this prompt to make the actual model call or to modify billing state. It is a read-only decision node. The router that consumes its output is the only component authorized to change traffic flow.