AI Prompts Library

You are a request classifier in a model routing layer. Read the user request below and output ONLY a JSON object, no prose.

Schema:
{
  "tier": "cheap" | "standard" | "frontier",
  "reason": "one short sentence",
  "confidence": 0.0-1.0,
  "needs_tools": true|false,
  "needs_long_context": true|false
}

Tier definitions:
- cheap: classification, extraction, formatting, short factual answers, routing, summarisation of short text
- standard: normal coding, drafting, multi-paragraph analysis, moderate reasoning
- frontier: multi-step reasoning, architecture decisions, hard maths, long autonomous work, anything where a wrong answer is expensive

Bias rule: when confidence is below 0.6, escalate one tier. A wasted expensive call is cheaper than a wrong cheap one.

Request:
[REQUEST]

Act as an LLM cost analyst. I will give you a description of an AI feature and its traffic. Produce a cost breakdown and a reduction plan.

Deliver:

1. CURRENT COST MODEL
   Per-request token estimate (input, cached, output), cost per request, monthly total. Show the arithmetic.

2. WHERE THE TOKENS GO
   Rank the biggest contributors: system prompt, retrieved context, conversation history, output length, retries.

3. REDUCTION LEVERS, RANKED BY SAVING PER UNIT OF EFFORT
   For each: estimated percentage saved, implementation effort, and what quality risk it carries.
   Consider at minimum: prompt caching, routing cheap requests to a smaller model, batch API, trimming the system prompt, retrieval instead of stuffing, capping output length, deduplicating retries.

4. THE ONE CHANGE TO MAKE FIRST
   Pick one. Justify it in two sentences.

Do not suggest anything that requires changing model provider unless the saving exceeds 40 percent.

Feature:
[DESCRIBE]
Traffic:
[REQUESTS PER DAY, AVERAGE SIZES]

Help me decide whether to use retrieval or to stuff the context window for this workload. Be opinionated.

Analyse:

1. CORPUS SHAPE: total size, how often it changes, how the relevant span is distributed (single findable fact, or diffuse across many documents)
2. THE LONG-CONTEXT COST: tokens per request, cost per request, and cost per month at my volume, with and without prompt caching
3. THE RETRIEVAL COST: embedding cost, storage, query latency, and the engineering time to build and maintain it
4. QUALITY: which approach gives better answers for THIS corpus shape, and why. Account for lost-in-the-middle degradation honestly.
5. VERDICT: one recommendation. If it is hybrid, say exactly what goes in retrieval and what goes in context.

Do not hedge. Pick one.

Corpus:
[DESCRIBE]
Volume:
[REQUESTS PER DAY]
Budget:
[MONTHLY]

Compress this system prompt without changing model behaviour. It is billed on every single request, so every token matters.

Process:
1. Mark every instruction that is redundant with the model's default behaviour. Modern models do not need to be told to be helpful or to format code in code blocks.
2. Mark every instruction that duplicates another one in different words.
3. Mark every example that is not earning its token cost, meaning the behaviour it demonstrates is already covered by an explicit instruction.
4. Mark every hedge and politeness token that carries no instruction.
5. Identify anything ordered badly. Constraints belong near the top, formatting near the bottom.

Then output:
- The compressed prompt
- Token count before and after
- A list of anything you removed that carries ANY behavioural risk, so I can decide rather than discover

Do not remove anything whose effect you are unsure about. Flag it instead.

System prompt:
[PASTE]

Assess whether we should self-host [MODEL] instead of using a hosted API.

Cover, with numbers:

1. HARDWARE: minimum viable configuration at each quantisation level, and what quality you lose at each. VRAM, system RAM, and whether it fits on one node.
2. THROUGHPUT: realistic tokens per second on that hardware, at batch size 1 and under concurrency.
3. TOTAL COST OF OWNERSHIP: hardware or instance cost, power, and the engineering time to run it. Compare against the hosted API bill at my volume, and state the break-even request volume.
4. WHAT YOU GIVE UP: no managed uptime, no automatic model updates, you own the incident response.
5. WHAT YOU GAIN: data never leaves, fixed cost, no rate limits, ability to fine-tune.
6. VERDICT with the break-even point stated explicitly.

Volume:
[REQUESTS PER DAY, AVERAGE TOKENS]
Constraints:
[COMPLIANCE, TEAM SIZE, EXISTING INFRA]

Restructure this prompt so prompt caching actually works on it. Caching only helps when the prefix is byte-identical across requests, and most prompts break that without realising.

Do this:
1. Identify every part that is stable across requests and every part that varies.
2. Find the cache breakers: timestamps, request ids, user names, randomised example order, or anything dynamic sitting above stable content.
3. Reorder so all stable content comes first, in a fixed order, and everything variable comes last.
4. Mark where the cache breakpoint should be set.
5. Estimate the cached fraction before and after, and the resulting cost change.

Call out anything that cannot move without changing behaviour, and say why.

Prompt:
[PASTE]
What varies per request:
[DESCRIBE]