Andy Garcia · freelance dev
FRENES
Back to the blog
AI & Agents

Asana Made a Browser Agent 76x Cheaper in Tests on GPT-6.1 Sol. In the 32-Page Study, the Biggest Single Step Is a Bigger Memory Budget, Not the Model

October 19, 2026 7 min read

On Friday, October 9, OpenAI published a customer story about Asana. A browser agent that Asana runs through StackAI, the no-code agent platform it acquired, averaged $0.47 in estimated model cost per run on GPT-6.1 Sol in tests, in about four minutes. OpenAI calls it 76x cheaper and 5x faster than "the original production setup on Model B", an unnamed model from another frontier lab.

The coverage I read stopped at the first split: the workflow changes alone cut cost 29x on Model B, and moving to GPT-6.1 Sol added 2.6x. That is right, and it stops one level too early. Asana's engineering blog links the full study, a 32-page PDF dated September 30 and written by StackAI's CTO, Frank Hidalgo, who had GPT-6 Astra in Codex run the experiments. It has the run ledger, and the ledger tells a more useful story than the headline.

I build agents on Claude every day as CTO of a LegalTech, and BidForge, my side product, reads French public tender files for small businesses. Both are machines for resending context. So I read the ledger.

What the agent was doing

A browser agent resends everything on every call: tool definitions, system prompt, and a growing history of page text and screenshots. A prompt cache bills the repeated part at a fraction of the price, but it only reuses the longest unchanged prefix of a request. Asana's agent cached its tools and system prompt, not its history. And it edited that history at nearly every step: it removed the previous screenshot and trimmed older text to fit a budget of 120,000 characters. Each edit changed an earlier part of the request, so reuse broke on almost every call.

The test task: open books.toscrape.com, a fictional bookstore built for scraping practice, visit 32 book pages, collect six fields per book (192 facts) and return a table with the price total. Six caching and pruning policies, two history budgets, four models, three runs each: 144 runs between September 14 and September 30, plus a 12-run follow-up on October 1.

The 76x, one step at a time

The study adds one change at a time on Model B. Mean model cost per run:

  • Original code, 120,000-character budget: at least $36.21. One run hit the step limit, so the mean is a floor.
  • Same code, budget raised to 480,000 characters: $4.87.
  • Plus caching of the history ($3.94 on its own), then screenshots pruned in batches: $1.24.
  • The same optimized agent on GPT-6.1 Sol: $0.47.

That is roughly 7.4x, then 3.9x, then 2.6x. Multiply them and you are back at about 76x.

The largest step is the first one, and it involves no cache and no new model. At 120,000 characters, the agent trimmed facts it had already collected, and no run's final request still held all 192. So it went back for them. On Model B, page revisits fell from at least 271 per baseline run to 2 with the larger budget, a count the study says also includes routine returns to the catalog. Between the original setup and the best one, Model B made 9x fewer calls, and each run sent 2.3 million tokens instead of 19.7 million.

An agent that forgets pays twice.

The upgrade trap

Newer models broke the old budget. Model C, a newer version of Model B released in fall 2026, added about 6,300 input tokens per call before its first trim, against 900 for Model A and 1,800 for Model B and Sol. Model C first trimmed its history at call 10, Model A at call 64. At 120,000 characters, Model C delivered an answer in none of its 18 runs and GPT-6.1 Sol in 3. At 480,000, every run on both answered.

Read that from the buyer's side. Swap in a newer model with the old settings, and the newer model looks broken. A history budget is tuned to a model, which makes a model upgrade a configuration change.

Caching alone cost more

This is the finding I find most useful. At the larger budget, caching the history without changing the pruning cost more than not caching it on Model A, Model C and Sol. Cache writes made up over 90 percent of that condition's cost, while cache reads stayed under a third of input.

The arithmetic is simple. In the study's price table, a cache write costs 1.25x the input price. A read costs 0.1x on the other provider and 0.05x on Sol. On GPT-6.1 Sol that is $2.00 per million uncached input tokens, $2.50 to write and $0.10 to read, the lines OpenAI's pricing page shows. Take a simplified 50,000-token history over 20 calls. Uncached: 20 × 50,000 × $2 / 1M = $2.00. Written once, then read 19 times: $0.125 + $0.095 = $0.22. Rewritten on every call because something earlier changed: 20 × $0.125 = $2.50, a quarter more than no cache at all.

Batch pruning is the fix. At 20:1, the agent keeps up to 20 screenshots, then cuts back to one, so about 19 consecutive calls reuse the cached history. The study's median Sol runs show it at call 24: about 40,000 input tokens, 9 percent from cache, under the old policy; about 58,000, 93 percent from cache, under the new one. By my arithmetic on those figures, ignoring output, the request that was 45 percent bigger cost roughly $0.016 against $0.073.

Then a follow-up kept every screenshot, no pruning at all. Cost per call came out 1.2x lower than the best condition on Model B and Sol. The study is careful: pruning still matters for long tasks, smaller context windows and pricier cache reads, and it calls this comparison "indicative", since the follow-up ran as one batch with shared caches. On this task, append-only won.

What the customer story leaves out

It is a development test, not a production bill. Where OpenAI's page and Asana's blog say "production setup", the study calls the starting point a "development baseline". It examines the problem "ahead of any claim about production savings in Asana." Costs are computed from token counters at list prices, are "not invoices" and exclude sandbox and server costs.

The best condition was picked after the runs, the lowest mean among twelve, and the study names that selection bias itself. Three runs per condition.

The cross-model comparison is, in the study's word, "descriptive." Model C and Sol ran in a second phase with effort set to high, and Sol got a 30-minute cache lifetime against five minutes.

Part of Sol's 2.6x is a price line. In the study's price table, Models B, C and Sol all cost $2 input and $10 output per million tokens, but Sol reads its cache at $0.10 against $0.20. Sol made 28 calls on average against Model C's 12 and still came out cheaper.

Sol answered "with a short summary of the total and the cheapest and most expensive books rather than the full table." Every Sol answer had the right total. It was also shorter than the task asked for, and output is the most expensive line on the price card. The study does not say how much of the gap that explains.

Even a quote moved. On Asana's page, its CPO, Arnab Bose, says "an agent ran the experiments." On OpenAI's page, the same sentence reads "GPT-6 Astra ran the experiments." A customer story is marketing. The study is the evidence.

What I would check in my own agents

None of this is specific to OpenAI: the study says its lessons held on both providers.

Measure cache reads per call from the provider's usage counters, not from your config. Asana's original agent had a cache marker and read about a tenth of its input from cache.

List everything that rewrites earlier messages: a text trimmer, an image dropper, a tool result summarized in place. The study adds one I would not have guessed: on the other provider, changing the tool choice reset the message cache, and each call that forced a tool caused a miss.

Re-tune the history budget at every model change. Log the call where the first trim happens, and whether the agent revisits what it already read.

Price a prune before shipping it. On a 35-call Sol run, the study estimates a prune pays for itself only after about 27 more calls at Sol's 0.05x read price, about 13 at 0.1x.

Keep the guardrails. No run reached the 480,000-character budget, and the study still says to cap steps, tokens and cost per run, because if the cache breaks on an agent that drifts, every call pays full price.

In September I wrote that for agents, the cache read is the line that changes the bill. This study adds the condition I left implicit: the cache only pays once the agent stops rewriting its own past. The model was the last 2.6x. The first 29x was in how the agent kept its memory, and the same fix cut cost on every model tested.

Sources

A project like this one?

I design and deploy products like this. Let's talk.

Let's talk