How to Actually Tokenmaxx and Save Millions — Alvin Pane, OutRival

Hey everyone, I'm Alvin, the head of agent intelligence at OutRival. By now, everyone's heard of token maxing. People have built leaderboards inside companies for who's using the most AI tokens. At Meta, they even had a title for this, Token Legend, a badge of honor for whoever's burning the most compute. It's a funny meme, but if you're actually shipping a product, token usage is a bizarre measurement of success. Tokens aren't the work, they're what you pay to get the work done.

At OutRival, our digital workers handle complex tasks over phone, text, and email. At the application layer, we're processing billions of tokens every single day, and when you operate at that scale, every redundant model call compounds into massive latency and millions of dollars in compute costs. Take a look at this prompt. I've built a synthetic proxy that mirrors what structural bloat looks like in a pipeline. Let's pretend we're classifying customer intents for a fictional company called Harborbyte.

We've all seen one of these. It's got twenty edge cases, overly pedantic definitions, and a paragraph practically begging the model not to hallucinate. When you're sending this much text on every single request millions of times a day, it isn't just a prompt anymore, it's a massive self-inflicted compute tax. If you want to give your agents more capabilities, you need the architectural headroom to do it. So today, we're reclaiming token maxing. It shouldn't be about burning the most tokens, but

about extracting the maximum surface area of intelligence from the absolute minimum token payload. So here's how to actually token max. Let's get into the playbook. First, observe. You can't fix what you can't measure. Instrument your shared model client so each attempt becomes part of a trace, connecting the model calls, tools, and retries for a single task. Record the prompt version, model settings, token

usage, latency, and cost. OpenTelemetry is a great framework for tracking this. Now that you have that telemetry, you can actually build a benchmark of how production is behaving, but here's where most optimization efforts hit a wall. Let me tell you how it usually goes. You take your massive prompt, you hand it to a smaller, cheaper model, and you run it against a few thousand of those historical production examples.

We did this. Our cheaper candidate model disagreed with our expensive production baseline about eighteen percent of the time, so naturally, we threw it out. It wasn't good enough. But what does that eighteen percent actually represent? Because language models in production are dealing with inherently ambiguous real-life inputs, that eighteen percent is actually a composite metric. It introduces a critical hidden

variable, the baseline variance of the model itself. When the input is messy, your production prompt will inevitably disagree with its own past decisions. So to isolate that hidden variable and understand what your rewrite actually changed, we asked a really dumb question: Does prod even agree with prod? We ran an AA test. We call this the ceiling test. We

took our massive, expensive production model and ran it three separate times on the same inputs and compared the answers. We discovered that it disagreed with itself roughly seven percent of the time. Production's own agreement was only about ninety-three percent, so we were demanding a standard of per-perfection from the cheap candidate that our existing expensive system couldn't even hit. Once you establish that ceiling test

benchmark, you finally have a measured baseline. Now, you can start making the work cheaper. There are three technical levers I like to pull, and they run in a sequence. The very first is caching. Specifically structuring your prompts to maximize your prefix cache rate is a really easy and really effective way to bring down the cost to run given tasks.

The second lever is to actually shrink the footprint of the prompt itself. So let's bring that Harborbyte prompt example back up. This prompt is almost five thousand tokens long, and why? Because over time, developers kept bolting on paragraphs of rules. For example, do not confuse enthusiasm with authorization is one such example. Uh, plus massive hard-coded

transcripts that were acting as worked examples. Nobody wants to be the one who deletes a line and breaks prod, so what do you do? You automate it. You turn prompting into a search problem. With a framework like DSPy, you can actually stop manually writing instructions. You define the exact interface contract, the inputs, the required output schema, and the scoring function, and then you hand it

off to an optimizer like GEPA. The optimizer treats your prompt as a search space. It runs against your benchmark, attempting to match those historical labels, and it uses feedback on failures to revise the instructions. It stripped out almost all of our long worked examples and replaced them with compact rules, a fifty-one percent reduction in instruction tokens with the same application contract. Now we

can move to test whether quality holds. That is instant margin. The third lever is to actually downsize the model. Now that you have a tight prompt and a measurable search loop, you don't always need a massive frontier model. You can start aggressively cutting compute. There are two interesting strategies here. First, you can break a massive prompt into smaller components. You use a cheaper model to

handle something like initial routing or data extraction, and only wake up your expensive frontier models for heavy reasoning. Second, you can use that exact same DSPy search loop we just built, but plug a smaller model into it. You let the smaller model search its own prompt space to match the benchmark answers generated by your large production model. You're essentially using GEPA to teach a tiny model to match the task performance of a massive one for your

specific data set. But the reality of optimization is not quite so easy when it comes to these small models. Um, if you're trying to compress the behavior of a large model into a smaller one, you'll notice that you introduce new points of failure and overfitting. Um, and in many of our downsizing experiments, uh, we found that the prompts weren't good enough to release. Which brings us to the final hurdle. We've cut

Harborbyte's prompt in half, but now we have to prove that we actually didn't break the product. Remember, these models are probabilistic. Production doesn't always agree with itself, and likewise, our new cheaper candidate is also going to have its own internal variance. So you run a massive shadow deployment on the exact same inputs and measure the system from three angles, production against production, candidate against candidate,

and candidate against production. There's a useful bit of math here. You take the disagreement between the two versions and subtract the average disagreement inside each one. What's left gives you a measure of how different their decision probabilities are. This is where that ceiling test pays off. We aren't guessing. We have a mathematical baseline for how much these answers move around when we haven't changed a thing. And here's the secret about that

drift. Different doesn't automatically mean wrong. If your optimizer did its job, the distributions should be different because the cheaper prompt is actually doing a better job. We aren't necessarily trying to build a perfect clone of a production system that may already have some flaws baked into it. So you stop panicking about the raw differences, you pull the diffs, and you manually review some of them. Was the candidate better? Was production better? Or were they just

two different, equally acceptable ways to handle an ambiguous input? For Harborbyte, let's say the completed review confirmed four hundred and forty-three regressions, but it also found two thousand four hundred and sixty-three outright improvements. That is almost six improvements for every one regression from a prompt that is half the size. But you do not ship on a point estimate. You have to account for sampling noise. We measured a massive gain on this

specific batch of requests, but we need to know exactly how much statistical confidence we can put behind it. So we calculate a confidence interval around that net gain. You keep the comparison strictly paired, both versions answering the exact same requests, and you keep the repeated runs of the same conversations grouped together. To say the candidate is better, we want the lower confidence bound above zero. If the interval crosses zero, we need more evidence before making that claim.

And one final sanity check is that you have to run this math on your critical categories separately. A great global average can actually, uh, silently hide that one vital customer intent is tanking. Uh, if your critical categories hold up and your lower confidence bound is above zero, you have your answer, ship it, and keep measuring. So this process is how you can replace the guesswork of prompt engineering with an explicit release rule.

Cache the obvious stuff, let an optimizer shrink your instructions, right-size your model, and use the ceiling test to understand the variation, then test whether quality holds. So here's your homework for Monday morning. Go pick your most expensive task, measure your baseline variance, put it through a search loop, and find out exactly how much bloat you're paying for. We need to reclaim token maxing. Let the rest of the industry fight for the high score

on the leaderboard. The real token legends are the ones making every single token count.