Asana Browser Agent Tests Cut Model Costs 76x With GPT-6.1 Sol

Asana says its browser agent became 76 times cheaper and five times faster after engineers changed how it retained and cached browsing history. The Asana browser agent tests used GPT-6 Astra in Codex to investigate the system, run experiments, and analyze traces. GPT-6.1 Sol then delivered the lowest estimated model cost under the optimized workflow.

The headline result looks like a model victory. The more important finding concerns agent architecture. Asana changed when the agent removed screenshots, expanded its history allowance, and cached the growing record of previous steps. Those changes reduced repeated processing while preserving information the agent needed to finish its task.

That distinction matters for every company evaluating browser agents. A team can switch to a less expensive model and still waste tokens through poor context management. It can also choose a more capable model, preserve the right history, and lower total operating costs. Asana's experiment puts those two strategies into direct competition.

The Asana Browser Agent Study Changed More Than the Model

Asana's largest gains came from redesigning the workflow around the model, not simply replacing one model with another.

The company published the results on October 8, 2026, followed by an OpenAI case study on October 9. The work focused on a browser agent inside StackAI, the no-code automation platform Asana acquired earlier in 2026.

StackAI lets customers create agents that navigate websites, collect information, and complete forms across business applications. These workflows resemble human browsing, but the underlying agent repeatedly sends instructions, tools, page text, screenshots, and earlier actions to a model.

That repeated context creates an expensive pattern. Every new step includes more history than the previous one. If earlier content keeps changing, a provider cannot reliably reuse its cached representation.

Asana's original agent cached fixed instructions and tool definitions. It did not effectively cache the growing browsing history. The agent also removed old screenshots and trimmed text frequently, changing earlier portions of the request.

Those edits broke the stable prefix, which is the unchanged beginning shared by consecutive model requests. Once that prefix changed, much of the browsing history had to be processed again.

Frank Hidalgo, StackAI's chief technology officer at Asana, directed GPT-6 Astra in Codex to inspect this behavior. The model mapped the codebase, reviewed how requests were assembled, and identified variables worth testing.

Asana says the resulting study included 144 primary runs across four frontier models. It tested six caching and screenshot policies, two history allowances, and three runs for each condition. The company later conducted a smaller follow-up.

Each configuration received the same assignment. The browser agent had to collect six fields for each of 32 books from a public demonstration catalog. That meant finding 192 facts while maintaining enough context to return a correct final answer.

The models included GPT-6.1 Sol and three anonymized alternatives. Asana called those systems Models A, B, and C. Model B powered the original production configuration, while Model C represented a newer model from the same provider.

Asana did not disclose those providers, limiting direct competitive comparisons. However, it said the optimized GPT-6.1 Sol workflow cost 76 times less than the original Model B setup. It also finished about five times faster.

The company has since released the browser-navigation changes in StackAI. That turns the exercise from a laboratory comparison into a production change, although Asana has not published broad customer-level performance data.

Why Prompt Caching Became the Deciding Mechanism

The decisive variable was whether the agent could keep most of its accumulated history unchanged between calls.

Prompt caching stores the reusable computational state associated with an unchanged prompt prefix. Later requests can reuse that state instead of processing the same material from the beginning.

The cache does not store a finished answer for replay. The model still processes new material and generates a new response. It simply avoids repeating work for eligible context that remains identical.

OpenAI's prompt caching guide recommends placing stable instructions and reference material before changing content. It also advises applications to append conversation history instead of repeatedly rewriting earlier turns.

Asana's original design violated that second principle during browser runs. At nearly every step, it removed an earlier screenshot and sometimes trimmed older text. The next request therefore differed in the middle of its history.

Caching only the fixed system prompt could not capture the largest source of repeated input. The browser agent accumulated page text, screenshots, observations, and tool results as it moved through the task.

Asana tested a different policy called batch pruning. Pruning means deleting older context before the accumulated history becomes too large. Under the selected policy, the agent retained as many as 20 screenshots before reducing the set to the newest one.

That approach created longer stretches of append-only history. The agent could add new observations at the end without changing earlier content during every step. More of each request therefore remained eligible for reuse.

The optimized workflow also increased the text-history allowance from 120,000 characters to 480,000 characters. This gave the agent more room to preserve previously gathered facts instead of discarding them.

The larger allowance had an important effect on completion. With the smaller history setting, GPT-6.1 Sol produced an answer in only three of 18 runs. At the larger setting, it answered in all 18 runs, according to Asana.

Asana says every one of those larger-history runs returned the correct answer. That result challenges the assumption that aggressively shrinking context always improves agent efficiency.

Deleting context reduces the immediate size of a request. However, it can force an agent to revisit pages, repeat tool calls, or continue without evidence gathered earlier. It can also break cache reuse when deletion changes the request prefix.

The best policy therefore depends on total task economics. Teams must consider input processing, repeated navigation, completion rates, response quality, and recovery from failed runs.

Asana reported that 89 percent of GPT-6.1 Sol's input came from cache under the optimized setup. That ratio explains why a more capable model could become the least expensive tested option for the complete task.

This is the central mechanism behind the Asana browser agent result. The company did not merely ask a model to use fewer tokens. It reorganized the workflow so repeated tokens became cheaper to process.

More Context Helped the Agent Finish Reliably

The experiment suggests that the cheapest request is not always part of the cheapest completed workflow.

Agent builders often treat context as a resource that must be minimized. That view makes sense because long prompts increase input processing and can approach a model's context limit.

Browser agents complicate the calculation. Their earlier observations function as working memory. Removing an address, product attribute, warning, or navigation result can leave the agent unable to complete its final answer.

The smaller history allowance produced especially weak results for some models. Asana reports that Model C returned no answer across 18 runs under that condition. GPT-6.1 Sol returned only three answers.

Those failures were not evidence that the models lacked general browsing ability. The larger history allowance changed the outcome. Both models answered every run after receiving enough space to retain the necessary record.

The result supports a broader engineering principle. Context policy must fit the model and the task. One universal token limit will not produce equivalent behavior across different systems.

Models can consume context at different rates because they produce different descriptions, tool calls, and reasoning traces. One agent might reach a pruning threshold after a small number of actions. Another might continue much longer.

Asana found that newer or more capable models did not automatically use the smaller allowance more efficiently. Model C began trimming history much earlier than Model A during the tested workflow.

The experiment also found that caching alone was insufficient. At the larger history allowance, caching without batch pruning cost more than not caching on three of four models.

That outcome sounds contradictory until the request structure is considered. A cache provides limited value when the application constantly rewrites the material it wants to reuse. The system pays to process changing history without receiving enough future cache hits.

Asana's selected policy aligned three decisions. It cached history, preserved an append-only sequence for longer periods, and provided a larger allowance before trimming became necessary.

A follow-up raised another question. Asana tested configurations that kept every screenshot instead of pruning them. Some delivered lower per-call costs than the selected policy during this particular task.

The company did not treat that as proof that pruning should disappear. Longer workflows can exceed context limits, while some providers charge more for cache operations. An agent that drifts into unnecessary browsing also needs firm boundaries.

Asana recommends caps on steps, tokens, and total run cost. These limits prevent an incorrect or confused agent from expanding its history indefinitely. Compaction, which replaces older history with a shorter summary, offers another option.

Compaction introduces its own tradeoff. It reduces context size but changes the earlier prompt, potentially disrupting cache reuse. A summary can also omit a detail that later becomes important.

Teams need records outside the active prompt for this reason. Asana logged requests, traces, and results in Command, its software delivery platform. Engineers and additional agents could then review the complete experiment.

A durable record also supports a searchable knowledge base. The active agent receives only the context needed for its current step, while reviewers retain access to the complete evidence trail.

This separation helps teams distinguish model memory from organizational memory. An agent's working context should remain bounded. The experiment record should remain detailed enough to reproduce decisions and investigate failures.

GPT-6 Astra Turned Evaluation Work Into an Agent Task

Asana used one model to improve the system and another to run the optimized production workflow.

GPT-6 Astra worked inside Codex as the research and engineering agent. GPT-6.1 Sol served as one of the browser agent's runtime models. Treating those as separate roles prevents a misleading interpretation of the results.

Hidalgo set the research direction and selected the proposed changes worth testing. GPT-6 Astra inspected the code, instrumented requests, ran preliminary trials, and identified influential variables.

The existing code was not designed for controlled comparisons. Asana says the Codex agent refactored the system so a shared frontend and backend could support several experimental workflows in parallel.

GPT-6 Astra then launched the study, analyzed usage records, and compared outputs. Separate model sessions reviewed parts of the work, while humans evaluated conclusions and approved production changes.

Asana estimates that the project would have required one or two months of manual work. With the Codex workflow, the investigation took about one week.

That claim comes from the company rather than an independent evaluation. It also describes one engineering project led by a technical executive familiar with the system. Other teams should not assume the same schedule reduction.

Still, the workflow illustrates a significant change in coding-agent use. The agent did not only implement a feature from a completed specification. It helped design and execute an empirical investigation.

The investigation produced traces, experimental results, tickets, and pull requests. Those artifacts passed through Command before the changes reached StackAI production.

That process matters more than the claim that an AI agent performed most of the mechanical work. Without stable records, reviewers cannot reliably tell which configuration ran, why it failed, or whether a reported improvement survived code changes.

The Asana study says humans established the goal and evaluation standards. They also reviewed the findings. The coding agent expanded the amount of experimentation the team could execute between those decisions.

Hidalgo described a routine of setting a goal before going to bed and reviewing the results the following morning. That asynchronous pattern turns agent runtime into an engineering resource.

It also shifts the bottleneck. When experiments become easy to generate, humans must spend more time selecting valid questions, checking measurements, and rejecting misleading conclusions.

The risk is automated experimental noise. An agent can produce many runs without producing strong evidence. Repeated tests remain vulnerable to benchmark design, hidden task variation, and scoring errors.

Asana reduced some of that risk by using a fixed task and an independently prepared reference answer. It also recorded the provider's own usage counters rather than estimating token consumption from text length.

The company ran only three repetitions for most configurations. Asana explicitly says the study reveals broad patterns, not dependable differences of a few percentage points.

That qualification is important. The 76x and 5x comparisons are large enough to justify attention, but they combine architectural and model changes. They do not isolate a universal advantage for GPT-6.1 Sol.

Asana's internal results show that Model B also improved substantially after receiving the optimized workflow. The architecture accounted for a major portion of the gain before GPT-6.1 Sol reduced costs further.

What the 76x Claim Does Not Establish

The published results are compelling engineering evidence, but they are not a neutral benchmark of the browser-agent market.

The study used one structured task on a public book catalog. Each run followed the same objective and gathered the same set of fields. Real enterprise browsing often includes authentication, changing layouts, ambiguous instructions, and recovery from unexpected dialogs.

A workflow that excels at repetitive extraction might behave differently during procurement, support, compliance, or internal operations. Those tasks can require judgment across several systems rather than repeated collection from similar pages.

The Asana browser agent test also compared GPT-6.1 Sol with three anonymized models. Readers cannot inspect provider-specific settings or determine how each alternative would perform after independent optimization.

Asana says Models B, C, and GPT-6.1 Sol had comparable standard pricing during the study. Model A was positioned as a less expensive alternative. The public article does not identify their names.

That anonymity prevents the result from becoming a clean model leaderboard. It also protects the study from drifting into vendor comparisons unsupported by enough trials.

The largest headline compares the optimized GPT-6.1 Sol workflow against the original production configuration on Model B. Two variables changed at once: the model and the agent architecture.

A narrower comparison found a fourfold cost reduction when the new policy was applied within GPT-6.1 Sol. The remaining difference came from comparing that optimized system with the older production baseline.

That does not weaken the result. It changes the conclusion. The study supports combining capable models with context-aware architecture, not treating a model switch as the entire solution.

The fivefold runtime improvement carries similar qualifications. Some original Model B runs reached a step limit before completing. Their measured duration therefore represents a lower bound for the complete task.

Completion quality also needs ongoing observation. Asana reports that all best-condition runs found the required facts and produced correct answers. The public material does not include customer workloads or long-term error rates.

Independent replication remains limited because the complete study depends on Asana's implementation and traces. The company shared its methods and a fuller study, but external teams still need their own task suites.

The company's acquisition of StackAI also creates a commercial interest in the result. Asana completed the StackAI acquisition in May 2026 to expand cross-system agent workflows.

OpenAI has a similar interest in showing how GPT-6 Astra and GPT-6.1 Sol support enterprise agents. Both primary sources provide valuable technical detail, but neither represents an independent industry audit.

Operational conditions can also change the outcome. Cache availability has a limited lifetime. Concurrent customers can have different histories, and personalized context can reduce the amount of shared material.

Privacy requirements may constrain which content enters model context. Security teams also need controls for screenshots, credentials, customer records, and sensitive information collected during browsing.

Caching does not remove those obligations. It changes computation and billing behavior, not the need for data governance. Teams still need retention policies, access controls, audit trails, and failure handling.

The right takeaway is therefore conditional. Asana found a high-value optimization for a specific browser agent and moved it into production. Other teams should treat the mechanism as a testable hypothesis.

The Next Test Is Performance Across Real Customer Workflows

The next three signals will show whether Asana's result becomes a reusable operating model or remains a strong internal case study.

The first signal is broader evaluation coverage. Asana says it is developing tools that let customers and internal teams compare cost, runtime, and answer quality when configuring agents.

Those evaluations need tasks beyond structured catalog extraction. Useful test suites should include changing websites, authenticated applications, partial failures, long navigation paths, and instructions with ambiguous stopping points.

If the same history policy improves those workflows, the case for architecture-led optimization becomes stronger. If gains shrink, Asana's selected configuration may be closely tied to repetitive extraction.

The second signal is evidence from production adoption. Asana has already shipped the browser-navigation changes to StackAI, but it has not published aggregate customer outcomes.

Completion rate should matter more than per-call cost. A cheaper request offers little value if customers must rerun jobs or repair incomplete outputs manually.

Teams should also watch the share of input served from cache, median task duration, step-limit failures, and human intervention rates. Those measures reveal whether the optimized design survives variable production traffic.

The third signal is how competing model providers and agent platforms respond. Prompt caching has become a product feature, but application architecture determines whether developers can benefit from it.

Providers can compete through longer cache retention, better diagnostics, lower cached-input rates, and clearer usage data. Agent frameworks can expose history policies without forcing every customer to build custom instrumentation.

OpenAI positions GPT-6.1 Sol as a model for capable agentic work at lower operating cost than GPT-6 Astra. Asana's study gives that positioning a concrete application example.

However, the strongest competitive pressure falls on agent software teams. Customers will increasingly expect platforms to optimize total task cost automatically, rather than exposing only a model selector.

A mature platform should recommend context limits based on observed behavior. It should identify cache-breaking edits, compare policies, and warn when pruning causes the agent to revisit earlier pages.

It should also retain enough external evidence for humans to audit the result. A browser agent needs bounded working memory, while the organization needs a complete operational record.

Asana plans to incorporate similar testing into its evaluation system. It is also using GPT-6 Astra in Codex to navigate product features, try different inputs, and report bugs for human reviewers.

That extension broadens the story beyond one browser agent. Asana is testing whether engineering agents can continuously evaluate other agents and product features.

The opportunity is clear. Automated experimentation can evaluate more configurations than a small engineering team could test manually. It can also shorten the path from trace analysis to reviewed code changes.

The constraint is equally clear. Human attention becomes the scarce resource when agents can generate experiments, findings, and patches continuously. Teams must decide which results deserve trust and production exposure.

For developers, the immediate action is to measure complete tasks rather than isolated calls. Record cache-hit ratios, completion quality, runtime, retries, and human repair work under realistic conditions.

For enterprise buyers, ask vendors how their agents manage growing histories. A model name alone does not reveal whether the surrounding system preserves useful context or repeatedly pays to process it.

For knowledge workers, the change promises faster and more capable browser automation. Its value will depend on whether agents can retain necessary facts without exposing sensitive data or drifting through unnecessary steps.

The Asana browser agent result makes a persuasive case that context design now belongs beside model selection in every agent evaluation. The next question is whether that lesson holds across the messy workflows customers actually want automated.