An OpenAI bill is a pile of small multiplications. Input tokens times the input price, output tokens times the output price, summed over every call. The number people stare at is the price per million. The number that moves the invoice is how many tokens you attach to a call that happens thousands of times. Token optimization is the unglamorous work of finding the text you are buying over and over, and deleting the part that does not change the answer.
Start with one real request, not with a slogan. Take a production call and split it into pieces you can name: the system text, the tool definitions, the retrieved passages, the user message, and the answer. Count each piece with the same tokenizer the model uses. On this site the cl100k estimate is the right planning figure for GPT-4-class models, inside about 5 percent on English instructions. Paste the system text alone and write the number down. Paste one retrieved passage and write that number down. The first time people do this, the system text is often larger than the user's question.
Here is a scale that matches a small support tool, using list prices checked on 25 October 2026. GPT-4.1 input is $2 per million tokens and output is $8. Suppose the system prompt is 1,800 tokens, the ticket is 400, and the answer is about 250. That is 2,200 input tokens and 250 output tokens. At 20,000 calls a day the input costs 2,200 × 20,000 / 1,000,000 × $2, which is $88. The output costs 250 × 20,000 / 1,000,000 × $8, which is $40. The day is $128 before tax, retries, and the calls that failed and were sent again. None of those figures require a dashboard. They require a count and a price.
Now suppose 600 of those 1,800 system tokens are a policy you pasted twice, or a brand paragraph the model does not need in order to draft a reply. Cutting them saves 600 × 20,000 / 1,000,000 × $2, which is $24 a day, about $720 a month, and it does not touch the output at all. If the cut also makes the answer shorter because the model stops apologizing in the voice of the brand paragraph, you save output tokens too. Output is the expensive side on GPT-4.1. A hundred tokens you do not generate, at $8 per million and 20,000 calls, is $16 a day. People trim adjectives in the prompt and leave a sentence in the instructions that says "write a warm, detailed reply."
The cuts that actually stick are specific. Delete a second copy of the schema. Delete the example that demonstrates a case you no longer handle. Delete the history of why the prompt was written. Keep the constraint that stopped a real incident. "Do not promise a refund amount" is worth more than its tokens the first time it prevents a bad email. "We value every customer" is not. The filler-word note lists the polite phrases that feel free and are not, but politeness is rarely the bulk of a production prompt. Repeated reference material is.
Retrieval is the other silent multiplier. If you stuff eight passages of 500 tokens and the answer only needed one, you bought 4,000 tokens to use 500. A cheaper model will not fix a retriever that returns the whole handbook. Count the passages for a dozen real tickets and see how many the draft actually quoted. Then lower the count you fetch, or fetch a short extract instead of the page. This is still token optimization. The tokens just happen to come from your index rather than from your prose.
Caching and batching change the price, not the token arithmetic. OpenAI's pricing page, as checked in October 2026, prices cached input below the normal input rate and prices the Batch API at about half the live rate for jobs that can wait. A 1,800-token system prompt that is identical all day is the textbook cache candidate, if your provider and your client actually send it in a way the cache can hit. Do not assume the discount. Read the request your SDK sends. Some wrappers rebuild the system text with a timestamp, which looks stable to you and looks new to the cache. A batch job is the right place for a nightly classification of 50,000 rows. It is the wrong place for a chat reply the customer is staring at. The batch-job note is the checklist before you launch one.
Model choice is a real saving and a separate decision. GPT-4o mini at $0.15 per million input tokens, on the same October 2026 list, makes the $88 input day into $6.60. That is a bigger lever than any editing pass, and it is only available if mini can do the task. Run fifty real tickets through both models and compare the replies you would actually send. If mini invents a policy on six of them and GPT-4.1 invents it on one, the cheaper model is not cheaper after a person repairs the six. Token optimization still matters on the cheap model, because a sloppy prompt wastes a larger share of a small context, and because you may move back to the expensive model for the hard slice.
Measure the prompt you will send, not the prompt you remember writing. Tool definitions count. A function schema with long descriptions can outweigh the user message. Image inputs are not the text tokens this site counts. A retry policy that sends the whole conversation again counts twice. Log the token usage the API returns for a day, group it by route, and sort. The top route is the one to edit. Editing the route that runs forty times a day will not show up on the invoice even if you halve it.
A clean edit looks like a diff, not like a new personality. Before: a 1,800-token system text with the policy, the voice, two examples, and a reminder of the policy. After: the policy once, no voice paragraph, one example that covers the case mini got wrong, and the output shape in a single sentence. Count both. If the answer quality on your fifty tickets holds, ship the shorter one. If it slips, put back the example, not the voice paragraph, and count again.
The failure mode is optimizing a prompt you do not evaluate. A shorter prompt that drops "do not invent a tracking number" will look efficient right up until a customer receives a tracking number that does not exist. Put that constraint back. The tokens are cheap next to the repair. Cost work is allowed to make the prompt longer when the added line prevents a class of output you have already seen.
Do the multiplication on paper once. Tokens in, tokens out, calls per day, price per million. Then the arguments about phrasing get smaller. You can see that shaving "please" off a 2,000-token prompt is noise, and that a duplicated handbook is the bill. The counter on the home page is enough to compare two drafts. The provider's usage page is the audit. Use both, and do not confuse them.
Questions
Is the biggest saving always a cheaper model?
Often, and only after you check the replies. A model at a tenth of the price that causes manual repairs can cost more than it saves. Count the tokens either way. A cheap model still charges for a pasted handbook.
Do filler words matter at API scale?
A handful of polite words do not. A paragraph of tone, repeated on every call, might. Count the paragraph. If it is 40 tokens, compute 40 times your daily calls before you spend an afternoon on synonyms.
Should I trust a browser estimate for a budget?
Use it to compare drafts of English instructions. Use the API's reported usage for the budget. The estimate does not see tool schemas, images, or output length, and output is often the larger line.