Asana cut its browser agent's model cost 76x. Most of the saving came before it changed models
On the same model, fixing how the agent cached and trimmed its browsing history cut estimated cost 29x. Switching to GPT-6.1 Sol added 2.6x. The workflow was the bill.
Listen to this article · 5 min
AI-generated narration of the full article.
The headline number is 76x. The more useful number is 29x, and it was achieved without changing models.
OpenAI published the story on October 9. Asana’s StackAI platform, which Asana acquired, runs a browser agent that customers use to navigate websites, fill out forms and gather information without code. Frank Hidalgo, StackAI’s CTO at Asana, directed GPT-6 Astra in Codex to investigate why the agent was expensive, test fixes and compare the results. The resulting 144-run study tested GPT-6.1 Sol and three other frontier models, which OpenAI labels Models A, B and C, on one task: collecting six fields for each of 32 books from a public demo catalog.
The optimized workflow on GPT-6.1 Sol averaged $0.47 in estimated model cost and about four minutes per run, against at least $36.21 and 22.5 minutes for the original production setup on Model B. That is the 76x and the 5x. But look at how it breaks down.
| Configuration | Estimated model cost per run | What changed |
|---|---|---|
| Original production setup, Model B | At least $36.21 | Baseline; some runs hit the step limit |
| Optimized workflow, still Model B | $1.24 | Caching and context policy only: 29x |
| GPT-6.1 Sol, larger budget, old policy | $1.97 | New model, old caching behavior |
| GPT-6.1 Sol, optimized workflow | $0.47 | Policy cut another 4x; 2.6x below optimized Model B |
The history was resent at full price
Astra’s first finding was mundane. The agent cached its fixed instructions and tool definitions, but not the growing history of page text and screenshots it collected along the way, so every request resent that history at the full uncached price.
The obvious fix would not have worked. The agent dropped older screenshots and trimmed text at nearly every step, so the history changed constantly, and a prompt cache only helps when the beginning of the prompt stays identical. Each trim invalidated it.
The winning policy let screenshots accumulate to 20 before cutting back to the most recent one. Earlier history then stayed unchanged for long stretches between removals, and the cache could do its work. On GPT-6.1 Sol, 89% of the input came from cache at 5% of the uncached price, and each call was about 3x cheaper.
The general lesson: a context policy that looks frugal per step can be expensive per run. Trimming to save tokens can break caching and cost more than it saves.
Keeping more memory finished more runs
The second finding is about quality, not cost. With the smaller history budget of 120,000 characters, only 3 of 18 GPT-6.1 Sol runs produced an answer. With 480,000 characters, all 18 did, each correct. The original agent was not only expensive; it lost facts it had already read and sometimes revisited pages to find them again.
This is why price per token is the wrong unit. A cheaper configuration that fails five times out of six is not cheap. The measure that matters is cost per completed, correct task, the same unit we argued for when Claude Haiku 5.5’s price line turned context size into an architecture decision.
The method is the transferable part
Hidalgo estimates the investigation would have taken one to two months by hand; with Astra running experiments overnight, it took about a week. Every session’s requests, traces and results were recorded in Command, Asana’s software delivery platform, then turned into tickets and pull requests before reaching production. Asana says it plans to build this testing into StackAI’s evaluations so customers can compare cost, runtime and answer quality when configuring their agents.
That is the part worth copying: agent configuration treated as an experimental variable, with controlled runs, recorded traces and a reviewable path to production. Most teams compare models. Few compare context budgets, caching policies and screenshot retention on the same model, and Asana’s numbers suggest that is where most of the money was.
The limits are real. These are estimated model costs, not total infrastructure or engineering costs. It is one task, in a vendor’s customer story, and the competing models are anonymized. Your agent’s history, tools and cache behavior will differ.
Three checks are cheap to run on any production agent this week. Measure the cache hit rate per step, not per session. Find where the agent rewrites its own history, because each rewrite resets the cache. And before routing to a different model, run the current one with a different context policy. You may find your 29x before you need anyone’s 2.6x.