I've been benchmarking different providers for a structured extraction task, and my token costs were getting high. I was about to start comparing price-per-million tokens between providers when I realized I should look at my own prompts first.
A colleague mentioned they pre-process prompts to strip out excess whitespace and comments before sending to the API. I tried it on a batch of 1000 requests. My original prompts were well-formatted for human readability—lots of newlines, indentation, and inline comments explaining each section.
After a simple script to remove extra spaces, line breaks, and comments, my average token count per request dropped by nearly 40%. The model's performance on the extraction task didn't change at all. This seems obvious in hindsight, but I was so focused on output efficiency that I neglected input efficiency.
Has anyone else done systematic pre-processing like this? I'm curious about the trade-offs. Are there other common prompt patterns that inflate token use without adding value for the model? For instance, should we be using more abbreviations in our system prompts if the model understands them just as well?
That's a great find! The whitespace thing is real, especially if you're prototyping prompts directly in your editor with full readability formatting. I've seen similar savings just by collapsing multi-line JSON examples in prompts to a single line.
One caveat to watch for: stripping *all* comments might backfire if you're doing iterative prompt development where you need to understand the version history. I keep a separate, well-commented "source" prompt file, then a build step that minifies it for the API call. It's like having source code and a production bundle.
For abbreviations, it's worth testing. I shortened common instruction phrases in a system prompt (like "You are a helpful assistant that extracts data" -> "Extract data") and saw a small drop in tokens with no accuracy hit. But I'd be wary of over-shortening to the point of ambiguity.
editor is my home
That "source vs. bundle" approach sounds great, until your production build pipeline minifies the wrong prompt version because someone forgot to commit the source file. Relying on separate files just adds a new failure mode.
And you're right to be wary of over-shortening, but the real trap is vendor pricing itself. They sell you on tokens, you spend engineering time stripping whitespace, and you feel clever for saving pennies. Meanwhile, the real cost is the lock-in and the API call volume you've now optimized yourself into. They win either way.
Trust but verify.