Computer-Use Agents &Browser Automation in 2026

The most useful fact about computer-use agents in August 2026 is a commercial one, and it is the least reported. Both flagship consumer browser agents shut down.

OpenAI's Operator — the product that made "an AI that uses your browser" a category in the first place — was deprecated and shut down on August 31, 2025, with its capability folded into ChatGPT agent. Nine months later, on May 4, 2026, Google shut down Project Mariner and absorbed it into Gemini Agent and AI Mode. Google named its reasons, which is rarer and more valuable than the shutdown itself: the heavy compute required for real-time visual processing, slow performance, and form-selection errors.

Read that list again, because it is a free engineering post-mortem from a company with more resources than you have. Compute cost. Latency. And the specific, unglamorous failure of picking the wrong form field. Those three are exactly what a team building this discovers in week six, except Google discovered it at consumer scale and then stopped.

This matters commercially because the pitch you will hear from vendors in 2026 is often still the 2025 pitch. If someone demonstrates an agent booking a flight across four websites, you are watching a demo of the exact product category that two of the best-resourced labs on earth withdrew from. Ask what they know that OpenAI and Google did not.

Commercial state of computer-use and browser-automation offerings, August 2026. Star counts and release versions are live GitHub data as of August 10, 2026.

Notice the shape of what survived. The API capability survived, because it lets an engineer scope the job. The open-source library survived, and thrived. The hosted infrastructure survived, because someone has to run the browsers. What did not survive is the product that promised to do anything on any website for a general consumer. That distinction is the whole article.

Strip the marketing and there are three distinct mechanisms, frequently conflated, with wildly different reliability and cost profiles.

• 1. Vision-driven computer use: The model receives a screenshot, reasons about it, and emits mouse and keyboard actions — click at these coordinates, type this string, scroll. It works on anything a human can see, including native desktop applications and Citrix sessions, which is its whole advantage. It is also the slowest and most expensive of the three, because every step costs a screenshot's worth of image tokens plus a full inference round trip.
• 2. DOM-driven browser automation with a model in the loop: The agent reads an accessibility tree or a filtered DOM rather than pixels, and acts on elements rather than coordinates. Far cheaper per step, far more precise, and it degrades in a more debuggable way. It cannot see what is not in the DOM — canvas apps, embedded viewers, native dialogs — and it breaks when the page's structure changes underneath it.
• 3. Deterministic automation with model-assisted repair: A recorded script runs the flow. The model is invoked only when the script fails, to diagnose and patch the selector or step, after which the script runs deterministically again. This is the cheapest, fastest, and most reliable of the three by a wide margin, and it is what most successful production deployments quietly converge on.

The industry conversation is almost entirely about the first mechanism. Most durable production systems are built on the third. That gap is where a lot of budget goes to die.

There is also a category boundary worth stating plainly. A browser agent is not a scraper and not an RPA tool, though it overlaps both. Scrapers extract; agents act, which is what makes their failure modes consequential. Traditional RPA is deterministic and brittle in ways you can see; a model-driven agent is adaptive and brittle in ways you cannot. Neither property is strictly better — but only one of them fails silently.

The mechanism choice is also the cost choice, and the difference is not marginal. Vision-driven computer use pays image tokens on every single step; DOM-driven automation pays a fraction of that; deterministic replay pays nothing to the model at all until something breaks. When someone quotes you a per-task cost for "an agent," the first clarifying question is which of the three mechanisms they are describing, because the answers differ by more than an order of magnitude.

A deterministic script that breaks loudly is more operable than a model that improvises quietly. Use the model to repair the script, not to be the script.

— Frenchy Digital engineering principle

The progress here is genuine and worth stating before the caveats. OSWorld is 369 tasks in a real operating system — file management, spreadsheets, multi-application workflows, the sort of work that resists shortcuts. Its human baseline is 72.36%. The original 2024 state of the art was 12.24%. Whatever else is true, a category that moved from twelve percent to roughly human parity in two years is not a category that stalled.

Now the caveat, which is the actual story. The verified numbers and the self-reported numbers diverge sharply, and they diverge for the same models.

That has a direct operational consequence. If you are evaluating a vendor, or writing a technical claim, the rule is simple: cite OSWorld-Verified, name the harness, or do not cite. A number without a harness attached tells you nothing you can act on, because the harness is doing more work than the model.

Computer-use and web-agent benchmark landscape as of August 2026, with the verified-versus-self-reported distinction made explicit.

On the web side specifically, prefer WebArena over WebVoyager. WebArena is harder and substantially more reproducible; OpenAI's CUA reaches 58.1% there, and the best specialized enterprise scaffold sits around 61.7%— up from roughly 14% eighteen months earlier, which is the same real-progress story OSWorld tells. WebVoyager's headline numbers are much higher and much less useful: they are self-reported, against a live web that mutates underneath the benchmark, with no shared harness.

Then there is the problem underneath all of it. In April 2026, a UC Berkeley group demonstrated that essentially every major agent benchmark is reward-hackable — reaching around 100% on WebArena and 73% on OSWorld without solving a single task, via mechanisms like config leakage, prompt-injected judges, and virtual-machine state manipulation. A follow-up catalogued 219 distinct flaws across ten benchmarks. This does not mean published scores are fraudulent. It means a benchmark score is evidence about a scaffold under a specific harness, not a measurement of capability you can transfer to your workload.

One more framing note that applies across agent evaluation generally: these benchmarks score whether a task completed, not whether it completed every time. Reliability under repetition is a different measurement and a much less flattering one. If your workflow needs the same task to succeed on consecutive attempts, single-run pass rates systematically overstate what you will observe.

Benchmarks tell you about a distribution of tasks. What you need is a boundary you can apply to your task before you spend anything. Here is the one we use on scoping calls, and it has held up better than any score.

Reliable: structured, single-site, short-horizon flows against a stable DOM. Unreliable: long-horizon multi-site tasks, drifting selectors, session interruptions, auth walls, and anything where a wrong click cannot be undone.

Reliability boundary for computer-use agents — the scoping heuristic Frenchy Digital applies before recommending this mechanism, 2026.

Step count is the single best predictor of whether a flow will hold. Error compounds across steps, and it compounds multiplicatively rather than additively — a per-step reliability that looks excellent in isolation becomes unacceptable by step thirty. This is the mathematical reason long-horizon consumer tasks like "plan and book my trip" were always the wrong first product, and why the products built on that promise are the ones that shut down.

The second-best predictor is whether anything on the page changes for reasons unrelated to you. A vendor portal that ships quarterly is workable. A consumer site running continuous A/B tests, rotating cookie banners, and promotional interstitials is a maintenance contract you signed without reading.

Computer-use agents have an unusual cost structure: the dominant term is not the model, it is the number of steps. Every step costs an inference call, an image payload, an action round trip, and a screenshot. Nothing amortizes.

Cost and latency components for computer-use agents. Per-task and per-action figures are weak, largely secondary estimates; Browserbase figures are from its published pricing page, checked August 10, 2026.

Do the arithmetic once and the design implications fall out. At roughly 200 to 510 milliseconds per action warm, plus 10 to 30 milliseconds per remote screenshot, a hundred-step session spends somewhere between twenty and fifty seconds purely on action latency — before any model inference. Interactive use is therefore off the table for anything but very short flows. Batch is the natural execution model, and "how many steps" is the question to ask before "which model."

The token side compounds the same way. Anthropic reports that agents use roughly four times the tokens of a chat interaction, and a vision-driven loop is worse than the average agent because it ships an image every step. If you are modelling cost, model it per step and multiply, and re-baseline against your provider's current published pricing rather than a figure from a blog post, because these change monthly.

A related trap worth naming, because it is invisible in a dashboard: tokenizers change. Claude 4.7 and later, including Sonnet 5, use a tokenizer that produces roughly 30% more tokens for the same text than earlier models. The per-token price did not change; the cost per request did. If you carried a cost model across a model upgrade by applying a multiplier to your old token counts, that model is wrong. Re-baseline with the provider's token-counting endpoint against real payloads rather than estimating — and for a computer-use agent, do it on a real screenshot-bearing request, not a text-only one.

One operational note that catches teams out: idle sessions bill. Browserbase charges $0.12 per browser-hour in overage, and a crashed agent that never closes its session keeps that meter running until something reaps it. Session lifecycle management is not hygiene here, it is a line item.

This section is longer than it would be in any other article in this cluster, because the risk here is not incidental to the architecture — it is the architecture.

Simon Willison named the pattern in June 2025: the lethal trifecta is access to private data, exposure to untrusted content, and the ability to communicate externally. Hold any two and you are broadly fine. Hold all three in one process and an attacker who controls the untrusted content can read the private data and ship it out — with no exploit code, because the page itself is the payload.

A browser agent holds all three by definition. It is logged into your systems (private data). It renders pages written by strangers (untrusted content). It can submit forms, send messages, and navigate anywhere (external communication). There is no configuration in which a general-purpose browser agent does not have the trifecta; the only question is how much blast radius each leg carries.

Now add the specific escalation: indirect prompt injection reaching an agent that can click. In a chatbot, a poisoned page produces a wrong answer. In a browser agent, the same text becomes an instruction to an entity holding your session cookie. The attack surface is every piece of text and every image the agent renders — including content in a page the user never intended it to visit.

Measured efficacy of prompt-injection controls relevant to browser agents. Vendor-reported figures are marked as such; adaptive-attack results come from independent and multi-lab research.

The most directly relevant published numbers come from Anthropic's Claude for Chrome evaluation. In autonomous mode across 123 test cases and 29 scenarios, attack success was 23.6% without mitigations and 11.2% with them. On a challenge set of four browser-specific attack types, mitigations took attack success from 35.7% to 0%. That is the cleanest prompt-injection number any frontier lab has published for a browser agent, and it should be read in full: a 0% on one narrow challenge set, alongside a residual 11.2% on the broader evaluation — which is not near-zero — measured non-adaptively, meaning the attacker was not tuning against the defense.

The strongest single piece of evidence in this area is "The Attacker Moves Second", a joint effort across OpenAI, Anthropic, Google DeepMind, ETH Zurich and Northeastern. Twelve published defenses were bypassed, most above 90% attack success, and the paper notes that the majority of them had originally reported near-zero rates. Human red-teaming succeeded on 100% of scenarios where static attacks succeeded on 0%. Read alongside CAISI's finding that raising the attempt budget from 1 to 25 lifted average attack success from 57% to 80%, the picture is consistent: attackers get more attempts than evaluations give them.

The labs themselves are careful about this, and it is worth quoting them rather than paraphrasing. Google's researchers write that "even with model hardening, no model is completely immune," and that indirect prompt injection "is not the kind of technical problem you solve and move on." OpenAI states that prompt injection, much like scams and social engineering on the web, is unlikely to ever be fully solved. Nobody credible claims otherwise. If a vendor does, that is diagnostic.

Two structural findings round this out. First, the security-fidelity tradeoff appears to be fundamental rather than an artifact of immature defenses: the SecFid benchmark reports the highest-fidelity configuration at 96.5% fidelity and only 47.8% security, the most secure at 99.3% security and 71.0–73.9% fidelity, and concludes that no model or defense achieves both. Second, and more uncomfortable, a 2026 position paper co-authored by Dawn Song observes that across every injection task in AgentDojo and WASP, the injected action is one an authenticated user would plausibly request in a routine workflow. Content-based detection is trying to distinguish a legitimate request from an identical illegitimate one.

The architectural defenses hold up better than the in-band ones, and it is worth being precise about what they cost. CaMeL, Google DeepMind's capability-based data-flow approach, recorded zero successful attacks across 949 runs with policies enabled — a genuinely strong result. The same paper measured utility dropping from 90.72% to 63.92% on the model it evaluated, collapsing to 25% on the travel suite, costing 2.82× input tokens, with the authors self-reporting a side-channel vulnerability that undermines the strong-guarantee claim. That is the honest shape of the tradeoff.

The design pattern most often reached for is the dual-LLM split: a privileged model that holds the tools and never sees untrusted content, a quarantined model that reads the untrusted content and has no tools, and a deterministic controller passing opaque references between them. It is a sound idea and worth knowing. It is also worth quoting its author's own assessment — "This solution is pretty bad!" — because he published it as a design proposal with no measured numbers, and later endorsed capability-based enforcement as the rigorous version. Treat the pattern as a way to reason about where untrusted text is allowed to touch a tool, not as a defense with an efficacy figure attached.

Design as though injection will succeed, because sometimes it will. The goal is not a browser agent that cannot be compromised. The goal is a browser agent whose compromise is bounded, observable, and recoverable — scoped credentials, an egress allowlist, resolved-target approval, and a step budget.

— Frenchy Digital security principle

Map your controls against the OWASP Top 10 for LLM Applications and the NIST AI Risk Management Framework. Neither will make an agent safe, and neither claims to. Both give you a vocabulary your security reviewer already accepts, which is worth more than it sounds during a procurement cycle.

The most valuable output of a computer-use feasibility review is usually the recommendation not to build one. If a documented API exists for the system you want to automate, use it. This is not a close call.

• Idempotency: An API tells you whether an operation already happened. A browser agent that times out after clicking Submit has no idea whether the order was placed, and neither do you.
• Typed errors: A 409 is actionable. A screenshot of a red banner in a language you did not anticipate is a research project.
• Versioning and deprecation notice: APIs change on announced schedules. Web pages change on Tuesday because someone shipped a redesign, and your first signal is a drop in success rate.
• Authentication that is not a human's session: API credentials can be scoped, rotated, and revoked. A stored browser session is a human identity that your automation is impersonating, with all the audit ambiguity that implies.
• Rate limits you can reason about: Documented quotas beat discovering an anti-automation threshold by getting your account locked mid-run.
• A support contract: When an API breaks, there is someone to call. When a page changes, there is only you.

The second-best option is also usually not an agent. If the vendor supports scheduled exports, SFTP drops, or webhooks, take them. A nightly CSV you can diff is more reliable than a screen-driving agent and roughly two orders of magnitude cheaper to operate. Unglamorous integrations have an excellent track record.

Computer use earns its place in a genuinely narrow set of situations, and they are worth naming precisely: legacy internal systems with no API and no vendor left to ask; third-party portals that will not open one — insurers, government filing systems, supplier extranets; one-off migrations and historical backfills where fragility barely matters because the job runs once under supervision; and cases where the integration cost of a real API exceeds the value of the workflow, which is a legitimate answer for a low-volume process nobody will fund properly.

If you have worked through the decision and computer use is genuinely the right mechanism, here is the control set. It is not optional and it is not expensive relative to the cost of skipping it. Everything here assumes the agent will occasionally do the wrong thing, because it will.

Control set for a production computer-use agent — Frenchy Digital reference architecture, 2026.

Three of these deserve expansion because they are the ones most often skipped.

Credential scoping is the highest-leverage control in the stack. The overwhelming majority of catastrophic browser-agent scenarios require the agent to hold permissions the workflow never needed. An agent that reconciles invoices should be logged into an account that cannot issue refunds, cannot change bank details, and cannot read unrelated records. This is ordinary least-privilege discipline, and it converts most injection outcomes from incidents into log lines. It also survives every future model change, which is more than can be said for any prompt-level defense.

The egress allowlist removes a whole leg of the trifecta. If the browser cannot reach an arbitrary host and the network cannot either, an injected instruction to exfiltrate has nowhere to send data. This does not stop destructive action inside an allowed domain — nothing does — but it turns a data-theft scenario into a much smaller problem. Deny by default; each new destination is a reviewed change with a name attached.

The determinism ratchet is where the economics come from. Once a flow succeeds, record the trajectory and replay it deterministically. Invoke the model only when replay fails, to diagnose and patch. A flow that runs a thousand times a day then costs one model invocation on the day the site changes, rather than a thousand vision-loop sessions daily. It also removes the latency problem, the cost problem, and most of the variance problem at once. Teams that get durable value out of this category almost all arrive here eventually; arriving deliberately is cheaper than arriving after a quarter of surprising bills.

On evaluation: build the suite from real failures, replay it in CI, and re-run it on every scaffold change — not only on model upgrades. The OSWorld-Verified-versus-tracker gap is the empirical argument for this. If a six-to-eleven-point swing can come from harness differences on a public benchmark, your own scaffold changes are moving your numbers at least as much, and you will not notice without a suite. Our multi-agent architecture guide covers the orchestration side of the same problem.

Three things cover most of what a team actually needs, and the shape of the list is itself informative.

• browser-use — the open-source default: At 108,638 GitHub stars as of August 10, 2026, it is the most-starred agent repository of any kind, ahead of every orchestration framework. Latest release 0.13.7, shipped July 27, 2026. It is a library, not a product: you own the loop, the sandbox, the retry policy, and the failure handling. That ownership is the point — it is also the work.
• Anthropic's computer-use API — the capability, unbundled: Exposes computer use as a tool the model calls, with you supplying and running the sandboxed virtual machine. The isolation story is explicitly yours, which is more honest than a hosted product implying it has solved containment for you. A macOS research preview for Pro and Max users launched March 24, 2026.
• Browserbase — hosted browser infrastructure: Managed headless sessions, proxying, and session lifecycle. It is infrastructure beneath your agent rather than an agent, and it is priced accordingly: plans from free through Developer at $20/month and Startup at $99/month, with $0.12 per browser-hour overage and API calls at $1 per 1,000 on Developer, $0.50 on Startup, and $4 per 1,000 through proxies.

What is missing from that list is the most important part of it. There is no flagship consumer browser agent on it, because there is no longer one to list. The surviving tooling is all builder-facing: a library, an API capability, and infrastructure. That is what a category looks like after it stops trying to be a consumer product and starts being a component.

One consequence of that shape is worth planning around: nobody is going to sell you an outcome here. A library, an API, and a browser host are three components you assemble, operate, and are accountable for. If your business case assumed a vendor would own reliability, revisit it — the vendors who were willing to own reliability for general web tasks are the ones who left.

A note on version claims generally. A great deal of what circulates as 2026 tooling comparison is search-optimized content with fabricated release numbers — versions and dates that live GitHub data contradicts outright. Check the repository and the release tag yourself before you believe a version number in a blog post, including this one. The figures here were read from live repository data on August 10, 2026, and they will age.

Find your row. The recommendation column is what we would say on a call, and the reasoning column is why.

Frenchy Digital decision framework for computer-use and browser automation, 2026.

Two additional questions decide most borderline cases. First: what does a wrong action cost?If the answer is "we re-run it," you have latitude. If the answer involves a counterparty, a regulator, or money that has left the building, you need per-action approval, and per-action approval frequently destroys the business case — which is useful information to have before you spend, not after.

Second: how often does the target change? Multiply your best guess by your team's cost of a repair cycle, then compare that to the labor you are automating away. A surprising number of these projects are net-negative on that arithmetic alone, before any discussion of reliability or security. The build-versus-buy analysis works through that comparison in more depth.

Every one of these has shown up in a real evaluation. None are hypothetical, and several are the default behavior of the category's marketing.

The Frenchy Digital red-flag list for computer-use and browser-automation buyers, 2026.

Ask to see it fail. Any vendor can demonstrate a happy path on a site they rehearsed against. Ask them to run it on your site, with your cookie banner, from an expired session, and show you what the agent does when it does not know what to do. That five-minute test predicts a year of operations better than any benchmark.

— Frenchy Digital buyer’s principle

These are the bands Frenchy Digital uses to scope agent engineering work in 2026. They assume the sandboxing, credential scoping, approval gates, step budgets, trajectory logging, and evaluation suite are in scope from the start — because retrofitting them is what makes this expensive.

Frenchy Digital cost bands for AI agent engagements, 2026.

Senior-led delivery runs $150 to $225 per hour, and ongoing retainers run $2,500 to $9,500 per month covering model and dependency upgrades, evaluation expansion, incident response, and a quarterly technical review. Every engagement carries a 30-day post-launch warranty, and you receive a written scope with a fixed-price phased proposal within 5 business days of the discovery call.

Included at every tier: full source-code and IP ownership transferred to you at delivery, no vendor lock-in, and an honest recommendation during discovery about whether computer use is the right mechanism at all. Frenchy Digital is a senior-led Black-owned Los Angeles agency, and we would rather tell you to build an integration than sell you an agent that needs a babysitter.

Everything above is stated as of August 2026 and will age. Here is what is genuinely uncertain, weakly evidenced, or likely to change — stated plainly, because a decision made on overstated evidence is worse than one made on none.

• The cost and latency figures are weak: The $0.03–$0.13 per task range and the 200–510 ms per-action latency come from limited, largely secondary sources. They are order-of-magnitude guidance, not a budget. Measure your own workload before you commit to a unit price with a customer.
• Benchmark scores measure happy-path completion only: None of OSWorld, WebArena, or WebVoyager measures graceful failure, partial-completion detection, or the cost of a wrong action. An agent that fails safely and one that acts wrongly score identically, and only one of them is shippable.
• Every major agent benchmark is reward-hackable: A UC Berkeley group reached around 100% on WebArena and 73% on OSWorld without solving a single task, and a follow-up catalogued 219 distinct flaws across ten benchmarks. Published scores are evidence about a scaffold under a harness, not transferable capability.
• Prompt injection is not solved and will not be during this planning cycle: Anthropic's 11.2% residual is a non-adaptive measurement. Twelve published defenses were bypassed above 90% attack success in a joint multi-lab study. Google states no model is completely immune; OpenAI states the problem is unlikely ever to be fully solved. Plan for blast-radius reduction, not prevention.
• Security and utility trade against each other, apparently fundamentally: The SecFid benchmark reports the highest-fidelity configuration at 96.5% fidelity and 47.8% security, the most secure at 99.3% security and 71.0–73.9% fidelity, and concludes that no model or defense achieves both. Expect to give up capability for containment.
• Human-in-the-loop is weaker than it looks: GhostApproval defeated approval dialogs across six AI coding assistants because the dialog named the wrong target. Approval is only a control over what is rendered, resolved, and legible — and building that rendering is real work, not a checkbox.
• Model and tooling figures perish quickly: Star counts, release versions, benchmark standings, and provider prices in this article were verified on August 10, 2026. Prices in particular change monthly. Re-verify anything you intend to put in a business case.
• Terms of service and legal exposure are not addressed here: Automating a third-party site may breach its terms regardless of technical feasibility, and defeating anti-automation controls carries exposure this article does not evaluate. Get that reviewed before you build, not after.

None of this argues against building. It argues for choosing the narrow workflow, scoping the credentials, bounding the steps, instrumenting the failures, and being honest with your own organization about the fact that two of the best-funded labs in the world tried the general version of this and withdrew. The teams getting value here are the ones who treated computer use as a last-resort mechanism for a specific job — not as a platform.