Asana Reports a 76× Browser-Agent Cost Cut by Keeping Prompt History Cacheable

The October 9 report covers a shipped optimization, not a new model

OpenAI published Asana’s browser-agent case study on October 9, 2026. The underlying Asana report is dated September 30 and says the caching and retention changes have shipped in StackAI. GPT-6 Astra in Codex helped investigate the code and run the experiments; GPT-6.1 Sol was one of four inference models tested for the browser workflow.

The headline result is specific: the selected optimized workflow on GPT-6.1 Sol averaged $0.47 in estimated model cost and about four minutes, versus at least $36.21 and roughly 22.5 minutes for the original Model B setup. Asana describes that as 76 times cheaper and five times faster. It does not report a new OpenAI model, new Asana product tier, customer price, service level or production-wide savings rate.

Editing old history was breaking prefix reuse

The browser agent resent tools, instructions, page text and screenshots on every model call. Its tools and system prompt were cacheable, but the growing browsing history was not. More importantly, the agent removed the previous screenshot and trimmed older text at almost every step. Prefix caching can reuse only the longest unchanged beginning of a request, so those edits invalidated reuse after the changed point.

Asana tested three coupled changes: extend the cache boundary through the newest tool result, raise the text-and-tool history budget from 120,000 to 480,000 characters, and remove screenshots in batches. Under a 20:1 policy, the agent could hold up to 20 screenshots and then cut back to one, leaving about 19 append-only calls between rewrites. Simply adding history caching without stabilizing that history cost more than not caching it on three of four models at the larger budget.

The study ran 144 trials on one catalog task

CAT32 asked the agent to browse a public demo bookstore, collect six fields for each of 32 books and return a table plus price totals: 192 reference facts. Each model received six policies at two character budgets with three runs per condition, producing 36 selected runs per model and 144 overall. A later no-pruning follow-up added four runs on each of three models.

The four names were GPT-6.1 Sol and anonymized Models A, B and C from another frontier provider. Model B was the original production choice. Model A and B ran from September 14 to 23; Model C and Sol ran on September 30 under a different protocol. Sol used gpt-6.1-sol through the Responses API, high reasoning effort, a 30-minute cache lifetime and standard pricing. Asana therefore labels cross-model comparisons descriptive rather than controlled head-to-head evidence.

The best Sol condition averaged $0.47 with 89% cached input

At the 480,000-character budget with 20:1 screenshot pruning, the three Sol runs cost $0.45, $0.51 and $0.46, or $0.47 on average. They took 25, 35 and 24 calls and 3.7, 4.5 and 3.8 minutes. Cached reads represented 88%, 91% and 88% of input. OpenAI’s published rates for gpt-6.1-sol were $2 per million standard input tokens, $2.50 for cache writes, $0.10 for cache reads and $10 for output; no request crossed the study’s long-context price threshold.

Model B’s original 120,000-character baseline averaged at least $36.21 because one of three runs hit the cap, while its best tested condition averaged $1.24. That separates two effects: workflow changes cut Model B cost at least 29-fold, then the same optimized design on Sol cost another 2.6 times less. The 76× comparison combines an architecture change with a model and provider change; it is not a model-only speed or price ratio.

A larger budget reduced repeated work and missing answers

At 120,000 characters, Model C answered none of 18 runs and Sol answered three; most reached the step limit after repeated trimming. At 480,000 characters, all 18 runs for each model delivered an answer, and the final Sol requests retained all 192 facts. Keeping more context increased per-call input but reduced calls and moved most repeated input onto cheaper cache reads.

The larger number is not a universal minimum. No 480,000-character run actually reached the budget, and the biggest request in the follow-up was about 151,000 input tokens. A different site, tool schema, image policy or task length could behave differently. History should grow only within explicit context, step, token, wall-time and dollar ceilings; otherwise append-only design can turn a looping agent into a large uncached bill when one edit breaks the prefix.

Answer evidence was narrower than the headline suggests

Asana checked persisted outputs against an independently prepared catalog reference rather than accepting the agent’s success claim. Every best-condition run saw all 192 facts. At the large budget, Sol answered all 18 runs and stated the correct total in all 18. However, Sol returned a short summary rather than the requested full table; final-answer tuning was outside the study’s scope.

The result therefore supports fact collection and one total on CAT32, not general browser-agent accuracy. It does not measure login flows, dynamic pages, adversarial instructions, accessibility trees, captchas, purchases, write actions, recovery from browser failure or correctness across changing customer sites. The public catalog was live, and the paper notes that its independently prepared reference could not guarantee identical pages across every run.

Three repetitions cannot rank small differences

The cheapest condition was selected after observing 12 conditions per model, which creates selection bias. Most conditions had only three repetitions, one Model A condition had two analyzed runs, and parallel workflows competed for machines and providers. Baseline caps make some savings ratios lower bounds, while a stopped run may be cheaper only because it failed to finish.

Asana explicitly says the study maps broad patterns rather than distinguishing configurations a few percent apart. The two phases changed effort, tool choice, API adapter and cache lifetime. Estimated model costs use native token counters and dated list prices, but exclude browser sandboxes, application servers, engineering, review and other infrastructure. These are useful disclosures; they also prevent treating $0.47 as an all-in production unit cost.

What browser-agent teams should do next

Instrument the actual outbound request, not just application settings. For each call, record uncached input, cache writes, cache reads, output, prefix break reason, retained facts, screenshots, tool calls and elapsed time. Start with an append-only history, then test whether and when pruning becomes necessary. A cache write that is never read is extra cost, and a summary that silently loses task-critical state is not an optimization.

Replay several production-shaped tasks across at least one ordinary, one long and one failure-prone trajectory. Predeclare answer checks and severe-failure gates, randomize or balance run order, increase repetitions where differences are close, and include sandbox and human-review costs. Ship behind a reversible cohort only when accepted-task cost falls without weaker completion, safety or recovery. Preserve hard limits even when the best test never reached them.

Disclosures

AccessAllGPT received no Asana, StackAI, OpenAI, Codex or Command account, code, traces, credits, briefing, benchmark data, review, payment or compensation for this article. Asana and OpenAI did not sponsor, review or endorse it. AccessAllGPT did not test or rank the named or anonymized models. AccessAllGPT Research is operated by NeuralArc, is independent, and is not affiliated with Asana, StackAI or OpenAI. Publication-wide relationships are listed on the disclosures page.