I trim repeated context before paying for another reply

Start with a prompt you actually use

A shorter prompt is only a saving if it still gets the job done. Removing half the words and then asking three follow-up questions can cost more than sending a clear request once. The useful target is not the fewest possible tokens. It is the smallest request that reliably produces an acceptable answer.

Choose one task you repeat, such as reviewing a function, explaining a lecture topic, or editing a project summary. Save the current prompt and a satisfactory response. This gives you a baseline rather than a vague impression that the shorter version feels better.

Write down what a successful answer must contain

Before cutting anything, identify the result you need. For a code review, that might mean finding correctness bugs, explaining their effects, and suggesting small fixes. You might also need the model to avoid style advice and keep the response under a certain length.

Keep those requirements visible while you edit. They are the meaning you are trying to preserve. Background about your day, repeated requests to be helpful, and several versions of the same instruction usually matter less than the task, necessary evidence, and limits on the answer.

Replace the preamble with a direct request

Consider this everyday prompt:

“I am working on a small project for a class, and I have been trying to understand whether this function has any problems. Could you please take a careful look at it and tell me if there are bugs? I do not really need suggestions about formatting or naming. Please explain what could go wrong and suggest fixes that do not change everything.”

A tighter version keeps the useful instructions:

“Review this function for correctness bugs. Explain each bug’s effect and suggest a minimal fix. Skip formatting and naming advice.”

The shorter request preserves the job, the explanation requirement, and the scope. If the class context imposes a real restriction, such as using only concepts already taught, add that restriction explicitly. Do not make the model infer it from your biography.

Send the evidence needed for this decision

Next, inspect the material attached to the request. A focused question rarely needs an entire conversation, document, or project. Include the relevant function, its expected behavior, and any failing example. Keep surrounding definitions when they affect interpretation.

For a study question, send the passage you do not understand and describe the specific confusion. For editing, provide the text and its intended audience. Replace unrelated history with a brief factual summary, but preserve exact wording when the wording itself is being analyzed.

Be cautious with error messages, numbers, exceptions, and negative instructions. These can look expendable while carrying the detail that determines the answer. Removing “do not change the public interface” is not compression; it changes the task.

Test one cut before making the next

Run the shorter prompt with the same model and comparable settings. Check whether the answer still satisfies your original requirements. If it misses a constraint, restore that constraint directly instead of bringing back the whole preamble.

Try several representative inputs, including one awkward case. A prompt that succeeds once may depend on an easy example. Avoid changing the model while testing the wording, because that makes it harder to tell which change affected the result.

Compare the whole exchange, not just the input

MyRelay shows each request’s tokens and cost, which helps you compare the original and revised versions. Look at output tokens and corrective follow-ups as well as input tokens. A compact prompt that triggers a long, unfocused answer may not improve your total spend.

If you want a single budget for these experiments across supported providers, create a MyRelay account and use a small set of repeatable tasks. Keep the version that completes them clearly at a sensible total cost, not simply the one with the shortest input.

Keep a compact template that earns its space

Save the winning prompt as a reusable template. Include the task, essential context, constraints, and expected answer shape. Add examples only when they resolve a recurring misunderstanding. After an unsuccessful exchange, revise the missing instruction rather than accumulating every previous correction. The habit is simple: remove repetition, preserve decisions, and measure whether the next reply still works.