Optimizing the Token Budget: How a Server-Side HTML Strip Saves 98 %

Martin Rau · · 4 Min. Lesezeit

There are these small efficiency wins you end up enjoying over your morning coffee more than some big feature launch. This is one of them. In our orchestration system, large projects can now carry file attachments — HTML mockups, concept documents, that sort of thing. Handy. Right up until I noticed what happens when the AI in charge dutifully follows the instruction “read all the documents first” and pulls in a raw HTML mockup.

Put bluntly: that burns real money without making the AI even slightly smarter.

Why raw HTML is so expensive

The core issue is that an AI pays for every character it reads — whether or not that character carries any meaning. And an HTML mockup mostly isn’t content; it’s scaffolding: markup, inline styles, scripts, whitespace. Exactly the characters that add almost nothing to understanding but get billed in full.

As a rule of thumb I assume roughly 3.7 characters per token for HTML — pretty dense. With three to five attached mockups, that quickly adds up to more than 100,000 tokens, all at once, right at the start of the project. The AI hasn’t done anything useful yet, but the budget has already taken a serious bite.

The obvious instinct isn’t enough

My first thought was the one everybody probably has: just tell the AI in the task to “only read the relevant parts.” Sounds reasonable, doesn’t work. Because for the AI to decide what’s relevant, it first has to read the file — and the moment it reads it, the tokens are gone. So the hint in the task is fundamentally too late.

The fix: clean up before the AI looks

So we moved the cleanup step into the server, not into the AI. A new tool — we call it get-big-project-plan-attachment-text — loads an attachment, drops script and style blocks, removes the remaining tags, decodes HTML entities, and collapses excess whitespace. What the AI gets in the end is just the plain text.

Deliberately kept simple: it runs through a handful of regex steps, no heavy parser library underneath. For mockups and reports that’s entirely sufficient, and it stays fast. An optional parameter additionally caps very long texts at a maximum length, if you need that.

What matters just as much is what the tool doesn’t touch: images, PDFs, and other binaries don’t go through the strip — that wouldn’t make sense for them. Instead the tool hands back a signed, time-limited download link for those. And it leaves Markdown concepts alone, because Markdown is already LLM-friendly. So the tool looks at the file type and decides whether cleaning up is even worth it.

What came out of it

These numbers are from a real test on June 7, 2026, not a back-of-the-envelope guess:

  • The file ai-modul-mockup.html was 99,469 characters raw, about 26,900 tokens. After the strip it was 2,585 characters, roughly 650 tokens. That’s 98 percent less.
  • A second file in the same project — a Markdown concept of 22,842 characters — was correctly left untouched, because Markdown is already clean. Exactly as intended.
  • Across both attachments combined, consumption dropped from about 32,600 to 6,350 tokens, roughly 80 percent saved.

Extrapolated to the typical case with three to five mockups, that means: instead of 100,000 to 130,000 tokens, just a few thousand. And without the AI losing any content — it still gets the full text, just without the markup scaffolding around it.

The takeaway

On its own this is a small building block. But it’s exactly the kind I like: treating the token budget consciously, for me, means giving the AI only what carries meaning, and clearing out the ballast on the server side. Gathering context should stay cheap — so the AI spends its budget on the actual project, not on reading through HTML tags.

And the nice part is: you don’t notice savings like this in one single place, but spread across the whole day. They’re quiet, but they add up.

Entdecke mehr