A browser agent's cheapest Google Maps run was the one where it wrote a selector

The cost of a growing context is the part of this test that generalises past Google Maps. The author split run 4's calls into thirds and summed the context read in each: 1.15M tokens, then 1.64M, then 2.88M, so the last third cost about 2.5 times the first, because every new call re-reads a context that keeps growing ^[13]. Those thirds sum to 5.67M tokens across 30 places, or 189k per place, which is the figure reported for that run ^[1][10].

Before any page loads, the agent's context already sits at about 31k tokens from the system prompt, tool definitions and instructions ^[8].

Run 4 was the cheapest of the four per record, at about 23 seconds, 189k processed tokens and 27k weighted per place, against 29 seconds, 293k and 49k in run 1 ^[10][9]. Processed tokens per place fell about 35 percent and the weighted proxy about 45 percent ^[2]. In that run the agent stopped calling its general find and get-page-text tools on each place page and instead ran one JavaScript call per page that pulled the values straight out of aria-label attributes, and the author credits that single change for most of the drop ^[11].

Review count is the field that separated the two, and the cause was a wait condition. The script came from a separate Sonnet worker, written from a one-paragraph spec with one iteration to fix the reviews-count wait condition ^[14]. The count loads in an async widget, and the script's wait returned nothing on 28 of the 50 rows it fetched ^[16]. The agent read the search results feed as well as the place page, so it had a second source for the number ^[17]. A script could read the feed too; this one skipped it.

That wait condition also shows up in the timings. Seven of the 30 Chicago rows took the script 32-36 seconds each, and those were exactly the rows that came back with an empty review count; the rest ran in 2-7 seconds, apart from the one page whose h1 never became visible inside the wait ^[18][16]. On those seven rows the script was slower than the agent's 23 seconds per place in the same batch ^[4]. Across the reported ranges, the agent's midpoint per record is about 2.9 times the script's ^[5].

Search and list discovery stayed with the agent; the script only re-fetched place pages whose URLs the agent had already found ^[15]. The author computed no dollar cost, and the weighted figure is an internal proxy that counts plain input at 1x, cache reads at 0.1x, cache writes at 2x and output at 5x ^[7].

Repeatability was loose. Runs 1 and 2 covered the same 10 places back to back and differed by 19 percent in wall time and 59 percent in weighted tokens. Most of that came from the second run: it hit a results feed stuck at 6 loaded items and needed a page reload plus a scripted scroll to recover ^[12].

For these numbers to transfer, the target site has to keep its fields in attributes that one in-page JavaScript call can read, and the batch has to be short enough that the context curve stays close to flat. This is 60 records on a single site in one country, from four runs by one author, and an earlier Shibuya pass was excluded from the results ^[1][19].