Engineering brief

Token bloat costs millions: the engineering playbook for fixing it

AI Engineer3 min read · saves 8 min

At a glance

The brief is enough

Relevance
Practical value
Radar
Time horizon
Now
Warnings
None

Most teams treat high token usage as a trophy. OutRival's Alvin Pane argues it's a self-inflicted tax.

Token costs explode silently. This playbook turns optimization from guesswork into a measurable engineering process.

Watch if you're managing LLM costs at scale and want a repeatable optimization methodology.

Summary

The proposal. Alvin Pane, head of agent intelligence at OutRival, argues that the industry's obsession with maximizing token consumption is misguided. Instead of treating high token usage as a badge of honor, teams should focus on extracting maximum intelligence per token.

Why now. Pane's company processes billions of tokens daily across phone, text, and email tasks. At that scale, every redundant model call compounds into latency and millions in compute costs. The problem is structural: developers bolt on paragraphs of rules over time, afraid to delete anything that might break production.

The measurement trap. Teams often reject cheaper models because they disagree with production baselines. Pane demonstrates that production frequently disagrees with itself—roughly 7% of the time in his AA ceiling test. Demanding perfection from a candidate that the expensive system cannot achieve is a mistake.

The three levers. First, caching: structure prompts to maximize prefix cache rates. Second, shrink prompts using an optimizer like DSPy or Jeepa instead of manual editing. Pane achieved a 51% reduction in instruction tokens. Third, downsize the model: break tasks into components, using cheap models for routing and frontier models only for heavy reasoning.

The validation hurdle. After optimization, teams must prove quality didn't degrade. Pane recommends shadow deployments comparing production-versus-production, candidate-versus-candidate, and candidate-versus-production. The key insight: different answers are not necessarily wrong ones. His HarborBite example showed six improvements for every regression.

The bottom line. Before shipping, calculate confidence intervals around the net gain and check critical categories separately—global averages can hide a failing intent. If the lower confidence bound is above zero, ship and keep measuring. Cache, shrink, right-size, validate.

My take

The ceiling test alone is worth the read. I've seen teams reject cheaper models because of a 5% disagreement rate, never realizing their production system wobbles more than that on its own. The math for isolating that variance is solid and practical. What I'd add: the organizational friction of maintaining these benchmarks. The ceiling test works today, but prompts drift as models update. Someone has to own re-running this every few weeks. That's a staffing conversation most teams skip. The DSPy search loop is clever, but it introduces its own maintenance burden. Still, this beats manual prompt engineering by a mile.

What to do with this

  1. Run a ceiling test on your most expensive production task to measure how often your current system disagrees with itself.
  2. Instrument your model client with OpenTelemetry to trace token usage, latency, and cost per task.
  3. Pick one expensive prompt and run it through an optimizer like DSPy to identify instruction bloat.

Watch the video

This video is blocked due to your privacy settings. To watch this video, please accept YouTube marketing cookies.

Related breakdowns

Get TL;DW

Too Long; Didn't Watch.

A concise breakdowns of the AI and devtools videos that actually matter for engineering leaders.

Free. Weekly. No hype.

Video and thumbnails remain the property of their respective creators. tldw.news provides editorial analysis, commentary, and discovery links to original content.