Article
Authors
Browser agents are usually evaluated by task success, reward, or human preference, yet the same trajectories also determine the serving load imposed on a language-model system. This paper studies browser shopping work as a capacity-planning problem. Each WebShop trajectory is transformed into a workload unit with instruction tokens, observation-token proxies, action counts, page types, candidate action counts, reward, and derived latency-risk indicators. The study uses 1,643 WebShop human trajectories, a 1,000-product WebShop catalog subset, 12,251 crowd instructions, and a deterministic MiniWoB++ validation sample of 1,467 demonstrations across 60 task directories. KMeans clustering over post-hoc trajectory features yields four operational personas: Direct buyers, Option comparators, Catalog scanners, and Recovery browsers. Direct buyers make up 73.5% of trajectories and require 637 prompt-token units on average, while the rare Catalog scanner persona uses 9,499 prompt-token units and 73 actions on average. Planning-time token prediction remains difficult when only instruction and product fields are available: Ridge regression achieves a held-out RMSE of 1,328.7 token units, only slightly ahead of the mean baseline, while logistic high-cost detection reaches AUC 0.688 and F1 0.503. A queue-based capacity simulation shows that under the observed persona mix, a four-worker service lane remains stable through 50 tasks per minute but crosses 38.1% wait-over-two-second risk at 60 tasks per minute. The findings show that browser-agent workloads have heavy-tailed serving costs, and that lightweight persona metadata can expose capacity pressure that is invisible in task-success metrics alone.
browser agents, WebShop, MiniWoB++, workload clustering, token-aware capacity planning