Token maxing: why you're paying frontier prices for a job a cheaper model handles
Token maxing is the practice of defaulting to the most capable and expensive AI model for every task, whether or not the task actually needs that capability. A classification call, an intent-detection step, a short structured-output extraction — all routed to a frontier model because that was the model available when the feature was first built, and nobody has checked since.
The reason this is worth naming as its own category, rather than folding it into “AI spend is high”: the fix is completely different from every other waste category. This isn't a bug, a retry loop, or a governance gap. It's a model choice made once, correctly for the moment it was made, that quietly became the most expensive line in the budget as pricing tiers diverged underneath it.
Why this is easy to miss
Model choice is a development-time decision, made once, under time pressure, with the reasonable goal of not risking a quality regression. The most capable model is also the safest choice in that moment — it's very unlikely to produce a visibly wrong answer in a demo. That safety has a price, and the price gets locked in at ship time, not revisited as routine maintenance the way a dependency upgrade might be.
Pricing spreads between model tiers within the same provider family can exceed 4,000x for comparable output quality on simple, narrow tasks. That gap didn't exist when many currently-shipped features were first built — model pricing tiers have both multiplied and spread further apart since. A choice that was reasonable eighteen months ago can be dramatically overpriced today, with nothing in the code or the invoice signaling that the gap has grown.
Why a manual model audit doesn't hold
An engineer periodically reviewing which model each feature uses, and judging by hand whether a cheaper tier would work, is a legitimate first pass — and it catches the most obvious cases. What it can't do is run continuously. The review reflects the call patterns from the week it happened; a new feature shipped the following sprint, or an existing feature whose task mix shifted, is invisible until the next audit happens to catch it.
There's also a judgment problem underneath the scheduling problem: “would a cheaper model handle this equally well” is not something you can answer by reading the prompt. It requires looking at what the calls actually produced — output length, structure, and consistency — at a scale no one reviews call-by-call.
The signal that actually indicates token maxing
A frontier model used consistently on a feature whose completions are consistently short — under roughly 500 tokens — is the pattern worth checking. Short, narrow-output tasks (classification, extraction, routing, short-form structured generation) rarely benefit from a frontier model's deeper reasoning, because there isn't much reasoning space for that depth to show up in a one-line answer. A frontier model producing long, structurally varied completions is a different picture entirely, and not a token-maxing candidate — the signal is the combination of expensive model and narrow output, not the model choice alone.
Cognocient's Token Maxing Detector watches for exactly this combination across every feature's call history, continuously, rather than at the cadence of a manual review — and calculates the exact monthly saving available from routing to a cheaper model in the same family, with a one-click routing rule to apply it. See the token maxing glossary entry for the underlying definition.
What this looks like in practice
Consider a hypothetical support-ticket triage feature that classifies incoming tickets into one of eight fixed categories, shipped a year ago on a frontier model because that was the safest choice at the time. Every completion is a handful of tokens — a category label, maybe a one-line justification. The task hasn't changed since launch, but the model's price relative to cheaper alternatives in the same family has widened considerably in that time.
That combination — frontier model, consistently short output, narrow fixed category set — surfaces as a token-maxing flag with the projected monthly saving from switching attached. Whether the switch actually happens is a judgment call for the team, evaluated against real output quality, not an automatic cutover — the value of the flag is making the tradeoff visible in the first place, not deciding it unilaterally. This is illustrative of how the detector behaves, not a specific customer's reported outcome.
Token maxing rarely travels alone. A feature with a large static system prompt on top of a token-maxing pattern is also paying a context tax on every call — a different waste category with a different fix. See the full guide to the five AI spend waste categories for how the two relate.