I Had a Working Agent at $3.41 a Run. Here's Where the Money Was Actually Going.

TL;DR

• Same task, same infrastructure, different harness: cost went from $3.41 to $0.03. Zero model changes.
• Prompt caching on the inner browser loop (~120 lines of wrapper code): −29% cost. The 8K of repeated system prompt + tools was being billed at full price 59× per run.
• Convergence rules in the prompt (three sentences): −54% cost on the desktop path, −75% wall time. The default behavior across Opus 4.8 and 4.6 is to keep searching. “After N items, STOP” is the most underrated sentence in production agent prompting.
• Eliminating the LLM from the browser loop entirely (Playwright instead of browser-use): −99% cost on the browser path. The first two are optimizations within the loop. This one removes the loop.

The previous post argued for the hierarchy: when an agent needs to interact with a UI, pick the cheapest tier that can do the job. Native API first, then connectors, then browser automation, then computer use. The core finding was that implementation choice — not model choice — drives most of the cost.

This post is what happens once you’ve picked your tier. You’re at tier 3 (browser) or tier 4 (computer use) because nothing above it covers your workflow. Now the question is: what does the cheap version of that tier actually look like, versus the demo version that ships out of the box?

I had a working agent — part of the fleet I run for my own daily operations. It found nearby lunch options, validated walking distances, and saved a markdown file. Twenty-three minutes per run. $3.41 per run on Bedrock. Not a bad number for a proof of concept. A bad number if you’re running this at any scale: a thousand lookups a month per tenant is $40,800 a year. Same outcome.

The question I sat down with wasn’t “is there a cheaper model?” I was using a frontier model deliberately. The question was: where is that $3.41 actually going, and what changes without touching a single line of model API code?

The optimization went further than I expected. The first two changes got cost down to $1.17. A third got it to $0.03. This post is the breakdown.

The runs

The first four runs used Opus 4.8 as the inner model. The Playwright run used Sonnet 4.6 — the point isn’t the model, it’s that the model is barely involved. One Haiku call at the end to format results.

Where vanilla browser-use spends $3.41

The browser-use library runs a screenshot-decide-click loop inside one tool call from the outer agent. On the Yelp task, that inner loop made 59 model invocations before returning. CloudWatch’s InputTokenCount for the Sonnet 4.5 inner sub-agent: 874,862 tokens in one run.

Per-call input shape:

┌──────────────────────────────────────────────────────────┐
│  Per-call input ≈ 14,800 tokens                          │
│                                                          │
│  ┌────────────────────────────────────────────┐          │
│  │ System prompt (browser-use thinking rules) │ ~5,000   │
│  ├────────────────────────────────────────────┤          │
│  │ Tool definitions (click/type/scroll/...)   │ ~3,000   │
│  ├────────────────────────────────────────────┤  IDENTICAL
│  │                                            │   every  │
│  │  ↑ 8,000 tokens repeat verbatim every turn │   turn   │
│  │                                            │          │
│  ├────────────────────────────────────────────┤          │
│  │ Conversation history (recent screenshots) │ ~5,000   │
│  ├────────────────────────────────────────────┤  varies  │
│  │ Current screenshot                         │ ~1,800   │
│  └────────────────────────────────────────────┘          │
│                                                          │
│  × 59 calls = 874K tokens billed at full price           │
└──────────────────────────────────────────────────────────┘

That ~8K of system+tools is paid at full input price 59 times. More than half the run cost is reprocessing the same instructions. Caching them is the obvious move.

Cache that, save 29%

Bedrock supports prompt caching via cachePoint markers — drop a marker in the request body, and from call 2 onward, content before the marker is served from cache at 10% of the input price. First call writes the cache at 1.25× normal price. Break-even: 2 calls. We were at 60.

browser-use 0.3.x exposes no cache_control configuration. The library sends raw messages to whatever LLM wrapper you give it. So I subclassed the wrapper instead of forking the library:

class CachedChatBedrockConverse(ChatBedrockConverse):
    def _generate(self, messages, ...):
        bedrock_messages, system = _messages_to_bedrock(messages)
        system.append({"cachePoint": {"type": "default"}})  # mark system cacheable
        params = self._converse_params(...)
        if "toolConfig" in params:
            params["toolConfig"]["tools"].append({"cachePoint": {"type": "default"}})
        return self.client.converse(messages=bedrock_messages, system=system, **params)

That’s it. About 120 lines once you handle the streaming path and a couple of edge cases. browser-use never knows.

The numbers from the next run:

Faster and cheaper. The cache write penalty (5.9K × 1.25× = trivial) is dwarfed by 306K cache reads at 10% price. The cached prompt also processes faster on Bedrock’s side, which is where the wall-clock improvement came from.

This is the kind of optimization that compounds. At a thousand lookups per month per tenant, the difference between cached and uncached is $11,600 per tenant per year. Paid once in 120 lines of Python.

I wrote about prompt caching last March. The general principle is well-known. What’s interesting is how rarely it’s applied inside agent harnesses — browser-use, Strands’ built-in browser tooling, and most reference implementations send identical prompts on every turn and let the bill add up.

The deeper fix: remove the LLM from the loop

Caching saved 29% by making the 59 model calls cheaper. But the question underneath is: why are there 59 model calls?

browser-use runs a screenshot-decide-click loop. Every action — navigate to a URL, click a button, read a result — goes through a model invocation. The LLM is not just reasoning about the task; it’s deciding every mechanical step. Most of those 59 calls aren’t doing strategic work. They’re doing work that code could do deterministically.

For tasks with a stable DOM structure — which describes most of the web — you can replace the entire browser-use loop with a Playwright script: navigate by URL, wait for a selector, extract structured data from DOM elements. Zero LLM calls in the browser loop. One LLM call at the end to rank and format.

The same lunch-finding task, reimplemented this way:

1. Navigate to google.com/maps/search/Mexican+restaurants+near+525+Market+St+San+Francisco
2. Wait for result cards to render ([role="article"])
3. Extract name, rating, review count from DOM selectors — no model, no screenshots
4. For each candidate, navigate to a walking directions URL (data=!4m2!4m1!3e2 = walking mode), extract duration with a regex scan
5. Pass the structured JSON to one Haiku call: “pick the best 3, format as markdown”

Result: $0.03. Same output. Same AgentCore Browser infrastructure. The difference is what’s driving it.

The 99% cost reduction isn’t from caching or prompting. It’s from not calling the model 59 times in the first place.

The tradeoff: Playwright scripts are task-specific. browser-use is general — give it any instruction and it figures out the clicks. If the site changes its DOM, the Playwright script breaks; browser-use adapts. For tasks you run at high volume on predictable sites, Playwright is the right answer. For tasks that require navigating novel UIs or handling sites with anti-bot measures, browser-use (or a vision loop) is still necessary.

Prompt engineering moved the dial more than caching

The desktop path tells a different story. Same Opus 4.8 on the same Bedrock endpoint, but now the model does both the strategic reasoning and the per-pixel clicking — no inner sub-agent. First run, with a base prompt that asked for “3 strong lunch options that meet ALL of these criteria,” the agent kept finding candidates indefinitely. Found 4. Found 5. Found 6. Hit the 20-minute harness timeout without ever writing the file. $2.13 spent. Zero output.

Then I added three sentences to the prompt:

“As soon as you have 3 candidates that meet the criteria, STOP SEARCHING. Do not look for better candidates. Three is the target, not the floor. If you cannot find 3 that meet ALL criteria, lower the bar (include 3.9-star options) and note this in the output.”

Same model. Same container. Same task. Five minutes and eleven seconds. $1.17. File saved. The agent quoted my rule back in the output: “bar lowered to 3.9 per convergence rules.”

That’s a 54% cost reduction from words. More than caching gave me. The default behavior across Opus 4.8 and Opus 4.6 is to keep gathering. “After N items, STOP” is the most underrated sentence in production agent prompting. Most builders write the search criteria carefully and forget the stopping criteria entirely.

The pattern works for anything the agent might over-explore: research depth, candidate pools, file searches, retry attempts. A budget the agent knows about converges faster than no budget.

The pattern

Four findings, ranked by impact:

1. Eliminate the LLM from the browser loop (Playwright): −99% cost. Only viable when the DOM is stable and the task is predictable. Not always possible, but when it is, nothing else comes close.
2. Convergence rules in the prompt: −54% cost, −75% wall time. Three sentences. Costs nothing. Applies to any agent that searches or gathers — not just browser agents.
3. Prompt caching on the inner loop: −29% cost, −12% wall time. 120 lines of subclass code. One-time investment. Applies whenever the same context repeats across many model calls.
4. Tier choice (browser vs desktop): Not a harness optimization, but worth noting — picking the wrong tier and then optimizing it is still losing.

The rankings matter. Most teams apply caching first because it’s well-documented and mechanical. Convergence rules are higher leverage and cost nothing. And neither is as impactful as asking whether the model needs to be in the loop at all.

The thing I’m still unsure about

None of the optimizations above (caching, convergence rules, sensible retries) ship as defaults in the major reference implementations.

The fixes themselves are small. What’s missing is a shared convention — a set of “production agent defaults” that frameworks could adopt so builders don’t have to rediscover them the expensive way every time.

I don’t know who is best positioned to define and ship that convention. The first credible party to do so will capture significant mindshare.

So what

If you’re shipping on a frontier model, stop optimizing the model first. Optimize the harness.

Work through these in order of impact:

1. Ask whether the model needs to be in the loop at all. For browser tasks with stable DOM structure, a Playwright script + one formatting call is $0.03. A generic LLM browser agent is $3.41. The gap is structural.
2. Add convergence rules. Three sentences. The default behavior for current frontier models is to keep gathering. Budget the agent explicitly and it stops.
3. Cache repeated context. 120 lines of wrapper code delivers 29% on inner loops. Low effort, reliable return.

The harness is where the margin lives — and the harness includes the question of whether you need a model-per-action loop or just a model-at-the-end. Most teams don’t ask that question until the bill arrives.

The next post looks at what happens when even a well-tuned single tier isn’t enough — and you have to orchestrate across tiers (the hybrid recovery behavior that only appeared in that setup).

Part 2 of the Agent Tooling series. ← Part 1: Cost-justified hierarchy · Part 3: Router or agent? →