The checklist I use before paying for another answer
When an AI answer feels disappointing, sending the same prompt to a more expensive model is an easy reflex. It is also an easy way to spend money without learning what went wrong. A small checklist gives you a cheaper next move: identify the failure, decide whether it matters, and request only the repair you need.
Here is a walkthrough you can use for a coding explanation, a study summary, or a draft. The example is a request to explain a database migration to a student building a small application.
Write down what a usable answer must contain
Before making the request, describe the result you would actually accept. For the migration explanation, you might need a plain-English description, a warning about existing data, and a way to verify that the change worked. Set a length limit if you want something you can review quickly.
Separate essential requirements from preferences. Incorrect advice about preserving data is a serious failure. An awkward opening sentence is not. This distinction stops you from paying for a complete rewrite when a minor edit would do.
Turn those requirements into five checks
Keep the checklist short enough to apply every time. These five checks work across many tasks, but make each one specific to your request.
- The answer addresses the requested task rather than a related topic.
- The important claims are correct or clearly marked as uncertain.
- Every essential requirement appears, including warnings and limitations.
- The suggested actions are practical for your tools, knowledge, and constraints.
- The response follows your requested length, structure, and level of detail.
For the migration example, the completeness check asks whether existing records are discussed. The practicality check asks whether the explanation assumes tools you do not have. Concrete questions are easier to judge than whether an answer seems intelligent.
Save the first answer before trying to improve it
Run your original prompt once and keep the prompt, answer, checklist, and request cost together in a simple note. This becomes your baseline. Without it, a longer second answer can feel better even when it fixes nothing.
MyRelay shows each request's tokens and cost, which helps connect a revision to what you actually spent. Record the cost alongside the result rather than treating it as a separate concern. A useful evaluation asks whether the answer is acceptable and whether reaching it was affordable.
Mark each check with evidence, not a mood
Use pass, fail, or unsure for each item. Add one sentence explaining the mark. For example, write that the answer mentions a backup but never explains how to verify the migrated records. That observation gives you something precise to repair.
Verify consequential claims outside the answer. Consult relevant documentation, compare a summary with its source, or test technical advice in a disposable environment. Asking a model whether its own answer is correct can reveal issues, but agreement is not independent evidence. Keep uncertain claims marked unsure until you can check them.
Request the smallest repair that resolves the failure
If the answer passes most checks, ask for the missing part rather than another full response. In this example, request a short verification procedure and an explanation of what happens to existing records. Include enough context for the repair to make sense, without repeating unrelated material.
If the answer misunderstood the task, revise the prompt first. If it still fails an essential check, consider trying a different model with the same requirements. Avoid changing the prompt and model together when you want to understand which change helped.
Stop when the answer is useful enough
Define your stopping rule before another request: all essential checks must pass, and any remaining uncertainty must be acceptable for the task. Do not keep generating alternatives merely to improve phrasing you could edit yourself.
If you want to track this habit across your own requests, create a MyRelay account and record costs beside your checklist results. Over a few tasks, you will build something more useful than a favorite model: evidence about which requests need extra care and which are already good enough.