The Metadata Tag That Revealed $4,200 Per Month in Hidden LLM Waste

Our LLM bill was $18,000 a month, and the honest answer to "what's driving it" was a shrug. The OpenAI dashboard showed total spend by model, which told us GPT-5 was expensive — something we already knew. It didn't tell us which of our 40+ endpoints was actually responsible. One HTTP header, added once, changed that entirely.

The Before and After

The Tag Itself

The mechanism is deliberately simple: attach an identifier to each request that names which part of your app triggered it, at the point the request passes through your proxy.

# Before — no way to distinguish this call from any other
response = client.chat.completions.create(
    model="gpt-5",
    messages=[...],
)

# After — tagged with the feature that triggered it
response = client.chat.completions.create(
    model="gpt-5",
    messages=[...],
    extra_headers={"X-Preto-Feature": "document-summarization"},
)

That's the entire technical change. No new infrastructure, no separate logging pipeline — the tag rides along on a request you're already making, and the proxy layer aggregates by it afterward. The cost of adding this is close to zero; the cost of not having it is every future cost conversation defaulting back to a single undifferentiated number.

What This Reveals, Almost Every Time

The specific dollar figures vary by team, but the shape of what feature-level attribution surfaces is strikingly consistent: cost concentrates far more than intuition suggests. Two or three features typically account for 60-80% of total spend, and at least one of those top features is usually running on a model more capable — and expensive — than its actual task complexity requires. This is the same pattern behind the single most common LLM cost-waste source, and feature-level tagging is the prerequisite for finding it, because "which specific feature is overpowered" is not answerable from a total-spend number alone.

In our case, the $4,200/month figure came from exactly that pattern: a document-summarization feature running GPT-5 on inputs that a mid-tier model handled with no measurable quality difference on our own eval set. The waste had been there the entire time — the tag didn't create it, it just made it visible enough to fix.

Why Retroactive Attribution Doesn't Work

It's tempting to think this data could be reconstructed later from application logs — correlate timestamps, guess at which endpoint was active, stitch together a rough picture after the fact. In practice this is fragile: it depends on logging discipline staying consistent across every code path that ever calls an LLM, and as a codebase grows past a handful of endpoints, that consistency erodes. A new engineer adds a new feature without knowing the logging convention exists; a refactor moves a call site and the log line doesn't follow. Tagging at the infrastructure layer — once, at the proxy — removes that dependency on everyone remembering to do it right, everywhere, forever.

Beyond the First Tag

Once feature-level tagging is in place, the same pattern extends naturally: tag by team if multiple teams share a workspace, tag by user if per-user cost matters for your pricing model, tag by environment (staging vs. production) if that distinction matters for your budget. None of these require new infrastructure — they're all the same header pattern, applied to a different dimension of "what caused this request."

Gaurav Dagade

Founder of Preto.ai. 11 years engineering leadership. Previously Engineering Manager at Bynry. Building the cost intelligence layer for AI infrastructure.

LinkedIn · Twitter