Show HN: Smooth CLI – Token-efficient browser for AI agents (docs.smooth.sh)
Here’s a demo: https://www.youtube.com/watch?v=62jthcU705k Docs start at https://docs.smooth.sh.
Agents like Claude Code, etc are amazing but mostly restrained to the CLI, while a ton of valuable work needs a browser. This is a fundamental limitation to what these agents can do.
So far, attempts to add browsers to these agents (Claude’s built-in --chrome, Playwright MCP, agent-browser, etc.) all have interfaces that are unnatural for browsing. They expose hundreds of tools - e.g. click, type, select, etc - and the action space is too complex. (For an example, see the low-level details listed at https://github.com/vercel-labs/agent-browser). Also, they don’t handle the billion edge cases of the internet like iframes nested in iframes nested in shadow-doms and so on. The internet is super messy! Tools that rely on the accessibility tree, in particular, unfortunately do not work for a lot of websites.
We believe that these tools are at the wrong level of abstraction: they make the agent focus on UI details instead of the task to be accomplished.
Using a giant general-purpose model like Opus to click on buttons and fill out forms ends up being slow and expensive. The context window gets bogged down with details like clicks and keystrokes, and the model has to figure out how to do browser navigation each time. A smaller model in a system specifically designed for browsing can actually do this much better and at a fraction of the cost and latency.
Security matters too - probably more than people realize. When you run an agent on the web, you should treat it like an untrusted actor. It should access the web using a sandboxed machine and have minimal permissions by default. Virtual browsers are the perfect environment for that. There’s a good write up by Paul Kinlan that explains this very well (see https://aifoc.us/the-browser-is-the-sandbox and https://news.ycombinator.com/item?id=46762150). Browsers were built to interact with untrusted software safely. They’re an isolation boundary that already works.
Smooth CLI is a browser designed for agents based on what they’re good at. We expose a higher-level interface to let the agent think in terms of goals and tasks, not low-level details.
For example, instead of this:
click(x=342, y=128)
type("search query")
click(x=401, y=130)
scroll(down=500)
click(x=220, y=340)
...50 more steps
Search for flights from NYC to LA and find the cheapest option
Smooth enables agents to launch as many browsers and tasks as they want, autonomously, and on-demand. If the agent is carrying out work on someone’s behalf, the agent’s browser presents itself to the web as a device on the user’s network. The need f...
26 comments
[ 3.1 ms ] story [ 40.7 ms ] threadHow does it compare to Agent Browser by Vercel?
The amount of manual QA I am currently subjected to is simultaneously infuriating and hilarious. The foundation models are up to the task but we need new abstractions and layers to correctly fix it. This will all go the way of the dodo in 12 months but it'll be useful in the meantime.
agent-browser helped a lot over playwright but doesn't completely close the gap.
the right abstraction for QA is probably closer to what a manual tester actually does, describe expected behavior, let a specialized system figure out the mechanical verification steps.
but the harder unsolved problem is evaluation: how do you reliably distinguish "the agent verified the behavior" from "the agent navigated to the right page and hallucinated a success report"? visual diffing against golden screenshots helps for regression but doesn't cover semantic correctness of dynamic content.
I _would_ be curious to try it, but...
My first question was whether I could use this for sensitive tasks, given that it's not running on our machines. And after poking around for a while, I didn't find a single mention of security anywhere (as far as I could tell!)
The only thing that I did find was zero data retention, which is mentioned as being 'on request' and only on the Enterprise plan.
I totally understand that you guys need to train and advance your model, but with suggested features like scraping behind login walls, it's a little hard to take seriously with neither of those two things anywhere on the site, so anything you could do to lift up those concerns would be amazing.
Again, you seem to have done some really cool stuff, so I'd love for it to be possible to use!
Update: The homepage says this in a feature box, which is... almost worst than saying nothing, because it doesn't mean anything? -> "Enterprise-grade security; End-to-end encryption, enterprise-grade standards, and zero-trust access controls keep your data protected in transit and at rest."
forms, PRG, semantic HTML and no js needed
I get the sandboxing, etc, but a Docker container would achieve the same goals.
The product sounds interesting but I am not gonna run this is in the cloud for my use cases.
https://n694923.alteg.io/company/656492/personal/menu?o=
Seems like an interesting new category.
curious about failure recovery though: when the specialised browsing model misinterprets an intent (e.g. clicks the wrong "Submit" on a page with multiple forms), does the outer agent get enough signal to retry or reframe the instruction? that's been the hardest part in my experience, the error surface between "the browser did the wrong thing" and "I specified the wrong thing" is really blurry.
Can you confirm that you only route the traffic of the one user who owns the machine though the proxy? Or do you use it as residential proxy for other users as well?
The docs don't say anything about it.
Curious to see how you compare against competitors, any benchmarks to share?
We launched a competitor in the space rtrvr.ai, that when benchmarked is SOTA and beats even OpenAI Operator.
Cool work on the proxying but LinkedIn has really advanced detections for even device/hardware fingerprinting, how advanced are your stealth measures? Because this might be risking account bans.
People in this space even setup consumer hardware in datacenters to get around this actually.