llm-cost-latency-budget

LLM Cost & Latency Budget Skill

LLM features have a unit cost and a tail latency that demos hide and production exposes. This skill does the token math up front — what one request costs, what a million cost, where the p95 latency comes from — and lays out the levers (model tiering, caching, prompt trimming) so cost and speed are designed, not discovered.

Required Inputs

Ask for these only if they aren't already provided:

• The request shape — typical system prompt, user input, retrieved context, and output sizes (in rough tokens).
• Volume — requests/day now and at target scale; peak concurrency.
• Models in play — candidate model(s) and their per-token input/output prices.
• Targets — acceptable cost per request (or per user/month) and the latency users will tolerate (p50 / p95).

Output Format

Cost & Latency Budget: [feature]

1. Per-request token math — a table estimating tokens in/out per call, and the resulting cost at each candidate model's price.

Component	Tokens	$ in	$ out
System prompt
Retrieved context
User input
Output
Per request		$x

2. Monthly projection — per-request cost × volume, at current and target scale; the headline number leadership will ask for.

3. Model tiering — route easy requests to a cheaper/faster model and only escalate hard ones (cascade); show the blended cost. Often the single biggest saving.

4. Latency — where the p95 comes from (model TTFT + output length + retrieval + network), the target, and how streaming changes perceived latency even when total time is unchanged.

5. Cost levers — ranked by impact: prompt/context trimming, caching (prompt cache + response cache for repeats), shorter outputs (max_tokens), batching, tiering, and "do you need the model at all for this path."

6. Guardrails — per-user / per-day rate limits, a max-tokens cap, a spend alert threshold, and a kill switch — so a bug or abuse can't produce a surprise invoice.