Writing Token-Efficient Prompts

Writing Token-Efficient Prompts: Token Counter Guide

With enough request volume, a 500-token rewrite in a system prompt can become a daily savings line item.

Anthropic's pricing page bills Claude Sonnet 4.6 at $3 per million input tokens, so a 2,000-token system prompt sent 100,000 times per day costs 200 million input tokens per day in that field alone.¹ At that rate, the system prompt costs $600 per day before a single word of user content is counted. Reducing that same system prompt by 500 tokens saves $150 per day at the same volume, from editing text, not changing models or infrastructure.

Which prompt elements waste the most tokens

The most common token waste in system prompts is redundant phrasing. OpenAI's prompt-engineering guidance explicitly recommends reducing "fluffy" and imprecise descriptions, while Anthropic's prompting best practices say Claude responds well to clear, explicit instructions.²³ Instructions like "Please always make sure to" cost three or four tokens before the actual instruction begins. "Always be helpful, always be accurate, always be clear" repeats the modifier word three times when "Be helpful, accurate, and clear" expresses the same constraint in six tokens instead of ten.

Furthermore, example outputs embedded in system prompts are extremely token-dense: a three-example format demonstration might consume 500 tokens, while a single concise format description achieves the same effect at a fraction of the cost. Structured output constraints can replace wordy prose when the model only needs a stable format, which is why schemas are often a cleaner compression lever than long formatting instructions.⁴ Auditing the example block is often the single highest-ROI compression step in any system prompt review.

Cutting system prompt bloat before the first API call

Review every sentence that repeats a constraint already covered elsewhere. If a line only softens the tone or restates the goal, remove it before measuring the final count. A system prompt that starts at 800 tokens and grows to 2,500 tokens over several months of iterative additions increases per-request input cost by 212 percent without any corresponding improvement in output quality; each redundant sentence is a recurring charge on every single API call, which means the cumulative cost of prompt bloat far exceeds what the token count alone suggests when multiplied across millions of daily requests.

Rewriting instructions for fewer tokens

Effective compression uses three techniques: direct imperative sentences, removal of qualifiers, and list formatting over prose. Anthropic recommends numbered lists or bullet points when order or completeness matters, and OpenAI recommends being specific about desired context, outcome, length, format, and style.²³ Consider this comparison: "You are an expert assistant that always tries to provide detailed, thorough, and comprehensive responses while being helpful and accurate" runs to 31 tokens. In contrast, "Give detailed, accurate responses." costs only 5 tokens. Between those two instructions, the expected behavior is identical.

Consequently, each compressed instruction frees up tokens for actual content. For response format instructions, a JSON schema or a short example is often more token-efficient than prose describing the same structure. OpenAI's Structured Outputs guide says schema adherence can make prompting simpler because you do not need strongly worded prompts to achieve consistent formatting.⁴

Rewriting prompt instructions with direct imperatives

Start with the outcome you want, remove polite filler, and keep the shortest instruction that still preserves the behavior. Phrases like "please make sure to always try your best to" add four or five tokens before the actual instruction begins, and when that pattern appears across ten different constraints in a system prompt, the polite filler alone can consume 40 to 50 tokens that contribute nothing to the model's understanding of the task; replacing each softened instruction with a direct imperative like "Always do X" or "Return only Y" preserves the intended behavior while reclaiming token budget for content that actually improves output quality.

Measuring compression gains before and after

Compression without measurement is pure guesswork that cannot tell you whether your rewrite actually saved tokens or merely changed the wording. OpenAI's token-counting guide says the input token count endpoint accepts the same input format as the Responses API and returns the exact count the model will receive for billing purposes.⁵ The correct measurement process is: paste the original system prompt into the token counter and record the baseline count, rewrite the prompt with your compression changes, paste again, and compare the two numbers directly. Comparing before and after counts surfaces exactly which specific rewrites save tokens and by how many, giving you concrete data to guide further optimization.

For team prompt engineering, sharing the before and after token counts alongside the rationale for each change builds shared intuition about which kinds of edits yield the highest-ROI savings. In production, log the system prompt token count as a time-series metric so gradual growth from incremental additions becomes visible long before it materially affects your monthly bill.

Compression gains across multiple prompt layers

Compression gains compound across every layer of a prompt that contains redundancy. A typical production prompt has three layers: a system instruction, a few-shot example block, and a user message template. Each layer can often be reduced by 30% independently. For a prompt with a 200-token system instruction, a 600-token example block, and a 100-token user template, a 30% reduction in each layer saves 270 tokens per request. At 500,000 daily requests on Claude Sonnet pricing, that saving is $405 per day from editing text alone.¹

Example blocks are often the highest-density compression opportunity because developers copy full production outputs into the few-shot block without trimming them. Replace verbose examples with minimal format demonstrations: a 30-token compact version showing structure only achieves the same formatting effect as a full 200-token example output. The model does not need to see a full-length example to learn the output format; a minimal representative structure at one-fifth the length is sufficient.

Making compression gains measurable and visible to your team

Because compression gains are invisible without a baseline measurement, building a before/after counting habit into your prompt editing process is essential. Before any edit, paste the full prompt into this tool and record the token count. After the edit, count again. The difference is the per-request saving; multiplied by daily request volume and the model's input price, it becomes the daily dollar saving from that one editing pass.

Tracking token count in pull requests

For team prompt engineering, include before and after token counts in pull request descriptions alongside quality metrics. Prompt-compression research across 13 datasets found that moderate compression can improve long-context performance, but that compression can also increase hallucinations when information is lost.⁶ Teams that see token counts alongside quality scores develop intuition about which edits are high-ROI versus which are cosmetic changes that save only a few tokens. Over time, this culture of token awareness prevents system prompts from growing unchecked. Treat a 20% growth in system prompt token count since the last review as a trigger for a compression audit, the same way you would treat a 20% growth in infrastructure spend.

Pull request descriptions also give reviewers a natural checkpoint to question unexplained token growth, because a system prompt that creeps upward between reviews rarely triggers a dedicated audit on its own. Getting that before-and-after number takes one pass through a paste-rewrite-paste token diff: note the original count, paste the rewrite, and read the difference directly. Keeping the before and after counts visible next to the diff turns every prompt edit into a measurable change rather than an untracked one.

When to use this

Use the token counter before and after every significant prompt rewrite. You should measure system prompt token counts as part of any prompt engineering review, especially when your API costs increase faster than your request volume.

Examples

"You are a very helpful, knowledgeable, and friendly customer service assistant who always tries to provide accurate, detailed, and complete answers to customer questions while maintaining a professional tone." (43 tokens)

"You are a helpful customer service assistant. Answer questions accurately, concisely, and professionally." (16 tokens). Saves 27 tokens per request. At 200K requests/day on Sonnet: ~$16/day saved.

"When answering, please first think through the problem step by step, then provide your final answer at the end after you've considered all relevant factors." (33 tokens)

"Think step by step. End with your final answer." (9 tokens). Same CoT behavior, 73% fewer tokens.