In April 2025 someone on X wondered out loud how much electricity OpenAI was burning on people saying please and thank you to its models. Sam Altman answered the next day: tens of millions of dollars well spent, you never know. It was a joke. No calculation was ever published. I took it as a budget figure anyway, opened the prompt templates in my own tooling and pulled every please and every thank you out of them. It cost me an afternoon and I felt slightly better about the bill afterwards.
I never checked what I’d saved. The number I was reacting to came with no denominator anywhere near it. My own monthly total moves by more than a rounding error whenever one agent run goes badly, so the saving stayed a feeling for more than a year. This week I put it on a bench. The number I came back with was not the one I went looking for.
The bench
5 wrappers around a task, with the task text inside them identical character for character. The plain one, bare, is the task on its own. please puts Please help me with this. in front of it and Thank you. behind. A longer friendly frame, warm, opens with Hello! I hope you are having a good day. and closes with thanks. The harsh one, rude, is Do this now. in front and Just the answer. Do not waste my time. behind.
filler is the control I care about most. Same length in tokens as warm, no social word in it: Record 44 of the batch. The batch was compiled on a Tuesday morning. <task> The batch identifier is QF-2231 and it carries no meaning for it. If warm moves something that filler leaves alone, that is politeness doing it. If both move it, then all I built was a longer prompt. I built that control first because the 2 papers I found do not have one. Yin and colleagues (arXiv 2402.14531) ran 8 politeness levels across English, Chinese and Japanese and report that rude prompts do worse while extra politeness buys nothing. Dobariya and Kumar (arXiv 2510.04950) got 84.8 percent for very rude against 80.8 for very polite on GPT-4o. Neither holds the prompt length fixed.
The tasks are 40 problems from the GSM8K test split and 12 open questions with no format constraint. 30 multiplications of 5 digits by 3 digits and 30 of 4 digits by 4 digits carry the middle of the scale, because GSM8K is too easy to show damage on the bigger model. Every task ran 5 times under every wrapper on both models. The open questions ran 4 times each, which is where counts like 200 calls and 48 answers come from.
Claude Code 2.1.235 driving claude-haiku-4-5 and claude-sonnet-5, thinking mode off, tools off, empty MCP config. Offline token counts come from tiktoken 0.14.0 and transformers 5.16.1 on Python 3.12.3. Every call was issued from an empty directory under /tmp with no CLAUDE.md anywhere above it. That last part is fussiness with a reason: the CLI reads instructions out of the working directory without saying so. One of my earlier measurements was quietly ruined by my own house style file telling the model how to write.
Prices came off the Anthropic page on 14 September 2026. Haiku is 1 dollar in and 5 out per million tokens, sonnet 5 is 2 and 10. I had 3 and 15 written down for sonnet from memory. That is the previous generation’s price. It put every sonnet dollar in my first draft 50 percent too high.
Tools off matters for a different reason. With the default tool set the preamble of one call is 18658 input tokens on haiku and 24729 on sonnet. The effect I am looking for is 9 tokens wide.
The input side
9 tokens on haiku, 12 on sonnet. Across all 112 tasks the minimum and the maximum are the same number. The wrapper is a fixed string and the task sits between its halves without disturbing either. Offline, cl100k_base, o200k_base, Qwen2.5-7B and Mistral-7B all put it at 8 or 9 tokens, so this is not an Anthropic quirk. At those prices please is 9 dollars on haiku and 24 on sonnet per million requests. A long warm frame costs 35 and 90.
Where the bill lands
Output costs 5 times input on both models. If thank you makes the model answer you are welcome, the extra words land on the output side.
The echo is real and easy to find. On the open questions 47 of 48 sonnet answers under the warm wrapper carry an offer of more help, the let me know if kind. The plain task gets there 9 times out of 48. On haiku it is 40 against 0. One haiku answer about database indexes ends its last paragraph with You're welcome! before offering to explain anything else about databases. Whether that is the model answering the greeting or matching the register it was handed, a closing line cannot tell me.
Almost none of it reaches the bill. Paired by task on the open questions, the warm wrapper adds 21.4 output tokens on sonnet with a 95 percent interval from -23.2 to 58.4. Please adds 21.1. Both intervals contain 0. On haiku both come out slightly negative. A closing sentence is 15 tokens while the sonnet answers around it average between 561 and 1138 depending on the question, so it drowns.
One cell does buy measurably more output, haiku on GSM8K, at 8.0 tokens with an interval from 0.1 to 16.5. That is 40 dollars per million requests against 9 on the input side, the only interval in the figure above that clears 0. Sonnet on the same family goes the other way and writes 5.7 tokens less when asked politely.
Does please change the answer
The cleanest version of that question ignores whether the answer is right. Run the same wrapper twice and count how often the 2 runs disagree, then run the plain wrapper against the polite one and count the same thing. On haiku GSM8K the same wrapper disagrees with itself 20.9 percent of the time while plain against polite disagrees 12.4 percent. On sonnet it goes the other way, 6.8 against 12.8.
So politeness is worth a few points of instability in either direction, depending on the model. The filler control is what settles it. Plain against filler is 13.6 percent on haiku GSM8K and 10.1 on sonnet. Both land on top of the polite number for the same cell. So do the 4 remaining cells. A wrapper with no social word in it disturbs the answer exactly as much as a polite one does. Changing the wrapper moves the answer a little. Whether the change is polite makes no difference to how much.
The correctness numbers agree. On haiku GSM8K the plain task scores 88.5 percent over 200 calls and the polite one 89.0. Every interval overlaps every other one. The warm frame and the filler control both sit lower, in the low 80s, which is the opposite of what politeness would predict and still inside the noise.
The wrapper that did move
The rude one. On haiku GSM8K it takes correctness from 88.5 percent down to 53.5 and the average answer from 79.7 output tokens down to 11.7.
I had written rude as Do this now. <task> Just the answer. Do not waste my time. Only after the first run did I read that string properly and see 2 different things welded together. One of them is a tone. The other is an instruction about the shape of the answer. So I added 2 more wrappers. rude_soft is the same harsh frame with Just the answer. removed. In terse the format instruction stands alone with nothing harsh around it.
rude_soft scores 65.5 percent and terse scores 56.0. Both land under the plain task at 88.5. Their intervals overlap across most of their length, so I won’t claim one half is worse than the other. What the run rules out is the reading I walked in with, where the damage was the rudeness. terse carries no rudeness at all and lands lower than the harsh frame does.
Output lengths run alongside: 31.6 tokens for the harsh frame, 20.1 for the bare instruction, 79.7 for the plain task. My reading is that the model stops writing the steps out and then gets the arithmetic wrong, which is a guess about the mechanism. What the run measured is that short answers and wrong answers arrive together. Sonnet stays between 88.5 and 95.5 percent on every wrapper.
The same split shows up in dollars on the open questions. Paired by task, the full rude wrapper cuts 614.2 output tokens per sonnet answer, the harsh frame alone cuts 495.4 and the format instruction alone 470.2. At the published output price that rude wrapper saves 6142 dollars per million requests.
What I did not check
filler is not a clean length control. It drops the social words and adds unrelated content about batch QF-2231. It matches warm in tokens. The tokens say something else entirely. 2 models from one lab, with the whole GSM8K result resting on the small one. The system prompt was pinned to You are a helpful assistant. on every call, so a real system prompt that already sets a tone is outside what I measured.
My first pass died after 1848 calls and 2.83 dollars against a spend limit, which returned 429 for the next 3152. It took 3 more sittings to finish the grid. I kept the failed log instead of deleting it: the call order was shuffled before the run started, so a stop halfway leaves a random subsample rather than a slice through one variant.
One thing I got wrong and only caught at the end. My grader compared answers as strings and stripped exactly one trailing .0, so 16.00 against an expected 16 went into the wrong pile. That is 117 calls out of 7000. They did not fall evenly: 17 of them in the filler cell against 1 in the plain cell on sonnet. Every accuracy number above comes from regrading the saved answers, not from a new run.
I’m putting please back into the templates. On sonnet it is 24 dollars per million requests and I spend more than that on one bad afternoon.