BROWSER USE - Browser Use Agents: give Browser Use a task and receive completed work. API V4 is current for new integrations. - Browser Infrastructure: connect your agent or automation to managed browsers through SDK, REST, or CDP. Starts at $0.02/browser-hour. - Developer tools: Open Source, Browser Harness, SDK, and MCP support the two products above. [Developer Index](https://browser-use.com/index.md) [Product Map](https://browser-use.com/llms.txt) [Full Product Context](https://browser-use.com/llms-full.txt) [Pricing](https://browser-use.com/pricing.md) [Cloud Docs](https://docs.browser-use.com/cloud/quickstart) [Open Source Docs](https://docs.browser-use.com/open-source/introduction) --- # How we Made Scalable Long-Horizon RL Environments for Browser Use **Author:** Alexander Yue **Date:** 2026-08-26 > Browser agent benchmarks are saturating. This is how we build RL environments from real user traffic against the real web. --- Browser agent benchmarks are saturating. Task sets that separated models a year ago now return pass rates above 90 percent. A good reinforcement learning environment needs the same things a good benchmark task needs, and neither is easy to build. The tasks have to be real. Synthetic site clones are reproducible and cheap to verify, but they strip out the properties that make the live web hard. Both also need a reward that is fair and that holds still: a judge that can tell good work from bad. This post describes how we build RL environments from real user traffic against the real web. We produce them continuously, and the 200 we are open sourcing are a sample. The source is derived from an anonymized version of our production corpus of browser agent tasks, so every task is something a person actually wanted done, not something an author imagined a person might want. The harder half of the problem is the reward. Below we describe how we build each rubric from the full set of attempts at its task, verify it against the live web, and then measure its stability by regrading frozen traces. ## 1. Filtering Down the Tasks The source corpus is production browser agent traffic, several hundred million task submissions over the collection window. Most of that volume is repetition, so we combine similar tasks down to about ten million distinct ones. We drop what no third party could run or should see: tasks addressing local network addresses or local files, tasks that are not confidently English, tasks outside 25 to 20,000 characters, and tasks matching known public benchmark content, which would contaminate any result we report. Every task comes from a source where we hold the rights to use and to sell the content, and traffic under a restricted data-use agreement never enters the corpus at all. ## 2. Suitability Most real user tasks do not make a usable environment, for reasons visible in the text alone. Some are too easy, answered by a search engine or by the model's own knowledge, and never needed a browser. Some carry personal information. Some take destructive or irreversible actions on a live site, such as submitting a form or making a purchase, which cannot be repeated on every evaluation run. Some are impossible as written, and some are too vague for any grader to decide. Before spending anything on execution we need a cheap filter that reproduces an expert judgement of suitability at corpus scale. ### 2.1 Hand labelling We began by hand labelling 900 tasks in a twelve hour sprint, using our experience with benchmarks to pick out the tasks that were both suitable and hard. Each one got a mark of suitable, unsuitable, or uncertain, and a written reason for the mark. Those reasons are the reference the rest of this section is built against. ### 2.2 Aligning a labelling agent We split the labels once, deterministically, by a hash of the task text: 80 percent for development, 10 percent held out for validation, and 10 percent sealed for a final test. The split is frozen and was never recomputed. We automated the prompt writing as well. An autoresearch agent, built on Claude Fable 5, got our written reasons and the development split, and had one job: produce a single-call prompt for Gemini 3 Flash that reproduces our labels. It proposed variants, scored them, and kept what survived, over 21 prompt versions. A model comparison at fixed prompt confirmed the choice of a small model. Gemini 3 Flash reached the highest agreement at roughly one fifth the cost of the larger candidates, which were systematically over-conservative: they threw away suitable tasks that we had accepted. The deployed prompt agrees with our labels on 77 percent of items, and on 81 percent of the sealed split it had never seen, at a cost on the order of $20 per thousand suitable tasks found. Run over the whole candidate sample, it marked about 13 percent of the tasks suitable. ## 3. Personal Data Replacement Real user tasks contain real personal data, and none of it can appear in anything we ship. The naive response is to detect and discard, but that response is wrong on the merits and expensive in yield. In a large fraction of real tasks the personal data is incidental to the work. Discarding such a task throws it away to remove a detail it does not depend on. So we use a different criterion. **A task is suitable if it can be run, and can succeed, with every piece of personal data replaced by our own standard dummy persona.** That question has a decidable answer and turns the personal data problem from a filter into a rewrite. We discard only when the rewrite cannot preserve the work, or when a combination of specific personal facts identifies a person, because string replacement cannot neutralise that. Replacements have to remain usable by a live site. When a task is not US-based we adapt the persona to the country of the task. Every replacement is a verbatim string substitution made in code, after we verify that the target string is actually present, so the model never rewrites the surrounding prose and never alters the task's meaning. ## 4. Feasibility and Difficulty A task that passes the first two filters is well formed. We still do not know whether it can be run, or whether it is hard. A task can be impossible now for reasons that have nothing to do with agent capability. It may have depended on the account or the personal artifact that the previous stage removed. It may have gone out of date, which is the single largest source of tasks that were once possible and now are not. It may never have been possible at all. And separately from all of these, it may simply be too easy, in which case it is well formed, possible, and useless for separating models. None of these show up in the task text, which is why they survive Section 2. All of them show up in a small number of real attempts, so the screen has to run the task. We run it with MiniMax M3 served on Fireworks. The reference model does not need to be strong. It needs to be consistent, cheap enough to run many times, and good enough that its failures tell us something instead of all looking alike. Of the well-formed tasks that reach this screen, a little over 40 percent come through it as both possible and hard enough to keep. ## 5. The Problem with Judgement Screening by execution requires a grader, and the requirement looks impossible. Today's frontier models complete fewer than 10 percent of these tasks perfectly. So how can a grader running those same frontier models decide what a perfect completion looks like? This is the trap most LLM graders sit in: the judge is no smarter than the agent. It can, because grading and solving are different problems. The grader does not need to be smarter. It needs to see more. Human graders work this way already. A grader assigned one exam question reads every attempt at it, and after enough of them knows the correct answer, the common wrong turns, and the answer that looks right but is not. None of that requires being the best mathematician in the room. It comes from having seen the whole distribution of attempts at one problem, which no individual student does. Language models keep nothing between calls, so we have to accumulate that exposure by hand. The best learning available to a model at inference time is its own context, so we give each task a file that the grader writes to and reads from. The file holds what we have established about that one task: what the correct answer is, which paths reach it, which failures recur and what they look like in a trace, and which claims agents make that are not true. It is provided only to the grader and never to the agent. We call this file a rubric, after the human artifact it imitates. The remainder of this report is largely about how to construct one that is correct and stable, because a rubric that is neither is worse than no rubric at all: it produces confident, reproducible, wrong scores. ## 6. Difficulty Estimation There is a catch-22 in finding task difficulty. Scoring runs needs finished rubrics, and creating the rubrics needs scored runs. Waiting for a mature rubric before screening would mean paying full run cost on every candidate, including the ones that are trivially easy or trivially broken. So we must accept a difficulty estimate made while we are still gathering traces. After each judgement, the grader writes what it learned into the task's rubric file, and the next judgement of that task reads it. The rubric is always the best description of the task that the runs so far can support. Early judgements work against a nearly empty rubric and are unreliable to match. Later ones work against a rubric that has collected real failure modes. That is enough for a screening decision, which only has to tell "everyone finishes this" apart from "nobody can start this", and it is cheap enough to run on every candidate. The screen itself is a sequential test with early stopping, because most candidates can be decided in fewer than the maximum number of runs. Tasks at a zero pass rate are escalated to a stronger model, Claude Opus 4.8, to separate "hard" from "impossible". In one such pass the stronger model completed roughly a third of the escalated tasks, which then enter the pool as hard but possible. About half showed substantial partial progress, and the rest were either confirmed impossible or left pending. ## 7. Rubric Construction The iteratively developed rubrics we produced during screening are not the rubrics we ship. This section explains why, and how the shipped rubrics are built. We rewrite the user tasks in the language of a personal request, standardizing and anonymizing formatting details while preserving all task instructions. ### 7.1 Why iterative rubrics do not converge It is natural to expect the iterative loop of refining rubrics discussed in Section 6 to converge to a perfect rubric given enough loops. Each judgement adds information, so the rubric should approach a correct description of the task and then stop changing. In practice it does not, and the reason is structural. Every judge in that loop sees exactly one trace. It cannot compare an agent's claim against another agent's claim, and it has no way to check a claim against the live site. When an agent states confidently, but incorrectly, that a page has seven listings, the judge has no basis on which to doubt it, and that number may be written into the rubric as an established fact. Every later judgement then reads it as ground truth. If it was wrong, the loop does not correct it, punishing all future correct answers until the rubric is edited back. We observed this with data. The edit rate does not taper on the tasks we care about: on hard tasks it was still 59 percent at the ninth wave of runs. The rubric was oscillating between differing interpretations and self-correcting endlessly. ### 7.2 The parallel rubrics we use instead Once we have estimated the difficulty and selected the challenging tasks, we need a wide variety of attempts to explore the solution space of each task. We run a fleet of 9 models, twice each: Claude Opus 5, GPT-5.6 Sol, GPT-5.6 Luna, GPT-5.5, Gemini 3.1 Pro, Gemini 3.7 Flash, Gemini 3 Flash, Grok 4.5, and MiniMax M3. A single agent, built on Claude Fable 5, then writes each rubric. The many traces are written as files alongside the iterative judge's findings. The agent can search selectively through the traces, retrieving relevant context, validating against the real web, and determining the ground truth and the valid paths. The screening judgements are the entry point. They are unstable as rubrics, but are a rich history of suspected issues among traces. The agent takes a claimed defect, opens the trace that produced it, and decides whether it is real. Nothing from those judgements is carried forward on trust, and no score or verdict from them is reused. Leads that survive the traces are then checked against the world. The agent opens a live browser and verifies the facts it intends to rely on, against the actual site, today. Every fact it records carries the date on which it was checked. Facts of the form "this value appears nowhere on the site" are marked separately, because a universal negative can only ever be left unfalsified and never proved. ### 7.3 Properties of a good rubric How do we define a good rubric? Here is what we came up with. *Every claim must be easily verifiable, and claims are split by who makes them.* The rubric makes claims about the task and the website. Those are claims about the world, they were checked against the live site on a recorded date, and anyone can open the site and verify. The grader states findings, claims about the agent's trace, and each one must cite the step where the evidence appears. A human should be able to see the judge's claims and verify directly in the agent's trace whether they are true. Neither the rubric nor the grader ever emits a score. Code computes the score from the findings. That is what makes the artifact auditable end to end: every output of a language model in the pipeline is a specific, located claim that a human can confirm or refute, and none of them is a judgement call that has to be taken on trust. *Items are atomic.* Each item checks one thing over one scope, so no single defect can be penalised twice. Weights sum to 100 and the score is the sum of the weights of the met items, with no worst-wins rule among the items and no negative marking, so partial credit comes from the granularity of the items and never from arithmetic inside one. That ordering is what makes the reward hard to game. Fabricated work earns nothing, because every item requires corroborating evidence in the trace, while honest incomplete work earns its honest portion. Separately from the items, the grader also reports whether reward hacking, lying, or fabrication occurred. The item score is computed first, in the normal way, and a positive flag then zeroes it, so dishonesty is never priced as the loss of one weighted item. ### 7.4 Stability as a measure of ambiguity For a benchmark, and much more so for a reward, the same trace must receive the same score every time it is graded. Language models are not deterministic, so we expect some variation. The useful observation is that the variation is not spread evenly. Most items are perfectly stable across regradings of a frozen trace, and the instability concentrates in a few. When we read the disagreeing pairs, we usually find that two runs of the same grader read the item's wording differently and drew the boundary in different places. So we treat instability as a signal of ambiguity in the rubric, not as noise from the model, and the item that flips tells us which sentence to look at. This is a measurable way to identify what parts of a task and rubric are ambiguous. Items are ranked by how often they flip between met and violated on identical input. For each item above threshold we go back to the original rubric-writing agent, which still has the traces and live web access, show it the disagreeing pairs of findings side by side, and ask it to rewrite the item as a decision rule sharp enough that two independent graders reach the same status. The loop runs up to three times. ### 7.5 Selection Not every task survives. We removed three classes of defect, in order. *Rubric ambiguity that did not resolve.* We dropped any task whose items were still flipping after three revision rounds. If three passes with full trace access and live verification cannot make the criterion decidable, the problem is the task, not the wording, and the task will never produce a usable reward. *Task interpretation forking.* Distinct agents read the same task text and pursue genuinely different objectives. Not all forking is a defect. Two agents may take different routes to the same answer. But when two agents disagree about what is being asked for, no rubric can be correct for both, and the task text is the defect. The only remedy is to clarify the task, which invalidates the existing runs and means gathering them again. A clarification may only state what counts as done, never how to do it, so it cannot leak a solution. Done well, this rescues many challenging and valuable tasks that would otherwise be discarded. *Temporal decay.* We removed tasks whose correct answer depends on an event that has not happened yet, or on data that turns over faster than a release cycle. A task pinned to a future date is guaranteed to be wrong later, and that is a slower and more damaging failure than being wrong now. We kept live-market tasks at lower preference, since their volatility is a cost to manage with dated facts and not a defect. The result is a task set in which every task carries an atomic, weighted, evidence-bearing rubric whose facts are dated and were verified against the live site, and whose items have been driven to a verdict flip rate below one percent on repeated grading of frozen traces. ## 8. Data Availability A sample of 200 of these tasks, with their rubrics, is open source at [github.com/browser-use/benchmark](https://github.com/browser-use/benchmark).