// HACKER NEWS — CYBERSECURITY
The bitter lesson of browser agents
As models get better, the browser harness has to change. A lot.
When we launched Browser Use in November 2024, GPT-4o wasn't trained for computer use. Built on next-token prediction, it didn't reliably understand what it could do on a page. We had to spell it out.
As models got better at coding, we moved from predefined state and actions to code: first the model wrote its actions, then its observations. Now it does both through raw CDP, inside an existing agent harness.
We defined the state: here's what's on the page, here's what's clickable. Then the action space: click, type, scroll. Every interaction had to fit those rules.
The model picked an action, we ran it and sent back the next state. But browser automation is a game of edge cases. Every exception needed another fix.
Models were getting much better at coding. We experimented with JavaScript execution in September 2025 and persistent notebooks in October. The model could write a program instead of picking actions.
Drawing a signature or looping through comments no longer needed a new action. Variables persisted, so the model could inspect results and keep going.
Hermes agent replaced 12 browser tools with browser_exec, powered by our Browser Use CLI. Mean token use fell 60% for Opus 4.8 and 66% for Kimi K3. Both versions solved 18/18 runs per model (six tasks, three runs).
We'd opened up the actions, but we still decided what the model could see. That became the next problem.
A cookie button can be right there on the screen and missing from the state we send. Maybe the accessibility tree doesn't expose it, or our processing drops it. Either way, the model never sees the button.