This may seem self-evident, but I wanted to put it through a small experiment: saying what I need the first time should cut down on wasted AI work.
I wanted to find something practical I could contribute to greener AI usage. Prompting seemed like a useful place to start because it’s something I can change myself. A request like “commit msg” or “make this JSON” leaves the model to guess what I want. If I already know the format and requirements, putting them in the first message might save a correction and another trip through the model. So I built a small experiment to see how much difference that made.
TL;DR: lazy prompts caused 103 correction turns and used 160,799 tokens. Front-loaded prompts caused 17 corrections and used 45,463 tokens. I used the same model, task set and output limit for both. The front-loaded prompts used 71.7% fewer tokens and got 134 of 140 attempts past the checker, compared with 96 for the lazy prompts.
I put the full methods and results in the white paper, Prompt Clarity, Correction Churn, and Token Efficiency.
The test
I wrote 15 machine-checkable tasks covering the kind of little jobs I regularly hand to an LLM: JavaScript functions, parsing CSV and log lines, date math, a regex, a commit message, some constrained writing, and a few tiny questions where a detailed prompt should probably be overkill.
Then I wrote two prompts for each task.
The lazy version was what I might actually type:
commit msg
The front-loaded version included the details that were otherwise sitting in my head:
Write a git commit message using Conventional Commits. Use the function name as the scope, keep the first line under 72 characters, then add one sentence explaining why.
I ran each prompt with thinking off and with the model’s default thinking. Each combination ran five times because the model isn’t deterministic. A failed answer got exactly one correction with the verifier output, then it was done.
One task had a sandbox problem so I dropped it from the final results. That left 14 tasks, 280 first attempts and 120 correction attempts, or 400 scored responses. This was a little more Bedrock traffic than I expected when I had the idea.
I also wrote the answer checkers first. Before I sent a single prompt to the model I made 15 known-good answers and 15 plausible bad ones. All of the good answers had to pass and all of the bad ones had to fail. This caught two mistakes in my original checks while fixing them was still free (yay!).
The numbers
Here is the whole result with the two thinking settings combined:
| Lazy prompts | Front-loaded prompts | |
|---|---|---|
| First-attempt passes | 37/140 | 123/140 |
| Correction turns | 103 | 17 |
| Solved after one correction | 96/140 | 134/140 |
| Total recorded tokens | 160,799 | 45,463 |
| Tokens per solved attempt | 1,675 | 339 |
The lazy prompts used 3.54 times as many tokens. They also created 86 extra correction turns, which is 86 extra opportunities for me to sigh at my computer and type what I should have typed the first time.
The input side surprised me. The detailed prompts were obviously longer, but the front-loaded arm still used 68% fewer input tokens overall. Every correction had to send the conversation back through the model along with the failed response and the verifier details. Saving 100 tokens at the beginning is not much of a bargain when it creates a 1,000-token second turn.
Output was even more lopsided. Lazy prompts produced 71,455 output tokens. Front-loaded prompts produced 17,247. A clear prompt was longer going in and much shorter coming out, which sounds a lot like the rest of programming now that I think about it.
The format tasks were brutal. Lazy prompts passed zero of 40 first attempts. That includes a perfectly reasonable commit message which failed because I never told the model which convention I wanted. A skeptic could say “of course it failed, you didn’t tell it the rules,” and that skeptic would be right because the rules were in my head and getting them out was the point of the test.
Where it got weird
The detailed prompt didn’t win everything. On the constrained rewrite task the lazy prompt solved six of ten attempts and used 12,906 tokens. The front-loaded prompt solved four and used 15,462. It kept missing the 60-word limit even though the limit was right there in the prompt. No clue. I left the result in because removing the one task that went the wrong way would make this look like an ad.
A couple of responses had the right answer but put something else last, so my extractor graded the wrong bit. For the date question every lazy response contained the correct answer, 199, but most added a caveat afterward and my last-number extractor grabbed the caveat. Another task contained the correct bug fix followed by an example, so the extractor tried to run the example by itself.
Those still matter to me. If I ask for something that a script needs to consume, making me dig the answer out of three alternatives is not a pass. However, it would be dishonest to say the model couldn’t do the date math. It did the math and then talked itself out of the grade.
I expected at least one of the three tiny tasks to favor a lazy prompt. None did. Asking for only the capital city, only the JavaScript expression, or only the number was enough to cut the extra response without adding much to the request. My prediction was wrong and the tiny prompts stayed in too.
Green Mode
There was another useful detail hiding in the API.
On the Sonnet 5 route I used, adaptive thinking is the default. Leaving the thinking parameter out turns it on. Turning it off requires sending an explicit disabled setting. With no extra setting I got the version that used more tokens in both prompt arms.
For the front-loaded prompts, thinking off solved 67 of 70 attempts after correction and used 20,236 tokens. Default thinking also solved 67 and used 25,227. For the lazy prompts both settings solved 48 of 70, while default thinking used another 4,867 tokens.
That makes me want to try a Green Mode: start with a less expensive thinking setting and a prompt that actually says what I need, then opt up when the result needs more work. For these tasks, the extra thinking used more tokens without getting more attempts past the checker. I’d like the interface to make that choice easy instead of requiring everyone to know which API parameter turns it off.
I’m not the first person to connect shorter model responses with lower environmental cost. A 2025 ACL paper called Brevity is the Soul of Sustainability tested response-length controls across several models and measured lower inference energy while preserving its quality measures. I like that somebody gave the obvious idea a proper experiment and a much better title.
My test is smaller and closer to the annoying little tasks I do all day. I see this as one idea that could help green AI initiatives: make it easier to state the requirements up front and use a setting that fits the task. In this batch that meant fewer corrections and fewer tokens per solved attempt. That’s enough to make me want to keep testing it.
I’m going to try the same harness on a batch of real work tasks next. I expect that set to be messier, mostly because my actual requirements are usually messier. At least now I have a number for how expensive “I’ll explain it in the next message” can get.