Token Bloat Detection in System Prompts Prompt

This prompt is for prompt engineers and infrastructure teams who need to audit the token growth of system prompts across versions. The job-to-be-done is identifying redundant instructions, stale policies, and accumulated cruft that inflate per-request cost without adding behavioral value. Use this when you have a version history of system prompts and want a structured diff analysis that flags specific lines or sections contributing to token bloat, not just a raw token count comparison.

The ideal user is someone responsible for prompt performance and cost efficiency in production. You should have access to at least two versions of a system prompt in plain text, along with approximate token counts or the ability to estimate them. The prompt works best when you provide the full prompt text for each version, not just summaries. It is designed to produce a diff that highlights additions, unchanged sections, and removals, with a focus on instructions that are duplicated, contradictory, or no longer relevant to the current product behavior. The output should include a severity ranking for each flagged item so you can prioritize cleanup.

Do not use this prompt for real-time cost monitoring or for analyzing user messages, tool call logs, or conversation traces. It is specifically for static system prompt text comparison. Avoid using it when you lack version history or when the system prompt is generated dynamically at runtime from multiple fragments—in that case, you need a runtime token attribution trace, not a static diff. If the system prompt contains sensitive business logic or security policies, ensure the analysis runs in a controlled environment and review the output before sharing it broadly. The next step after running this prompt is to take the flagged items and decide which to remove, consolidate, or rewrite, then measure the token savings in a staging environment before promoting the cleaned prompt to production.

This prompt template is designed to be dropped into your prompt versioning workflow. It accepts two versions of a system prompt and produces a structured diff analysis focused on token consumption, redundancy, and staleness. The output is a JSON report that can be ingested by your cost monitoring dashboard or CI/CD pipeline. Use this template when you have access to the full text of at least two system prompt versions and need to quantify growth before it silently inflates your per-request costs.

textCopy
You are a prompt architecture auditor specializing in token efficiency and instruction hygiene.

Analyze the two system prompt versions below and produce a structured diff report. Focus on token bloat, redundant instructions, stale policies, and accumulated cruft that increases per-request cost without adding value.

[SYSTEM_PROMPT_VERSION_A]

[SYSTEM_PROMPT_VERSION_B]

[OUTPUT_SCHEMA]

[CONSTRAINTS]

To adapt this template, replace the placeholders with your actual data. [SYSTEM_PROMPT_VERSION_A] and [SYSTEM_PROMPT_VERSION_B] should contain the full text of the two prompts you are comparing. [OUTPUT_SCHEMA] must define the exact JSON structure you expect, including fields for token delta, redundant blocks, stale policies, and a severity score. [CONSTRAINTS] should specify rules such as ignoring formatting-only changes, setting a minimum token threshold for flagging growth, or requiring line-level citations for every flagged issue. For high-stakes production prompts, always route the output through a human review step before accepting removal recommendations, and validate the JSON schema programmatically before ingestion.

This prompt is designed to run as a scheduled audit or a pre-release gate, not as a real-time request-path component. The primary integration point is your prompt versioning system or CI/CD pipeline. Before each deployment, or on a weekly cadence, fetch the current system prompt and its immediate predecessor from your prompt registry. The prompt expects two versions as input: [CURRENT_SYSTEM_PROMPT] and [PREVIOUS_SYSTEM_PROMPT]. If you maintain more than two active versions, run pairwise comparisons sequentially and aggregate the results into a trend report. The output is a structured JSON diff that your harness can parse to decide whether to block a release, file an automated ticket, or simply log the growth trend for later review.

Validation and gating logic should be applied to the structured output. Parse the total_token_delta and growth_percentage fields. Define thresholds in your harness: for example, a token increase greater than 15% or an absolute increase exceeding 200 tokens might trigger a warning. A growth percentage above 30% could block the release and require manual approval. Validate that the bloat_categories array contains recognized categories (redundant_instruction, stale_policy, accumulated_cruft, duplicate_constraint, unused_example). If the model returns an unrecognized category, log it as an anomaly but do not fail the pipeline—this prevents brittle parsing from blocking deployments. Wrap the LLM call in a retry with a simple schema validator: if the response fails to parse as valid JSON matching your expected schema, retry once with a stricter [OUTPUT_SCHEMA] constraint before falling back to a human review ticket.

Model choice and cost matter here because this is an operational audit, not a user-facing feature. A smaller, cheaper model (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned open-weight model) is usually sufficient for diff analysis. The input tokens will be dominated by the two system prompts themselves, so ensure your harness logs the token cost of each audit run. If you run this check on every commit to a prompt file, batch audits or use prompt caching on the previous version to reduce cost. Store the structured output in your observability platform alongside the prompt version hashes so you can correlate token growth with latency and cost regressions in production traces.

Human review integration is essential for high-risk domains. When the harness detects a bloat category of stale_policy or flags instructions that appear to contradict newer policies, route the diff to a prompt engineer for manual inspection before any automated refactoring. Do not automatically remove or rewrite system prompt content based solely on this prompt's output—the model can misidentify intentional redundancy as bloat. Instead, use the output to generate a review ticket with the specific flagged sections, the suggested action, and a link to the full diff. Over time, track which bloat categories correlate with actual production issues to tune your thresholds and reduce false positives.