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.
| Run | What changed | Wall | Cost |
|---|---|---|---|
| Browser path, vanilla | AgentCore Browser + | ||
ChatBedrockConverse
subclass injecting 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.
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.
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:
| Vanilla | Cached | Ξ | |
|---|---|---|---|
| Sonnet input billed at full price | 874,862 | 535,327 | β339K |
| Sonnet cache reads (10% price) | 0 | 306,176 | +306K served from cache |
| Sonnet cache writes (125% price) | 0 | 5,888 | +5.9K written |
| Sonnet cost | $3.32 | $2.34 | β$0.97 |
| Wall clock | 20:11 | 17:48 | β2:23 |
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.
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:
google.com/maps/search/Mexican+restaurants+near+525+Market+St+San+Francisco
[role="article"]
)data=!4m2!4m1!3e2
= walking mode), extract duration with a regex scanResult: $0.03. Same output. Same AgentCore Browser infrastructure. The difference is what's driving it.
| browser-use (LLM loop) | Playwright (code loop) | |
|---|---|---|
| LLM calls in browser | ~60 | 0 |
| Cost | $3.41 | $0.03 |
| Wall time | 20:11 | 1:09 |
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.
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.
Four findings, ranked by impact:
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.
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.
If you're shipping on a frontier model, stop optimizing the model first. Optimize the harness.
Work through these in order of impact:
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.