What this prompt does
This prompt runs a compression pass over an existing prompt to cut token usage while preserving output quality. It strips redundant instructions and filler, replaces verbose explanations with concise directives, and uses structured formatting like numbered lists and tables to pack information densely. It then identifies which context belongs in few-shot examples versus the system prompt, counts tokens before and after, and applies a caching strategy so stable context is not re-billed on every call.
The variables ground the optimization in real numbers. [original_prompt] is the prompt being trimmed — the longer it is, the more there is to compress. [tokenizer] measures the before/after token counts accurately, and [model_provider] determines which caching strategy applies, such as system-prompt or prefix caching. [test_count] sets how many cases the prompt runs to confirm quality did not drop, and [volume] estimates monthly cost savings at your real request rate. The prompt also designs a tiered system — a short version for simple inputs, a full version for complex ones — and finds the minimum viable prompt.
When to use it
- A prompt is heading into high-volume traffic and the token bill will add up fast.
- You suspect a prompt is bloated with filler and want a measured trim, not a guess.
- Stable context could move into a cached prefix to avoid re-billing it on every request.
- You want a tiered prompt — short for simple inputs, full for complex — to save tokens on the easy cases.
- Quantifying cost savings at a specific
[volume]before committing to a change. - Finding the minimum viable prompt that still produces acceptable output.
Example output
Expect a compressed version of your [original_prompt] with redundant instructions removed and verbose passages tightened into directives, plus before/after token counts measured with [tokenizer]. You also get a caching strategy tailored to [model_provider], a tiered short-and-full prompt design, a quality comparison across [test_count] test cases, an estimated monthly cost saving at [volume], and a note on the minimum viable prompt that still holds quality.
Pro tips
- Feed in a genuinely long
[original_prompt]; there is little to compress in an already-tight prompt, and the savings scale with the bloat you start from. - Move stable context into cached prefixes for
[model_provider]rather than deleting it — caching keeps the context but stops re-billing it on every call. - Always run the
[test_count]quality comparison; aggressive trimming can quietly degrade output, and you want evidence the short version still holds up. - Use the tiered design honestly — route simple inputs to the short prompt and reserve the full prompt for complex cases, so you only pay for context when it is needed.
- Measure with the right
[tokenizer]; estimating token counts by eye undercounts and makes the cost-savings figure unreliable. - Treat the minimum viable prompt as a floor to test against, not necessarily the version you ship — sometimes a slightly fuller prompt is worth the tokens.
