ClawBenchBenchmark Entity
ClawBench Web Tasks Benchmark
ClawBench Web Tasks evaluate agents on realistic browser workflows: reading pages, navigating interfaces, using tools, and completing multi-step goals with traceable evidence.
What It Measures
The benchmark tests whether agents can handle real web task state, follow instructions across pages, and recover from UI friction. It is designed for agents that operate through browsers or web automation tools, where the task is not only to produce an answer but to perform the workflow in the target interface. That can include reading page content, navigating through stateful UI, submitting forms, using authenticated tools, and confirming that the requested outcome happened.
Web task benchmarks are important because browser agents fail in different ways from coding agents. They can lose page context, click the wrong control, hallucinate information that is not visible, skip validation, or complete a workflow in a way that cannot be audited. A useful benchmark therefore needs both scoring and evidence: what the agent saw, what it clicked or called, and what final state it produced.
| Signal | Why it matters | ClawBench evidence |
|---|---|---|
| Task grounding | The agent should act on the actual page state, not a guessed version of the workflow. | Visited URLs, observations, screenshots or trace events, and submitted result. |
| Tool and API usage | Production web agents often combine browser actions with API calls and local tools. | Tool-call timeline, request evidence, and trace annotations. |
| Outcome verification | The run should verify the requested state before claiming success. | Final page state, scoring result, and replayable task trace. |
How ClawBench Uses It
Each run is connected to task evidence and public scoring. The traces show whether the agent used real API calls, visited the expected pages, completed the requested workflow, and failed for model or infrastructure reasons. This keeps the benchmark useful for production teams, because a single pass or fail score is not enough to decide whether an agent can safely operate a web application.
ClawBench uses the trace to preserve the run context: selected task, browser or tool actions, API calls, timing, final output, and scoring state. That evidence supports both leaderboard comparison and failure analysis. When a run fails, reviewers can check whether the model misunderstood instructions, the browser automation broke, the target page changed, or infrastructure limits interrupted the workflow.
Methodology Signals To Review
First, confirm that the web task is real and that the agent interacted with the intended target rather than a mocked page. Then inspect whether the agent used observations from the page before taking actions. Strong web agents slow down enough to read the interface, handle redirects or errors, and verify the final state. Weak web agents often click by label guesswork, miss hidden state, or report success after only partial progress.
For production validation, also check API and tool evidence. If the task requires a real API call, the trace should show the call rather than a simulated answer. If the task requires browser work, the trace should show the navigation path and relevant state changes. This is how ClawBench separates authentic task completion from plausible-looking summaries.
How To Interpret Results
A strong Web Tasks result shows that the agent can act in a dynamic interface while preserving auditability. The best runs include clear page observations, targeted actions, real tool calls where required, and an explicit check that the requested outcome exists. For teams building customer support, research, operations, or data-entry agents, this behavior matters more than a short demo because production web workflows are stateful and easy to fake.
Use the leaderboard for broad comparison, then open traces to review task-by-task behavior. When failures cluster around page navigation, improve browser-control skills. When they cluster around missing API calls, improve tool policy. When they cluster around infrastructure limits, fix the run environment before judging the model.