AI Browser Agent Costs: Where Asana's 76x Reduction Came From

Asana's browser agent went from at least $36 per run to about $0.47, and from roughly 22 minutes to about 4. The headline number is real as reported, but it combines two different changes. One is how the agent manages its conversation history. The other is which model runs it. Looking at the published figures, most of the reduction came from the workflow change on the same model. The model change accounts for the rest.

This article works through what Asana and OpenAI measured, where browser-agent money goes, how much each change contributed, and what that means for anyone running agents at their own scale.

What Asana actually measured

Two publications describe the same study. Asana published its write-up on 8 October 2026, and OpenAI published a companion case study on 9 October 2026. Both report the same core figures.

Three points separate measurement from promotion.

The baseline is a floor. Some original runs reached the step limit before completing. Their cost is counted, so the true mean for a fully completed baseline would be at least $36.21. The reduction is therefore a lower bound on the factor, not an exact figure.

The headline mixes two variables. The 76x comparison sets the original Model B configuration against the optimised configuration on GPT-6.1 Sol. Asana's own breakdown shows that the same workflow change on Model B produced 29x, and the switch to GPT-6.1 Sol added another 2.6x.

The sample is small and narrow. Each main-study condition was run three times; one Model A run was excluded. Models A and B ran in the first phase, and Model C and GPT-6.1 Sol in the second, with different API adapters and some request settings. The cross-model figures are observed configuration comparisons, rather than an isolated test of model identity. Asana notes that the study shows broad patterns rather than distinctions between conditions a few percent apart. It also tested one task type. The results describe that workload and do not establish a general rule for browser agents.

For the wider budget, see our AI agent economics guide. This experiment concerns StackAI browser navigation; Asana AI, monday.com AI and ClickUp Brain subscription costs are a separate purchasing comparison.

Where the money goes

A browser agent calls a model many times per task. Each call resends its tools, its instructions and its accumulated history of page text and screenshots. The cost of a run is therefore driven less by the number of calls than by how large each call is and whether its input can be reused.

The main drivers are:

• Repeated history. Earlier steps are sent again on every call. A 20-step run with a growing history pays for the early steps 20 times.
• Screenshots and image tokens. Each screenshot adds input volume. Removing or trimming them changes the cost of every later call.
• Large tool outputs. Verbose page text or tool results accumulate in the history.
• Context edits. Any change to earlier content breaks reuse from the changed point onward.
• Input versus output tokens. Input usually dominates in browser agents because the history is long and output is short.
• Prompt caching. Cached input is cheaper than uncached input. On the models Asana tested, cache reads cost 0.05x to 0.1x the standard input price; the study used standard-tier GPT-6.1 Sol, not Ultrafast. Cache savings depend on the prefix staying identical between calls.
• Failed and repeated actions. A wrong click or a retried step adds calls without adding progress.
• Sequential tool calls. Each step waits for the previous one, which increases both latency and the number of model turns.

Our prompt caching economics comparison explains write, read and storage charges. For the separate speed-tier decision, see GPT-6.1 Sol Ultrafast pricing; the $0.47 benchmark is not an Ultrafast or general API tariff.

Asana's central finding is about the caching point. The agent cached its tools and system prompt, but not its history. It also removed the previous screenshot at every step and trimmed older text to fit a history budget. Each of those edits changed an earlier part of the request, so the cache broke on almost every call.

Cost-reduction techniques

The study tested a specific set of changes. Other techniques are commonly discussed but were not part of this experiment. The two groups are kept separate below.

Demonstrated in the study

• Caching the history, not just the system prompt. A cache marker was placed on the latest tool result so the growing history could be reused.
• Append-only history with batched pruning. Instead of removing one screenshot per step, the agent pruned screenshots in batches. GPT-6.1 Sol's cheapest tested condition kept up to 20 screenshots and then cut back to one, allowing about 19 calls between cache rewrites; Model B's cheapest condition cut from 20 to 10. Both used the larger history budget.
• A larger history budget. The budget rose from 120,000 to 480,000 characters, so older text was no longer trimmed to fit.
• Matching the budget to the model. Newer models filled the smaller budget faster. At 120,000 characters, Model C answered in none of 18 runs. At 480,000, every run on both models that were tested answered.

Additional general recommendations (not tested in this study)

• Conversation compaction, which summarises earlier history instead of keeping it verbatim. Asana lists this as outside the scope of its study.
• Limits on steps, tokens and cost per run, so that a drifting agent cannot run up an unbounded bill.
• Cutting unnecessary tool calls and avoiding redundant context in tool outputs.
• Choosing the cheapest model that passes your own task test, rather than the cheapest list price.

The actual savings

The table below uses Asana's reported means. Multipliers and percentages are calculated from the rounded figures shown.

Two comparisons separate the contributions:

• Workflow change, same model (Model B): $36.21 → $1.24. That is at least 29.2x, or at least a 96.6% reduction. Cache-intact history, batched pruning and the larger budget account for this.
• Cross-model comparison, each at its best tested workflow: Model B at $1.24 → GPT-6.1 Sol at $0.47. That is 2.6x, or a 62.1% reduction. The two models are listed at the same price per token in the study's table, so this gap is not a list-price effect. It reflects differences in token use and the mix of uncached input, cache writes, cache reads and output. Model-specific pruning and cross-phase request settings also differ, so the 2.6x figure should not be read as a model-only causal effect.

A third comparison isolates the workflow change on GPT-6.1 Sol alone. With the larger budget, the cost fell from $1.97 to $0.47 per run, which is 4.2x or a 76% reduction. This is the cleanest measure of the workflow change on the newer model.

Latency also improved. The original Model B setup ran for at least 22.5 minutes, and the optimised GPT-6.1 Sol workflow ran for about four minutes. Asana reports this as roughly 5x faster.

Costs at scale

These figures assume that each execution is comparable to the study task and that per-token pricing stays as it was. They are not a forecast for a different workload.

The original column is a floor for the reason given earlier: completing the capped baseline runs could add cost beyond the amount recorded.

The hidden trade-offs

A cheaper run is only useful if it still finishes the task. The study gives several examples of where cost and reliability pull apart.

Task completion. OpenAI reports that the headline optimised workflow completed its runs and returned the correct answer on this test task. The full study distinguishes seeing all 192 facts, producing an answer and stating the correct price total; it did not tune the final answer format, and GPT-6.1 Sol returned a summary rather than the requested full table. The original baseline included runs that reached the step limit. These are task-specific outcomes, not a general production success rate.

Context loss. The smaller history budget did not just cost less; it stopped some runs from producing an answer. At 120,000 characters, Model C answered in none of 18 runs. GPT-6.1 Sol answered in 3 of 18 (16.7%). At the larger budget, GPT-6.1 Sol answered in all 18 (100%). Model C's smaller-budget answer rate was 0 of 18 (0%). A budget that is too small makes the cheapest configuration the least useful.

Retries. A retry adds another attempt's cost. Assuming equal average cost per attempt and a stable success probability, if a configuration fails one run in five, its effective cost per success rises by a quarter before any other factor is counted.

Cache fragility. The caching gain disappears when the prefix changes. Without batched pruning, caching the history at the larger budget cost more than not caching it on three of four models. The cache was rewritten often and rarely reused. Caching is not automatically cheaper; it depends on how the history is edited.

Pruning. The follow-up kept every screenshot. Per call, this cost about 1.2x less than the best pruning condition on Model B and GPT-6.1 Sol, and about 5% less on the third model. Asana notes that pruning still matters for long tasks, small context windows and more expensive cache reads. For a task of this length, the study did not show a benefit.

Engineering effort. The study ran for about a week with a coding agent doing much of the work. Asana's team needed to refactor the code to run configurations in parallel. Building that infrastructure is a cost that the per-run figures do not include.

Latency. Faster runs are also a cost benefit when runs are billed or queued by time, but the reported speed gain does not guarantee lower latency for every task.

Model quality. The models differ in more than price. Newer models used their history budget faster, and the study shows that their behaviour changes with the budget. Changing models requires re-testing the workflow, not just swapping a model name.

Practical recommendations

Before choosing a browser-agent architecture, measure the following on your own tasks.

1. Define success for one task. Write down a pass/fail test that does not depend on the model's own judgement. Asana scored each answer against an independently prepared reference.
2. Record per-run token counts from the provider. Use the provider's usage counters, not estimates. Record input tokens, cached input tokens and output tokens separately.
3. Measure cache reads. If cached input is a small share of input, the caching design is not working, whatever its intent.
4. Set run limits. Cap steps, tokens and cost per run so that a failing run has a bounded cost.
5. Compare at least two configurations on the same tasks. Hold the model fixed while you change the workflow, and hold the workflow fixed while you change the model. Otherwise you cannot tell which change produced which saving.
6. Calculate cost per successful task. Use this formula: Cost per successful task = total spend across all runs ÷ number of runs that met the success test This includes failed runs and retries in the numerator, and counts only successes in the denominator. A configuration that costs $0.30 per run and succeeds 50% of the time costs $0.60 per successful task. A configuration that costs $0.47 per run and succeeds 100% of the time costs $0.47.

7. Re-test when the model or the budget changes. The study shows that the right budget depends on the model.

Verdict

Can meaningful reductions in AI agent costs come from better architecture rather than simply buying cheaper tokens?

In this test, yes. Keeping the history intact so that the cache could be reused, pruning in batches, and raising the history budget reduced the cost per run on the same model by about 29x. Changing to a different model on top of that reduced it by another 2.6x. Architecture accounts for most of the saving in the reported figures.

The evidence has limits. It covers one task, one set of models and three runs per condition. The cost figures are estimates from token counts, not invoices. The model comparison is not separated from differences in per-run behaviour. A cost reduction is only meaningful if the success rate holds. Here it did, but only once the history budget was large enough for each model; at the smaller budget, Model C failed to answer in every run.

For a developer or a small team, the reliable conclusion is narrower than the headline: how an agent handles its history can change its cost by an order of magnitude, but the only way to know by how much for your agent is to run the same tasks under each configuration and count the cost per completed task.

Sources

• Asana: browser-agent cost and runtime study, 8 October 2026.
• OpenAI: Asana browser-agent case study, 9 October 2026.
• Asana full study: methods, results and limitations (PDF).