How to build frontier RL browser tasks - Browserbase x Hud

TL;DR

Training web agents with RL requires browser infrastructure that can run reliably at scale. Models will continue to become better at navigating the web. The bottleneck then shifts from capability to infrastructure and identity. At Browserbase, we have built the framework for secure and reliable web authorization and accessibility and are excited to partner with HUD to run frontier RL environments and evals that labs need.

What is a browser eval?

An unpredictable, dynamic web is core to what makes browser evals a valuable performance metric for models. A reproducible browser eval helps discern agent capability because it grades success the same way even as websites change. What makes a task valuable is covered in HUD's What is a good task? blog post.

What is a task?

A task encompasses a prompt, an environment with the files and tools the agent can use, and an outcome grader. HUD's QA agents additionally review execution traces for prompt alignment and reward hacking, flagging runs where an agent was wrongly given or denied credit. This gives teams a way to identify misleading scores and support reliable, verifiable grader outputs.

Beyond outcomes, The LiveWeb Samples we used in this blog are an example of a task set which groups them together for an eval run. Each sample uses a browser environment, sandbox and configuration (name, starting URL, prompt, rubric).

See the HUD overview, Tasks & Tasksets, and Creating Environments.

Common pitfalls in browser evals

Sufficient evidence and reproducibility are imperative in distinguishing model errors from shifts in websites, infrastructure, or grader-related discrepancies.

Given that the web itself is a live environment, it serves as an uncontrollable variable between runs. As a result, the opportunity for agents to reward hack exacerbates across several form factors. Improvements in browser and computer use enable models to modify web pages and deceive graders that check the appearance of success versus underlying outcomes. Agents can also access publicly available task set solutions, thus increasing success rates without verifying any sincere performance improvements. In this same vein, Anthropic has documented cases where models have exhibited eval awareness, recognizing that it was running BrowseComp and retrieving the benchmark’s answer key instead of solving the original research problem.

Identity and authorization also bear significant weight against an agent’s success on the web. Bot detection and CAPTCHAs often gate agents from accessing the intended task environment. Verified mode leverages Web Bot Auth to sign traffic and enables access providers like Cloudflare and reCAPTCHA to recognize agents. This allows website owners to set policy and enable broader access for agents.

Designing tasks for the live web

LiveWeb is HUD's internal set of tasks on live websites. HUD open-sourced them to show how it designs hard tasks. They cover turning a 3D model, reading photos, driving a data tool, and signing in.

The first three pin their answers to things that won't change (a fixed 3D model, the listing photos, and a date in 2024). Costco has no answer to go stale, so the grader checks each step of the sign-in. Ladybird grading takes one final integer with the exact count scoring a 1 and closer misses scoring higher than farther ones. Ranges or a list of alternatives do not count. The task asking about the number of chairs at the kitchen table requires an exact-match, because noticing the partially hidden chair is the visual challenge. AirNow grades four values with separate weights, so finding the right site but missing the AQI value still produces a score. AirNow shows what makes a task hold up on the live web. The answer isn't written anywhere on the site. It sits in historical air-quality data, so the agent has to find the map tool, move it, pick the date, and read four values. And since the date is in the past, the answer never changes.

Taskset: https://www.hud.ai/shared/tasksets/72a36a57-b90e-4b7f-a26a-e5e639656e04/tasks

Task definition

The three read-only LiveWeb Samples share one HUD environment, and Costco runs on a second one with the credential tools. The agent starts on a live URL and works from a prompt. Each task is YAML data under tasks/ with a name, starting URL, prompt, and a rubric used only for grading, not a new environment.

The template every task runs through (full version in the hosted environment):(https://github.com/hud-evals/liveweb-samples)

@env.template(id="web-research")
async def web_research(prompt: str, url: str, rubric_items: list[dict]):
    await load_browser_on_url(url)
    answer = yield prompt
    yield await grade_with_rubric(answer, rubric_items)

The environment opens the starting URL, gives the agent the prompt, then scores the answer against the rubric. To add a task, add those fields under 'tasks/' and run 'hud sync tasks <your-taskset> task.py' . You do not rebuild the browser environment unless the task needs a new archive.

Where models fail

We ran all four tasks across model tiers. Almost every AirNow run earned full marks, only one Chairs run got the count right, and Ladybird scores ran from 93% down to zero. On Costco, scores were consistent at 75% across models.

On the Ladybird task, Astra’s six attempts average 93.3%. Fable averages 56% over five completed attempts. Sonnet and Qwen sit at 0 on completed Ladybird runs; Qwen’s Ladybird comparison is also confounded, because that harness had shell and files but no computer tool, and several runs asked for a URL or image instead of counting. The traces show what separated them. Astra's counts landed on or right next to the true total. One of Fable's weaker runs skipped the spots low on the sides of the shell, which its better runs had counted. Sonnet kept rotating and zooming the model and still came up short, averaging 113 turns to Fable's 91. A turn is one step in the agent's loop, and since harnesses pack different amounts of work into a turn, turn counts only compare models on the same harness.

AirNow is mostly solved when the run finishes. Twenty of twenty-one completed AirNow attempts score 1.0 as recorded. HUD counts a task as hard when frontier models score 50% or less, so AirNow no longer qualifies. Where the models still differ is how long they take. Fable and Sonnet both earned full marks, but Sonnet took more than twice as many turns, 107 on average against Fable's 47. Astra’s 50% cell includes three provider capacity errors that recorded 0; on its three completed AirNow runs it scores 100%. That run never relied on the model's own vision. It installed three YOLO object detectors and had them count the chairs, a legitimate approach that only worked because Qwen's harness had shell access. It ran for 120 turns, while Qwen's typical Chairs run ended around 14.

Chairs is almost all zeros under an exact-match grader that expects 7. One Qwen run scores 1.0 after installing object detectors.

Authenticated websites are an example where Browserbase helps production agents get past access issues. In this task, the agent needs to sign into an existing account by entering credentials without exposing the password in tool output, and validate that it's able to access the authenticated account page. HUD uses Browserbase’s cloud browser sessions, live-site navigation, screenshots and a secure way to enter credentials in these cases to validate agent performance on real websites.

Frontier labs target these failure points when they collect data. A task that causes models to fail at a specific step, is more valuable than one they simply pass or fail overall. This makes the full trajectory the most valuable component. Every detail above comes from traces. HUD's trace viewer plays back each attempt step by step, showing what the agent saw and what it did at each point. Here's Astra working through AirNow, from the EPA homepage to the four values.

Monetizing evals on Datavendor

Frontier labs need data to improve their models, so they buy private evals, environments, and tasksets that current models find difficult. A taskset that meets the standard above, with graded traces as proof, becomes a monetizable asset.

"Historically, data has been something where you're in the room. You're in San Francisco, you have these long-term relationships. But it's not just engineers in San Francisco who can make frontier-grade training data. There are experts around the world who are not in the room." - Parth Patel, co-founder of HUD, on the Standard Capital podcast

Use hud deploy to publish the environment and hud sync to publish the tasks, then list them on datavendor.ai.

What’s next

To learn the principles behind good task design, read What makes a good task.

Take the liveweb-samples repo, sync it into your taskset on HUD, and run it directly from the platform. Or eval from the CLI against a public taskset:

hud eval liveweb-samples claude --runtime hud --all --max-steps 150 -y

For the stack around this blog:

• HUD: Docs, Task and tasksets, Creating and environment Evaluating Agents, Designing tasks
• Browserbase: Docs , Agent identity, Verified