Showing an Agent Its Token Budget Made It Worse, Not Cheaper

An AI agent works through a stack of support tickets. It reads one, reads the next, keeps both in memory, and by ticket forty it is hauling every earlier ticket along with it. Each new step re-bills everything already read. The invoice grows in a shape nobody planned for.

There's a fix circulating for this that sounds obviously correct: tell the agent how much budget it has left. Give it a running counter, let it watch the meter, and it will start cleaning up after itself. A June 2026 research paper argues exactly this. Its core observation is that models are blind to their own memory usage and can't judge, from the text alone, how much room remains.

We wanted to know whether that translates into a smaller bill on a small, ordinary workload. So Effloow Lab built the counter and ran it twenty times against two commercial models.

It cost more. On one model it also produced wrong answers.

What we actually ran

The setup is deliberately mundane. Twelve short operational notes, the kind of shift-handover text any ops team accumulates. Three of them contain a buried code. The agent's job: find all three codes and report them. It has two tools, one to read a note and one to archive a note it's finished with. Archiving genuinely strips that note's text out of the agent's working memory, so it really does make every later step cheaper.

Two versions ran, identical in every respect but one.

The control version was told, in plain instructions, that it had a budget, that notes it keeps around go on costing money, and that archiving helps. No live numbers.

The dashboard version got the same instructions plus one extra line after every single tool result:

[CONTEXT STATE] tokens_used=6256 budget=6000 tokens_remaining=0 notes_in_context=5 notes_archived=3

That's the whole intervention. Same task, same tools, same wording, one added meter.

Five runs each, on two models: Google's Gemini 3 Flash (the preview build) and OpenAI's GPT-4.1 mini. Twenty episodes total. Everything synthetic. No customer data, no secrets.

What happened

Model	Version	Tokens used (avg)	Right answers	Cost per run
Gemini 3 Flash	Control	21,505	4 of 5	$0.0126
Gemini 3 Flash	Dashboard	36,969	1 of 5	$0.0217
GPT-4.1 mini	Control	8,845	5 of 5	$0.0038
GPT-4.1 mini	Dashboard	11,387	5 of 5	$0.0049

In plain terms: on Gemini 3 Flash, the budget meter made each job cost roughly two-thirds again as much (71.9% more tokens) while correct answers fell from four out of five to one out of five. On GPT-4.1 mini nothing broke, but the job still cost about a quarter more than before (28.7% more tokens) for exactly the same result. Five right answers either way.

So the best case in our run was paying more for nothing. The worst case was paying more for less.

Costs come from OpenRouter's published list prices, pulled on the day of the run: $0.50 per million input tokens and $3.00 per million output for Gemini 3 Flash, $0.40 and $1.60 for GPT-4.1 mini.

The specific thing that broke

This part matters more than the averages, because it explains the failure instead of merely recording it.

Four of the five Gemini dashboard runs never finished. They hit the turn limit with nothing to show. In those runs the agent made 56 calls to read a note across a set of only 12 notes, and 52 calls to archive one. It was archiving notes and then reading them back again, over and over, in a loop.

The reason sits in the counter itself. Our stated budget was 6,000 tokens. Here's the cumulative usage from one of those runs:

turn 1  used=316     remaining=5684
turn 2  used=2010    remaining=3990
turn 3  used=3990    remaining=2010
turn 4  used=6256    remaining=0
turn 14 used=44412   remaining=0

By turn four of fourteen the meter read zero, and it kept reading zero for the remaining eleven turns. After every action, the agent was told it had already blown its budget and had no room left. It behaved the way a person under that message might: frantic cleanup, then re-reading what it had just cleaned up, then cleanup again.

A dashboard reporting an unrecoverable state doesn't produce discipline. It produces thrashing.

That's our leading explanation, and we should be honest that a budget set too tight is a flaw in our own harness rather than proof about the idea in general. A meter that stays actionable might behave differently. We haven't tested that, and we're not going to claim it.

What this means for your cost line

Take the Gemini numbers at face value and scale them. At 10,000 agent tasks a day, the gap between the two versions is about $91 a day, roughly $33,000 a year, for a version that answered correctly one time in five instead of four. On GPT-4.1 mini the same arithmetic gives about $11 a day, near $4,000 a year, for an identical outcome. Both are extrapolations from our per-run figures, not measured production bills.

What to do differently after reading this: if you already have a self-reporting meter in an agent prompt, or you're about to add one, run it as an A/B against the same prompt without the meter and score task success, not token count alone. Ours changed the bill on both models and improved neither.

The transferable lesson is narrower than "never show an agent its budget." Every token you spend telling the agent about itself is a token you pay for on every subsequent step, forever, because it stays in the transcript. Our meter was one short line. It still moved the bill by a quarter on the model where nothing else changed at all.

Instrumentation isn't free when the instrument lives inside the thing being measured.

Can this survive your workflow?

The question to carry into your own system: is the agent's self-report load-bearing, or decorative? Concrete places this shows up:

• Support ticket triage. Long queues, growing transcripts, agents that re-read. Add a budget meter here and you need to measure the accuracy of the triage decision, not just the token count.
• Order and invoice processing. Steps that must complete. A thrashing loop that exhausts its turn budget is an unfinished order, and our Gemini runs failed in exactly that shape: no answer at all rather than a wrong one.
• CRM and internal record writes. Cheap per call, enormous by volume. A 28.7% overhead that changes no outcome is the most expensive kind of change, because nothing looks broken.
• Research and document review agents. The regime where the idea is most likely to actually help, and the one we didn't test.

If you're weighing a context-management change and want the measurement run by someone with no stake in the answer, that's what Proof Studio does. We publish the null results too, which is the entire point.

When to use a budget dashboard, when to skip it

Consider it when your agent runs long enough that context pressure is the real failure mode, the budget number you show stays achievable for most of the run, and you can score task success rather than only tokens.

Skip it when the workload is short, when the meter would spend most of its life reporting zero, or when the model is already handling the task unaided. GPT-4.1 mini got five out of five without the dashboard. Nothing was left for the meter to improve, so all it did was add cost.

Reach for a different tool when the goal is purely to shrink the bill. Server-side pruning doesn't require the agent to reason about anything. Anthropic's context editing clears stale tool results before token counting, and Anthropic reports a 29% performance improvement from context editing alone plus an 84% reduction in token consumption in a 100-turn web search evaluation. Those are vendor figures from a vendor evaluation, not ours, and they measure a different mechanism: the platform doing the cleanup rather than the agent deciding to.

That distinction is the practical takeaway. Cleaning up on the agent's behalf and asking the agent to clean up after itself are separate bets with separate costs.

What we did not test

Our result is small and should be read that way. Five runs per cell, two models, one task shape, one level of context pressure, no significance testing. The randomness setting sat at its default maximum, and the spread shows it: control runs on Gemini ranged from 6,833 to 38,909 tokens.

The paper behind this idea reports much larger effects than anything we saw, on benchmarks built for long-running agents at 1M, 100K and 10K trajectory scale. Our twelve-note task is nowhere near that. The paper also describes a full system with recoverable archived payloads and typed memory blocks; we implemented only the visible meter. No code accompanies the paper's abstract page, so its headline results were not reproduced here, and nothing above confirms or contradicts them.

One more caveat. The run went through OpenRouter rather than the two vendors' own endpoints, because the Effloow OpenAI project hit its spend limit that morning and returned a 429. We wrote separately about handling that failure mode. Routing was not controlled for.

Bottom Line

On a short task with two commercial models, showing the agent a live token meter cost 29-72% more and, on Gemini 3 Flash, collapsed accuracy from 4/5 to 1/5. If you're adding self-monitoring to an agent to save money, measure it before you ship it. It isn't free and it isn't automatically helpful.

What Effloow added

The paper supplies the idea and its own benchmark numbers. Vendor documentation supplies a different, server-side approach with its own figures. Neither tells you what happens when you bolt a budget meter onto an ordinary short agent task, and neither publishes the case where it backfires.

This article contributes a measured 20-episode A/B comparison with the full per-run numbers, the cost arithmetic at published list prices, and a documented failure mode: a meter pinned at zero for eleven of fourteen turns, producing an archive-then-re-read loop that burned the whole turn budget. Complete method, raw counts and limitations sit in the public lab note.

For related measurements on where agent tokens actually go, see our token cost breakdown for programmatic tool calling and the agentic web search context control proof. For the broader cost-reduction toolkit, start with the production LLM token optimization guide.

For your engineers

Harness. scripts/context-state-visibility-token-proof.py, plain urllib, no SDK. Provider: OpenRouter's OpenAI-compatible POST /api/v1/chat/completions. Model ids exactly as sent: google/gemini-3-flash-preview and openai/gpt-4.1-mini.

Command.

python3 scripts/context-state-visibility-token-proof.py \
  --trials 5 \
  --models google/gemini-3-flash-preview,openai/gpt-4.1-mini \
  --temperature 1.0

Task. 12 synthetic notes, ids 1-12; fragments buried in notes 3, 7 and 10; expected answer K7-Q2-M9. Correctness is a substring match on the normalized final message.

Tools. read_note(id) returns the note body. archive_note(id) rewrites that note's existing tool message in the message array to [ARCHIVED] note N text removed from context., so archiving reduces real input tokens on every later turn rather than only claiming to.

The only difference between arms. After each batch of tool results, the visible arm appends one user message: [CONTEXT STATE] tokens_used=N budget=6000 tokens_remaining=N notes_in_context=N notes_archived=N. The control arm appends nothing.

Caps and guards. max_tokens=1600, MAX_TURNS=14, temperature=1.0, stated budget 6,000 tokens, and a fail-closed local ceiling of 900,000 tokens for the whole invocation. Total spend recorded in the artifact: 393,529 tokens.

Token accounting. OpenRouter documents that prompt_tokens and completion_tokens are counted "using the model's native tokenizer." Control-vs-dashboard comparisons within one model are therefore sound. Comparing absolute counts between Gemini and GPT is not, and no such comparison is made above.

Reproduce. Raw per-episode results, per-turn token traces, aggregates and the full limitations list are in the public lab note, backed by the JSON artifact written by the script.

Primary sources.

1. arXiv:2606.30005: LLM Agents Are Latent Context Managers: Eliciting Self-Managed Context via State Proprioception (Binyan Xu, Haitao Li, Kehuan Zhang; v1 2026-06-29, v5 2026-07-31)
2. Anthropic: Context editing documentation
3. Anthropic: Managing context on the Claude Developer Platform
4. OpenRouter: Usage accounting
5. OpenRouter: Models and pricing endpoint (prices read 2026-08-21)