Token budget aware reasoning
Ask some reasoning models “What’s 2+3?” and they’ll chew through 900+ tokens before telling you “5.”
That’s like hiring a consultant who writes a ten-page memo to confirm the sky is blue, then bills you by the page.
This is the problem token-budget-aware reasoning solves. Here’s what it is, why it matters, and how to actually use it.
Table of Contents
A 30-second primer
Two terms you need:
- Token: A chunk of text, roughly a piece of a word. AI models read and write in tokens, and you pay per token.
- Reasoning model: A model that “thinks” step by step before it answers. That thinking is made of tokens too, and they’re billed as output tokens, the expensive kind.
So every bit of internal “hmm, let me think about this” shows up on your bill.
The What
Token-budget-aware reasoning means giving the model a thinking allowance that matches the difficulty of the problem.
- Easy question → small budget.
- Hard problem → room to think.
The goal is simple: stop paying for thinking you don’t need, without hurting answer quality.
The Why
1. Thinking is the priciest part of the bill
On OpenAI’s standard models, output tokens cost six times more than input tokens. Google’s Gemini bills its thinking tokens at the output rate too. If your AI costs jumped after switching to a reasoning model, this is usually the culprit.
2. Models overthink the easy stuff
Reasoning models can use many times more tokens than regular models to reach the same answer, and most of that waste happens on simple questions (hello again, 2+3).
3. A lot of the “reasoning” is filler
Researchers tested this with a technique called Chain of Draft, which limits every reasoning step to five words or fewer. If accuracy holds up, the cut words weren’t doing real work.
The results:
- Sports trivia (Claude 3.5 Sonnet): Tokens dropped from 190 to just 14, and accuracy actually rose, from 93.2% to 97.3%.
- Coin-flip logic puzzles: Accuracy stayed at a perfect 100% while tokens fell by 68–86%.
- Math word problems: Here’s the exception. Models gave up about 4 points of accuracy for an 80% token saving.
Takeaway: What kind of task you’re running matters more than which model you use. Test compression per task type before you roll it out.
The How
There are two levels to work at: the prompt (quick wins) and the architecture (big wins).
Level 1: Fix the prompt
Let the model set its own budget. A method called TALE-EP works in two steps:
- Estimate: Ask the model how many tokens it thinks it needs for this problem.
- Constrain: Put that number into the real prompt as a hard budget.
On GPT-4o-mini across seven datasets, this cut output tokens by 67% on average with less than a 3% accuracy drop. On one math benchmark, accuracy went up (81.35% → 84.46%) while output shrank from 318 tokens to 77. Less overthinking, fewer mistakes.
Or just say “be concise.” Adding that one instruction made GPT-3.5 and GPT-4 responses about 49% shorter with little impact on most tasks. But on math, GPT-3.5 took a 28% performance hit. “Be shorter” isn’t free when the problem genuinely needs the steps.
The catch: squeeze too hard and it backfires. In one test, a 50-token budget trimmed a response from 258 tokens to 86. Great. But a 10-token budget on the same problem produced 157 tokens, nearly double. When a model can’t meet an impossible limit, it tends to ignore it entirely. Smaller models are especially bad at this.
That’s why AI providers are moving budgets out of prompts and into API settings:
- Gemini has a thinking budget setting:
0turns thinking off,-1lets the model decide. - Claude’s newer models (Opus 4.7 and later) use adaptive, model-controlled thinking, steered by an “effort” setting rather than a fixed token count.
- OpenAI advises against adding step-by-step prompts to its reasoning models at all, since they already reason internally.
Level 2: Fix the architecture
Prompt tricks make each answer cheaper. Architecture changes let you skip answers altogether. Three moves:
1. Semantic caching: don’t answer the same question twice
In one analyzed workload, over 30% of queries were basically repeats of earlier ones, just worded differently. “How do I reset my password?” and “I forgot my password, help” deserve the same answer, and you shouldn’t pay for it twice.
How it works:
- Store each answer alongside an embedding, a numeric fingerprint of what the question means.
- Match each new question’s fingerprint against the stored ones.
- Serve or call: Close enough? Return the saved answer instantly. If not, call the model.
A cache hit means zero reasoning tokens. In one implementation, hit rates landed between 61.6% and 68.8%, with cached answers correct 92.5–97.3% of the time. Redis reports that its managed caching service, LangCache, delivered up to 73% lower inference costs and 15x faster responses on hits in its own benchmarks.
2. Smart routing: don’t send easy questions to your most expensive model
Not every question needs the heavyweight model. Routing sends each query to the cheapest model that can handle it. Two common designs:
- Pre-routing: Decide which model to use before calling anything, based on the question.
- Cascading: Try the cheap model first, and escalate only if it isn’t confident.
Research results are striking: one router cut costs by up to 85% while keeping 95% of GPT-4’s performance, and a cascade approach saved up to 98% while matching the best single model on tested tasks. Your mileage will vary by models and traffic, but the pattern holds: most traffic doesn’t need the big model.
3. Memory: don’t make your agent re-learn what it already knows
AI agents waste tokens in two ways:
- Turn-by-turn bloat: Many agents resend the full chat history on every call, so costs can grow roughly quadratically as conversations get longer.
- Session amnesia: Without memory, an agent re-figures-out the same conclusions every new session.
The fix is to store what the agent learned, both short-term (this session’s notes) and long-term (facts, preferences, past events), and retrieve it instead of re-deriving it.
Level 3: Measure everything
You can’t cut what you can’t see. The emerging OpenTelemetry standard for AI (still in development) defines counters for input tokens, output tokens, and, crucially, reasoning tokens on their own.
Two numbers to watch:
- Output token ratio: Output divided by total tokens. If it creeps up, your prompts or reasoning are getting wordy.
- Cache hit rate: Hits divided by queries. The most direct measure of how much work you’re skipping.
Proof it pays off: GitHub cut token spend in its agent workflows by up to 62% after instrumenting usage and weighting output tokens far above cheap cached reads.
Cheat sheet
| Lever | What it does | Reported savings |
|---|---|---|
| Self-estimated budgets (TALE-EP) | Model sizes its own thinking allowance | ~67% fewer output tokens |
| “Be concise” prompting | Asks for shorter reasoning | ~49% shorter responses (risky on math) |
| Semantic caching | Reuses answers to similar questions | Up to 73% lower cost (vendor benchmark) |
| Model routing | Sends easy queries to cheaper models | Up to 85–98% (study-dependent) |
| Agent memory | Stops re-deriving past conclusions | Avoids quadratic history growth |
| Token instrumentation | Shows where spend goes | Up to 62% (GitHub) |
The bottom line
Prompt-level budgets are a quick, cheap first step, and API-level settings make them more reliable. But they only shrink each answer. The real savings come from not generating answers you don’t need: cache repeats, route easy questions to cheaper models, give agents a memory, and measure everything so you know what’s working.
Make your AI think as hard as the problem requires, and not one token more.