Pricing a browser agent

A browser-use agent drives a real browser from a model loop: the page goes in as a screenshot or as text, and navigation, clicks and typing come back. Its selling argument is that it needs no integration, which makes it look inevitable wherever a system has no API. That argument is about capability, and the decision is about cost, so the two have to be brought onto the same footing: what outcome is being bought, what else would deliver that outcome, and what each option costs to build, to run, to maintain and to be wrong.

The comparison here is a small, ordinary request — weekly invoice data out of three supplier portals — with the exposure priced the same way. The pricing part is arithmetic anybody can redo. The part that gets skipped is measuring the outcome honestly, because the version of a task that reaches a product channel is usually the version that made the request compelling rather than the version somebody actually performs.

A browser-use agent looks like the obvious answer to a request of this shape, because the portals cannot be integrated with and an agent can use anything a person can use. Both halves of that sentence are true and neither of them is a cost. What makes a comparison possible at all is separating the outcome from the instrument, and the outcome here can be written in one line: last week's invoice rows, in finance's hands, on a Monday. Every option below is judged against that line, and the agent is one of four.

Four ways to get the same twenty-two minutes back#

Before any of the columns, the quantity they are all measured against has to be built, and it is the one arithmetic step the rest of the chapter rests on. The task is three logins, three downloads and one find-and-replace, and it takes twenty-two minutes. Annualising is the right operation because every other option in the table is priced by the year: fifty-two occurrences at twenty-two minutes each is a little over nineteen hours. That is the whole prize, and it is now in the units the other columns are already in. Multiplying it by a fully loaded hourly rate — the cost of an hour of somebody's time including everything the salary line does not show — converts it once more, into a figure that can be set beside engineering days. Without that second conversion a build cost and a person's time cannot be compared at all, which is why proposals that skip it end up arguing about whether saving somebody's afternoon is worth a sprint.

Two of those columns are worth expanding, because they are the ones people skip.

Asking the supplier is the option that gets dismissed in the first meeting and works surprisingly often, because portals are usually a UI over a system that already exports. Two of the three suppliers here had a scheduled CSV email available on request; one of them had an SFTP drop it offered to enterprise customers and had simply never mentioned. That is the whole integration for two thirds of the problem, at the cost of two emails and a procurement conversation, and it removes the credential holding entirely because the data arrives rather than being fetched. "No API" is a claim about a documentation page, and it is worth twenty minutes of verification before it becomes an architectural constraint.

The run cost for the agent is worth computing rather than hand-waving, because the number surprises people who have only priced text-only tool calls. A screenshot-driven loop sends an image on every step. A 1024×768 screenshot is on the order of 1,100–1,600 tokens, and a portal run — log in, navigate, filter by date, download, verify — takes 30 to 45 steps. Even with the conversation cached aggressively, a run of that shape lands in the range of 250,000 to 600,000 input tokens plus a few thousand output. At current mid-tier model pricing that is a pound or two per run, which is fine weekly and stops being fine when someone runs it hourly across forty suppliers. Alongside that sits the latency: four to seven minutes per portal against 400 milliseconds for a scraper doing the same fetch, a factor of roughly 600, which matters if anything downstream is waiting.

Two steps in that paragraph carry the weight and both are usually skipped. The first is the jump from the cost of a screenshot to the cost of a run, which is not a multiplication. A thousand-odd tokens an image across thirty to forty-five steps comes to a few tens of thousands of tokens, and the range quoted above is close to ten times that. The missing factor is that a model call carries no memory of the last one: each step sends the whole conversation so far, not only the newest picture, so what gets multiplied by the step count is the size of a request rather than the size of an image, and requests grow as the run proceeds. Pricing a screenshot loop by multiplying image cost by step count is the commonest error in these estimates, and it undercounts by close to an order of magnitude. Caching changes what those tokens cost rather than how many of them there are, which is why the sentence above says cached aggressively and still quotes a quarter of a million.

The second step is the latency comparison, which is a division worth performing rather than accepting. Four minutes is two hundred and forty seconds. Four hundred milliseconds is two fifths of a second. The quotient is six hundred. Notice which end of each range that used: at seven minutes against the same fetch the factor is larger still, so the figure quoted is the favourable end of the comparison for the agent, and the honest way to carry it into a document is as a floor rather than as an estimate.

The estimate is easy to keep honest by measuring it directly rather than trusting the arithmetic, since the API reports the counts:

import base64, anthropic

client = anthropic.Anthropic()
resp = client.beta.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    betas=["computer-use-2025-01-24"],
    tools=[{
        "type": "computer_20250124",
        "name": "computer",
        "display_width_px": 1024,
        "display_height_px": 768,
        "display_number": 1,
    }],
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "Open the invoices page and filter to last week."},
            {"type": "image", "source": {
                "type": "base64", "media_type": "image/png",
                "data": base64.b64encode(open("step_01.png", "rb").read()).decode(),
            }},
        ],
    }],
)
u = resp.usage
print(u.input_tokens, u.cache_read_input_tokens, u.output_tokens)
# one step of a 38-step run; multiply, then price at your provider's rates

Log those three numbers per step for one real run and the per-run cost stops being an argument. Teams that do this often discover the screenshot resolution is the largest single lever, because a 1280×800 capture costs about 1.6× a 1024×768 one for identical task success on most portals.

Resolution is a lever at all because an image is charged by area rather than by width. A capture that is wider is also taller, so a change that sounds like one step up is a change in two dimensions at once, and anybody comparing capture sizes the way monitors are sold — by the diagonal — will underestimate what it costs. The ratio between your own two candidate sizes is not something to reason about in a meeting: the call above reports the input token count, so capture the same page at both and read the two numbers off. What makes the lever worth pulling is where it sits in the arithmetic. Resolution multiplies a per-request cost that is itself multiplied by a step count set by the portal, so it is the one factor in the product that a team actually controls.

What the agent reaches when a page turns hostile#

Cost is half the comparison; the other half is the exposure, priced the same way. The scraper and the agent both hold portal credentials, so on that dimension they are equal. They diverge on what happens when the page misbehaves, because the scraper does not read the page as instructions — a supplier portal that starts serving text saying "your session has expired, please re-authenticate at this address" is a parse failure to Playwright, the browser-automation library that drives a real browser from a script, and a plausible next step to a model. And the agent's reach is not limited to the portal, since a computer-use loop that can navigate can navigate anywhere the machine can reach, which is the authority enumeration of the previous chapter applied to a design that does not exist yet.

This is where the full request gets larger than the one that was pitched. It is not "read three portals"; it is log in, download, transform, and upload the result into the ERP — the enterprise resource planning system that holds the company's purchase orders and payables ledger — unattended, nightly. Written out as one sentence, the design contains three properties that are each defensible alone and are dangerous together: it runs with nobody watching, it holds write access into a system of record, and nothing checks that what it wrote is right. Any one of those removed makes the others survivable. Attended operation means a human sees the wrong thing before it lands. Read-only access means a mistake is a bad report rather than bad ledger entries. Verification means a wrong write is caught the same night.

Check that the three close, because a design argument turns on whether all of them are genuinely required rather than on how many were listed. Remove the first property and put a human in the chair: a wrong write is seen before it lands, and the missing verification costs a delay instead of a ledger. Remove the second and make the ERP account read-only: a wrong result is a bad report, and nobody being awake and nothing being reconciled barely changes that. Remove the third and reconcile every write against the portal's own totals: a wrong write is caught the same night whoever was watching and whatever the account could reach. Each removal on its own takes the consequence down, which is what makes the combination the thing to name in a review, and no single one of them the thing to argue about. It also says where to spend first. Verification is the cheapest of the three to add after the fact, because the other two are negotiations with other teams — one about staffing a night shift, the other about a service account somebody already has and does not want to split.

The version of this design that sounds responsible — a service account on the portal, a service account on the ERP, a container, a nightly cron — leaves the two decisions that matter unmade. The first is the ERP account's scope, which in most organisations becomes whatever the integration team already had, because creating a new role in NetSuite or SAP is a two-week ticket and reusing the existing integration user takes ten minutes. That account typically has write access across far more than accounts payable. The second is what happens at 3 a.m. when the agent does something wrong, which is a question about verification and ownership rather than about isolation, and a container answers neither.

The belief worth naming is the one that makes a proposal feel costed when it is not. "We have priced it" is the defence, and the test is whether the price moves when the thing being bought moves. The figure attached to this request was four hours a week, and it would have been four hours a week whether the portal work took forty minutes or four, because it was somebody's estimate of a job rather than anyone's measurement of a task. A number that stays put across the whole range of what it is meant to measure is not a cheap measurement of that quantity; it is a different quantity that happens to be denominated in hours. The thing that moves it is a morning spent watching somebody do the work, and a morning is cheaper than every option in the table.

The costs the estimate leaves out#

Two line items are missing from the table because they are missing from almost every proposal of this kind, and both are borne by someone other than the team that builds it.

The first is the portal's opinion. Supplier portals sit behind the same bot-management products as everything else, and an automated browser that logs in nightly at the same minute, moves the pointer in straight lines, and never fails a form is distinguishable from a person by any of them. The outcomes range from an interstitial challenge that stops the run, through rate limiting that makes it intermittent, to the account being suspended, which is the expensive one because it also stops a human logging in manually while it is being sorted out. Most enterprise supplier agreements also contain a clause about automated access, and the fact that a browser agent is indistinguishable from a person is precisely what makes the clause apply. The honest version of the proposal names this and either gets written permission from the supplier or accepts a maintenance stream of unblocking work; the version that does not name it discovers the clause during the suspension.

The second is what happens to the twenty-two minutes when the agent goes wrong. The saving is real only when the run is trusted, and a run that has to be spot-checked costs more of a person's time than doing it themselves, since checking 412 rows against a portal is slower than downloading them. So the automation only pays if verification is automated as well, which adds engineering days that belong in the build column. A proposal that books the full twenty-two minutes as saved while leaving verification to a human has counted the same time twice.

Both of these point at a decision rule that is more useful than a scoring matrix. Pay the flexibility premium where the environment actually varies. If the task will look the same in six months, that premium is buying nothing, and something deterministic — a feed, a scraper, a person — will be cheaper on every dimension including the ones that do not appear in a spreadsheet.

Where the agent is the right instrument#

Reading this as a case against browser agents would be the wrong lesson, because there is a shape of problem where the alternatives are genuinely worse and the arithmetic reverses.

The long tail is the clearest one. Three portals used weekly is a job for three scrapers. Forty portals, each used twice a year, is 100 engineering days of scrapers that will have rotted between uses, against one agent that adapts to whatever the page looks like on the day. The agent's cost per run is high and its cost per portal is near zero, which is the opposite of the scraper's economics, and that crossover is the thing to look for when deciding. One-off and exploratory work has the same property: a migration that requires pulling six years of records out of a system being decommissioned next month does not justify a durable integration, and an agent doing it once under supervision has none of the unattended-write exposure, because a human is watching and the task ends.

The crossover itself is worth writing down as two shapes rather than remembered as a threshold. A scraper's cost is paid once per portal at build time and again per portal per year in maintenance, and it hardly notices how often it runs; four hundred milliseconds a fetch is four hundred milliseconds a fetch whether that is weekly or hourly. An agent's cost is paid per run and hardly notices how many portals there are, because the same loop reads whatever page it is pointed at. One curve is flat in runs and steep in portals; the other is flat in portals and steep in runs; they cross. Three portals read every week sits a long way on the scraper's side, because the run count is high and the portal count is low. Forty portals read twice a year sits as far on the other, because the portal count is high and the run count per portal is two. What to carry away is not a number but a question: which axis is your problem long on.

The hybrid worth naming explicitly puts the agent at authoring time and deterministic code at run time. The agent explores the portal, works out the selectors and the flow, and emits a Playwright script; an engineer reviews the script; the script runs nightly with no model in the loop. When the layout changes and the script fails closed, the agent is invoked again to repair it, and the repair goes through review before it ships. That arrangement pays the agent's flexibility cost once per layout change rather than once per run, keeps the injection surface out of the nightly path, and produces an artefact somebody can read. It costs more engineering than pointing an agent at the portal every night, which is the reason it does not get proposed by default.

Costing a capability means costing the outcome, and the outcome is usually smaller than the request. Twenty-two minutes a week is what three supplier portals were worth; the other three and a half hours were judgement work that no option on the table addressed. Against that outcome a feed costs two emails, a scraper costs two and a half days per portal and 400 milliseconds per fetch, and an agent costs six engineering days, a pound or two and four to seven minutes every time it runs, plus a page of untrusted content read as instructions on every single one of those runs.

Deciding to build it is where this chapter stops, and it leaves the harder half of the operational problem open. Suppose the design goes ahead with a scoped ERP account and a container, and it works — the finance team stops thinking about it, the nightly job posts a green tick in a Slack channel for four months. The failure that arrives after that is not a crash, which is why none of the machinery teams usually build for reliability will notice it.