Asana made a browser agent 76x cheaper, mostly by not breaking its own cache. Check how your agents handle history

The cheapest token is the one your provider already has in cache, and most agents throw that away.

What happened

Asana, which is building agent automations on StackAI, published a study on one browser agent. Every call resent the tools, the system prompt and a growing history of page text and screenshots. The tools and prompt were cached, the history was not, and caching it alone would not have helped: the agent dropped the previous screenshot and trimmed old text on every step, and any edit to an earlier part of a request breaks cache reuse from that point.

The fix had three parts. Cache the history too. Prune screenshots in batches, keeping up to 20 and then cutting back to 1, so about 19 calls in a row reuse the cached history. Raise the history budget from 120,000 to 480,000 characters so old text stops getting trimmed.

Across 144 runs on four models, the best setup cut cost 29x on the benchmark model and ran 4x faster. On GPT-6.1 Sol the optimized agent cost 76x less than the original setup, ran 5x faster and read 89% of its input from cache. Two warnings stood out: without batch pruning, caching the history at the larger budget cost more than not caching on three of four models, and with a budget too small for the model, most runs on the newer models hit the step limit before answering. Asana notes it was one agent on one task, a public demo catalog, not a production savings claim.

My take

Most of the 76x came from engineering, not from a cheaper model. That is good news, because you can do the same on whatever model your client already uses.

What I check on any agent that loops:

• Is the history append only? Anything that rewrites earlier messages, like summarizing or dropping attachments each step, quietly kills caching.
• When you must prune, prune in big batches, not a little every call.
• Read cache hit numbers from the provider's own usage counters per call. Do not assume.
• Set the history budget per model, and cap steps, tokens and cost per run so a drifting agent cannot run up a bill.

If an agent runs hundreds of times a day for a client, this is the first audit worth doing.