The 76x agent: what Asana's browser-agent fix teaches KD builders

OpenAI published a customer story on October 9 about Asana's browser agent, the one inside StackAI that clicks through websites, fills forms and pulls data for no-code workflows. The headline number is big: estimated model cost per run fell from at least $36.21 to $0.47, roughly 76x cheaper, and runs got about 5x faster.

The part worth your attention isn't the model swap at the end. Most of the saving came from fixing how the agent handled its own context. That's a bug a lot of us are probably shipping right now.

TL;DR

• On the same model (anonymised as "Model B"), workflow changes alone took a run from ≥ $36.21 to $1.24, about 29x.
• Moving the optimised workflow to GPT-6.1 Sol made it 2.6x cheaper again, $0.47, even though Model B costs the same per token.
• Run time went from at least 22.5 minutes to about 4.
• On Sol, 89% of input came from cache, billed at 5% of the uncached price.
• With a bigger history budget, Sol produced an answer in 18 of 18 runs, all correct, up from 3 of 18.

What they actually did

StackAI's CTO, Frank Hidalgo, pointed GPT-6 Astra in Codex at the agent's codebase: map how each model request is built, find the waste, propose fixes. He picked three. Astra then refactored the code so many configurations could run side by side, and ran the study: four models, two history budgets, six caching and screenshot policies, three runs each. That's 144 runs, all on one task: collect six fields for each of 32 books from a public demo catalogue.

Hidalgo's estimate is that the investigation took about a week instead of one to two months by hand.

The bug that cost the money

Prompt caching works on an unchanged prefix. If the start of your request matches a recent one, that part is billed cheaply; once something changes, everything after it is a miss.

The agent cached its fixed instructions and tool definitions, but not the growing history of page text and screenshots it collected. Worse, it trimmed text and dropped old screenshots at nearly every step. So the history kept changing, and even caching it wouldn't have helped: each edit broke the prefix, and the whole history was resent at full price on every call. The trimming also threw away facts, which could send the agent back to pages it had already read.

The three fixes

1. Cache the browsing history too, not just the system prompt and tools.
2. Raise the history budget from 120,000 to 480,000 characters, so the agent stops forgetting.
3. Prune screenshots in batches. Let them pile up to 20, then cut back to the latest one. Between cuts the history only grows, so the prefix stays cacheable for long stretches.

Here's the shape of it as a sketch (mine, not Asana's code):

// Before: rewrite the history every step. The cache misses from the first edit on.
history = trimOldText(dropOldScreenshots([...history, step]));

// After: append every step, and prune only now and then.
history.push(step);
if (countScreenshots(history) > 20) history = keepLatestScreenshot(history);

The numbers

Setup	Est. model cost per run
Model B, original workflow	≥ $36.21 (some runs hit the step limit)
Model B, optimised workflow	$1.24 (29x cheaper)
GPT-6.1 Sol, optimised workflow	$0.47 (2.6x cheaper again)

On Sol alone, at the 480k budget, the new caching and screenshot policy cut cost 4x, from $1.97 to $0.47 per run. Each call was about 3x cheaper because most of the input was a cache read.

What KD builders can take from this

1. Treat context as an append-only log. Keep the stable stuff (system prompt, tool schemas, early turns) at the front and only ever append. Anything you rewrite in the middle invalidates everything after it.

2. Prune like a garbage collector, not on every step. Batch your cleanup so you pay one cache miss per batch instead of one per call.

3. Log cached vs uncached input tokens per run. Most providers report cache reads in the usage data. If your cache-read share is low on a long-running agent, you probably have this exact bug.

4. A bigger context can make an agent more reliable, not just pricier. Going from 120k to 480k characters took Sol from 3 of 18 runs answering to 18 of 18. Forgetting is expensive: the agent redoes work.

5. Fix the workflow before you shop for a model. The workflow gave 29x; the model change gave 2.6x on top. Swapping models first would have hidden the real problem.

6. Make experiments cheap. The refactor that let configurations run in parallel is what made the 144-run sweep possible. A fixed task, a known correct answer, a few runs per setting and a cost log is a small eval harness, and you can build one this weekend.

7. A human still sets the direction. Hidalgo chose which fixes to test and reviewed the results. His line from the story: "Shipping speed is no longer the bottleneck; human attention is."

Caveats

• This is one case, published by the model vendor as a customer story.
• Costs are estimates, not invoices.
• The baseline is partly capped: some original runs hit the step limit, so $36.21 is a lower bound and the 76x is a rough figure.
• Samples are small: means of three runs per configuration, 144 runs in total, on a single scraping task.
• The other models are anonymised, and 76x mixes two effects, the workflow fix and the model change.

The direction is still worth acting on. If your agent loops over a growing transcript, check your cache hit rate this week.

Source: Asana cuts model costs 76x in browser tests with GPT-6.1 Sol, OpenAI, October 9, 2026. The story links to Asana's and StackAI's write-ups of the full study.