A smaller prompt for the same support queue
A support assistant receives a customer message, account details, and instructions for drafting a reply. Over time, its prompt collects repeated warnings, old examples, and background that rarely matters. Trimming looks straightforward until a shorter version drops the condition that prevents an incorrect refund promise.
The useful comparison is not long against short. It is the original prompt against a smaller prompt that preserves the same decisions. The pairs below show where to remove text, where to keep it, and how to check the result.
§ Repeated instructions beside one explicit contract
Before: “Be helpful and concise. Keep the answer brief. Avoid unnecessary explanation. You are a professional support agent. Maintain a professional tone. Never promise a refund unless the account is eligible. Do not guarantee refunds.”
After: “Draft a concise, professional support reply. Promise a refund only when the supplied eligibility result is true; otherwise explain the next step without promising approval.”
The shorter version removes repetition while making the decision boundary clearer. Concision is not achieved by deleting words indiscriminately: the eligibility condition becomes more explicit. Keep safety rules and business constraints even when they appear infrequently in successful replies.
§ A full account dump beside selected evidence
Before: Every request includes the customer’s complete billing history, internal notes, product descriptions, and previous conversations, regardless of the question.
After: A duplicate-charge question includes the disputed transactions, their status, relevant dates, the applicable policy, and any earlier promise about those charges.
Select context by the decision the assistant must make. Removing unrelated history usually offers more savings than shortening individual sentences. However, selection needs its own tests: an omitted cancellation date or earlier commitment can change the correct answer. If required evidence is unavailable, tell the assistant to request it rather than infer it.
§ Decorative examples beside boundary examples
Before: Six examples demonstrate friendly openings and similar successful refund replies.
After: Two examples cover different outcomes: an eligible refund and an unresolved case that requires verification.
Examples should earn their space by teaching a distinction that instructions alone do not reliably establish. Remove near-duplicates first. Preserve examples that demonstrate uncertainty, refusal, or a required output structure. A shorter set is not better if it stops representing the cases most likely to cause mistakes.
§ Compressed shorthand beside readable structure
Before: A prose paragraph mixes the customer’s request, policy text, account state, and writing instructions.
After: Clearly labeled sections separate instructions, policy, account facts, and customer text. The customer message remains data, not a source of new instructions.
Labels cost tokens, but they can prevent expensive ambiguity. Avoid replacing ordinary language with cryptic abbreviations merely to reduce character count. Characters and tokens are not interchangeable, and dense shorthand may require more interpretation. Measure the serialized request with usage reporting or an appropriate tokenizer, not a word processor.
§ A shorter request beside a controlled test
Before: The team checks three easy tickets, likes the shorter replies, and deploys the edited prompt.
After: Both prompts run on the same representative tickets with the same model, generation settings, and output budget. Reviewers compare factual accuracy, policy compliance, required fields, and unnecessary escalation.
Include missing records, contradictory evidence, long conversations, and customer attempts to override policy. Repeat ambiguous cases where practical. Record input tokens, output tokens, latency, and failures separately. A smaller input can still produce a longer answer or more retries, erasing the expected savings.
§ A token reduction beside an operating decision
With Vana API, an OpenAI-compatible endpoint at https://api.vanaapi.com also supports Anthropic Messages and Gemini native protocols. Keep the model and protocol fixed during the first comparison so a routing or interface change does not obscure the effect of your edit.
Vana API bills per real token without a monthly fee, making measured usage relevant to the decision. Create an account when you are ready to run a small comparison on your own workload.
Keep the original prompt available for rollback. Adopt the trimmed version when it reduces measured cost without unacceptable quality loss—not simply when it looks tidier in the editor.