Cost-Estimate Preflight Prompt Before Model Invocation

This playbook is for platform engineers and AI infrastructure teams who need to predict the cost of a model call before it happens. Use this prompt when you have a multi-model routing system and you want to avoid committing an expensive, long-context request to a premium model without first understanding the financial impact. The prompt acts as a preflight check: it estimates input tokens, projects the total cost based on your pricing config, and returns a go/no-go recommendation. This is not a prompt for generating user-facing content. It is a control-plane prompt that sits inside your model gateway or router, making a deterministic, auditable decision before downstream invocation.

The ideal user is an infrastructure engineer who operates a model gateway, a cost-aware router, or a multi-model dispatch layer. They have access to current pricing data for each available model, understand their request volume patterns, and need to enforce cost controls without manual approval for every call. Required context includes a model pricing configuration (cost per 1K tokens for input and output), the estimated input length or the raw prompt text itself, and any hard budget constraints (per-request dollar cap, daily spend limits, or token budgets). Without accurate pricing data, the preflight estimate becomes a guess and loses its value as a control-plane decision point.

Do not use this prompt when you need a precise token count from a specific tokenizer. The prompt estimates tokens using heuristic methods (word count, character ratios) that are fast but approximate. For exact counts, use the model's native tokenizer in your application code before calling this prompt. Also avoid this prompt for streaming responses where output token count is unknown in advance; instead, use it for requests where you can bound the maximum output tokens. Finally, do not rely on this prompt alone for compliance-grade cost auditing. It is an operational control, not a financial record. Log its recommendations alongside actual costs to measure estimate accuracy over time and trigger recalibration when error rates drift beyond acceptable thresholds.

This prompt is designed to be run on a fast, cheap model like GPT-3.5 Turbo to act as a cost preflight check. It takes the system prompt, user input, and expected output schema you intend to send to a more expensive model and returns a token estimate, a cost projection, and a go/no-go recommendation. This prevents budget overruns in production systems where a single request to a frontier model could cost orders of magnitude more than the preflight check itself.

textCopy
You are a cost-estimation preflight system. Your job is to analyze the provided [TARGET_SYSTEM_PROMPT], [TARGET_USER_INPUT], and [TARGET_OUTPUT_SCHEMA] and estimate the total token consumption and cost for a target model invocation. Do not execute the task described in the system prompt. Only produce the cost estimate.

TARGET MODEL: [TARGET_MODEL_NAME]
INPUT TOKEN PRICE (per 1M tokens): [INPUT_PRICE_PER_1M]
OUTPUT TOKEN PRICE (per 1M tokens): [OUTPUT_PRICE_PER_1M]
MAX EXPECTED OUTPUT TOKENS: [MAX_OUTPUT_TOKENS]

TARGET SYSTEM PROMPT:
```[TARGET_SYSTEM_PROMPT]```

TARGET USER INPUT:
```[TARGET_USER_INPUT]```

TARGET OUTPUT SCHEMA:
```[TARGET_OUTPUT_SCHEMA]```

Estimate the following and return ONLY a valid JSON object with these exact keys:
- "estimated_input_tokens": integer, your estimate of total input tokens (system prompt + user input + schema).
- "estimated_output_tokens": integer, your estimate of output tokens based on the schema and task complexity, capped at [MAX_OUTPUT_TOKENS].
- "estimated_total_tokens": integer, sum of input and output estimates.
- "estimated_cost_usd": number, calculated as (estimated_input_tokens / 1,000,000 * [INPUT_PRICE_PER_1M]) + (estimated_output_tokens / 1,000,000 * [OUTPUT_PRICE_PER_1M]). Round to 6 decimal places.
- "cost_risk_level": string, one of "LOW", "MEDIUM", "HIGH" based on whether the estimated cost exceeds [LOW_RISK_THRESHOLD] and [HIGH_RISK_THRESHOLD].
- "go_no_go": string, "GO" if estimated_cost_usd is less than or equal to [HARD_COST_CAP], otherwise "NO_GO".
- "rationale": string, a brief explanation of your token estimate logic.

Do not include any text outside the JSON object.

To adapt this template, replace the square-bracket placeholders at runtime. [TARGET_MODEL_NAME] should be the exact model identifier (e.g., gpt-4o). [INPUT_PRICE_PER_1M] and [OUTPUT_PRICE_PER_1M] must be sourced from the provider's current pricing page, not hardcoded. Set [MAX_OUTPUT_TOKENS] to the max_tokens you would pass in the real API call. [LOW_RISK_THRESHOLD] and [HIGH_RISK_THRESHOLD] define your cost risk bands (e.g., $0.01 and $0.10). [HARD_COST_CAP] is the absolute maximum you are willing to spend on a single invocation. The preflight model will use these to make a binary routing decision. Always validate the returned JSON structure before acting on the go_no_go field; a malformed response should be treated as a NO_GO to avoid unexpected spend.

The cost-estimate preflight prompt is not a standalone utility; it is a gate in your model invocation pipeline. The primary integration point is immediately before the call to an expensive model (e.g., GPT-4, Claude Opus, or a fine-tuned large model). The application should serialize the fully assembled prompt—including system instructions, context, and user input—and pass it to the preflight prompt along with the current pricing configuration. The preflight returns a structured estimate that your application must evaluate against a hard or soft budget before proceeding. This gate pattern prevents surprise overages in agentic loops, batch processing, or high-volume API endpoints where a single runaway prompt can consume a daily budget in minutes.

Integration Architecture: Implement the preflight as a lightweight, deterministic check using a fast, cheap model (e.g., GPT-3.5 Turbo or Claude Haiku). The preflight model receives the target model's pricing config as part of [PRICING_CONFIG]—a JSON object mapping model names to input and output cost per 1K tokens. The application must supply [TARGET_MODEL], [INPUT_TOKEN_COUNT] (pre-computed using a tokenizer library like tiktoken), and [MAX_OUTPUT_TOKENS] from the original request parameters. The preflight prompt estimates the expected output tokens and calculates a cost projection. Validation layer: After receiving the preflight response, validate the JSON schema strictly. If estimated_output_tokens exceeds [MAX_OUTPUT_TOKENS], clamp the estimate and flag a warning. If the projected_cost exceeds [COST_BUDGET], the application must execute the [BUDGET_EXCEEDED_ACTION]: either block the call, route to a cheaper model, request human approval, or truncate context. Log every preflight decision—including the estimate, actual cost post-invocation, and the go/no-go outcome—to build a feedback loop for calibrating the estimator's accuracy over time.

Retry and Fallback Logic: If the preflight prompt itself fails (invalid JSON, timeout, or model error), do not silently proceed with the expensive call. Implement a fail-closed default: either block the invocation or route to a conservative fallback model. Retry the preflight once with a backoff; if it fails again, escalate to a human operator or a dead-letter queue for manual review. Observability: Emit metrics for estimate error rate (absolute difference between projected and actual cost), budget-block frequency, and preflight latency. These metrics are critical for tuning the [COST_ESTIMATE_ACCURACY_TARGET] and deciding when the preflight model itself needs an upgrade. What to avoid: Do not use the preflight prompt to make the final routing decision—it estimates cost, not quality. Do not skip the preflight for

low-risk

requests without evidence; cost overruns often accumulate from high-frequency

low-cost calls. Finally

never hard-code pricing in the prompt; always inject `[PRICING_CONFIG