2/5/2026 at 4:13:33 PM
by antves
2/7/2026 at 7:47:26 AM
Few days ago I built something like this for a personal project because it’s just the obvious thing to do - abstract away the gory details of using a browser. I found it was surprisingly easy to build and I soon had a browser agent that worked as you describe Smooth. Just surprised that the other browser agent frameworks like Browser Use and claude —chrome haven’t caught up to this yet, it’s so obvious and easy to do.by znnajdla
2/6/2026 at 2:42:07 PM
This looks really interesting!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."
by tekacs
2/6/2026 at 2:49:40 PM
Curious: what are people using as the best open source and locally hosted versions to have agents browse the web?by johnys
2/6/2026 at 3:53:34 PM
Playwright, same thing we use when doing non-ai automationFun fact, ai can use the same tools you do, we don't have to reinvent everything and slap a "built for ai" label on it
by verdverm
2/6/2026 at 4:09:25 PM
We love these tools but they were designed for testing, not for automation. They are too low-level to be used as they are by AI.For example, the playwright MCP is very unreliable and inefficient to use. To mention a few issues, it does not correctly pierce through the different frames and does not handle the variety of edge cases that exist on the web. This means that it can't click on the button it needs to click on. Also, because it lacks control over the context design, it cannot optimize for contextual operations and your LLM trace gets polluted with incredible amount of useless tokens. This increases cost, task complexity for the LLM, and latency
On top of that, these tools rely on the accessibility tree, which is just not a viable approach for a huge number of websites
by antves
2/6/2026 at 4:41:39 PM
again (see other comment), you are not listening to users and asking questions, you are telling them they are wrongYou describe problems I don't have. I'm happy with Playwright and other scraping tools. Certainly not frustrated enough to pay to send my data to a 3rd party
by verdverm
2/6/2026 at 5:16:00 PM
have you tried any other AI browser automation tools? we would be curious to hear about your use cases because the use cases we have been working on with our customers involve scenarios where traditional playwright automations are not viable, e.g. they operate on net new websites and net new tasks for each executionby antves
2/6/2026 at 5:35:51 PM
I'm unwilling to send my data to a 3rd party that is so new on the sceneConsider me a late adopter because I care about the security of my data. (and no, whatever you say about security will not change my mind, track record and broader industry penetration may)
Make it self-hostable, the conversation can change
by verdverm
2/6/2026 at 3:38:50 PM
Thanks for bringing this point up!We take security very seriously and one of the main advantages of using Smooth over running things on your personal device is that your agent gets a browser in a sandboxed machine with no credentials or permissions by default. This means that the agent will be able to see only what you allow it to see. We also have some degree of guard-railing which we will continue to mature over time. For example, you can control which URLs the agent is allowed to view and which are off limits.
Until we'll be able to run everything locally on device, there must be a level of trust in the organizations that control the technology stack, passing from the LLM all the way to the infrastructure providers. And this applies to every personal information you disclose at any touch point to any AI company.
I believe that this trust is something that we and every other company in the space will need to fundamentally continue to grow and mature with our community and our users.
by antves
2/6/2026 at 4:16:05 PM
I was actually very interested until I realized that this doesn't run on my computer…I get the sandboxing, etc, but a Docker container would achieve the same goals.
by jwr
2/7/2026 at 3:23:13 AM
Glad I saw this comment.The product sounds interesting but I am not gonna run this is in the cloud for my use cases.
by 6ak74rfy
2/6/2026 at 4:33:54 PM
There are pros and cons to running the browser on your own machineFor example, with remote browsers you get to give your swarm of agents unlimited and always-on browsers that they can use concurrently without being bottlenecked by your device resources
I think we tend to default to thinking in terms of one agent and one browser scenarios because we anthropomorphize them a lot, but really there is no ceiling to how parallel these workflows can become once you unlock autonomous behavior
by antves
2/6/2026 at 4:37:12 PM
I appreciate that, but for the audience here on HN, I’m fairly certain we understand the trade offs or potentially have more compute resources available to us than you might expect the general user to have.Offer up the locally hosted option and it’ll be more widely adopted by those who actually want to use it as opposed to tinker.
I know this may not fit into your “product vision”, however.
by garciasn
2/6/2026 at 5:22:09 PM
I agree it would be really cool to run this locally, it's definitely something on our radarsby antves
2/7/2026 at 6:56:46 AM
Yeah, give us the OSS.. and sell the SLA's to enterpriseby noeltock
2/7/2026 at 4:40:56 AM
the abstraction level argument is spot on. i've been working on browser automation for AI agents and the biggest lesson has been that exposing Playwright-level primitives to a foundation model is fundamentally the wrong interface. the model burns most of its context reasoning about DOM traversal and coordinate-based clicking instead of the actual task. the natural language intent layer is the right call, it's basically treating the browser interaction as a tool-use problem where the tool itself is agentic.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.
by tiny-automates
2/6/2026 at 5:36:34 PM
I'm working on building a personal assistant concept. One test I've been running is asking different AI assistants to use a browser to check available appointment slots for my hairstylist. None of them has managed to do it successfully yet, but I'm going to keep trying.by dandaka
2/7/2026 at 7:50:21 AM
I built a browser agent that can almost certainly handle that task. Will test and let you know by posting here later.by znnajdla
2/6/2026 at 10:20:25 PM
Cool project guys! Just gave it a spin. One thing I would have wished, was if the browsers would run locally. Since the smooth browser is running in prod, it makes it harder for Claude to test dev appsby stopachka
2/6/2026 at 10:26:01 PM
thanks! it can actually test apps running on your localhost with our tunneling feature (https://docs.smooth.sh/features/use-my-ip)you should be able to tell it to go to your localhost address and it should be able to navigate to your local app from the remote browser
let us know if you have any questions!
by antves
2/7/2026 at 7:51:33 AM
But does the tunnel expose the low level APIs required for Claude Code to write end to end tests and check browser console errors, etc ?by znnajdla
2/6/2026 at 11:00:31 PM
It still may not be quite ideal. For example, right now I was building a clone of Counter Strike. There's such large files that tunneling would be cumbersome.by stopachka
2/6/2026 at 11:34:07 PM
ah fair point! the tunnel is peer-to-peer so it doesn't add too much overhead, but you can't really beat localhost on latencyI'd be curious to try and see if practically the difference is so little that it doesn't matter
by antves
2/6/2026 at 10:54:08 PM
What is wrong with "claude --chrome"?by EMM_386
2/6/2026 at 11:25:56 PM
the Claude --chrome command has a few limitations:1. it exposes low-level tools which make your agent interact directly with the browser which is extremely slow, VERY expensive, and less effective as the agent ends up dealing with UI mechanics instead of thinking about the higher-level goal/intents
2. it makes Claude operate the browser via screenshots and coordinates-based interaction, which does not work for tasks like data extraction where it needs to be able to attend to the whole page - the agent needs to repeatedly scroll and read one little screenshot at the time and it often misses critical context outside of the viewport. It also makes the task more difficult as the model has to figure out both what to do and how to do it, which means that you need to use larger models to make this paradigm actually work
3. because it uses your local browser, it also means that it has full access to your authenticated accounts by default which might not be ideal in a world where prompt-injections are only getting started
if you actively use the --chrome command we'd love to hear your experience!
by antves
2/6/2026 at 10:59:52 PM
claude --chrome works, but as the OP mentions: they can do it 20x faster, by passing in higher-level commands.by stopachka
2/6/2026 at 3:31:49 PM
Way too expensive, I'll wait for a free/open source browser optimized to be used by agents.by tobyhinloopen
2/6/2026 at 3:48:08 PM
Our approach is actually very cost-effective compared to alternatives. Our browser uses a token-efficient LLM-friendly representation of the webpage that keeps context size low, while also allowing small and efficient models to handle the low-level navigation. This means agents like Claude can work at a higher abstraction level rather than burning tokens on every click and scroll, which would be far more expensiveby antves
2/6/2026 at 3:56:50 PM
If a potential user says it is too expensive, better to ask why than to tell them they are wrong. You likely have assumptions you have not validatedby verdverm
2/6/2026 at 4:22:24 PM
Definitely! Making Smooth as cost-effective as possible it's been a core goal for us, so we'd really love to hear your thoughts on thisWe'll continue to make Smooth more affordable and accessible as this is a core principle of our work (https://www.smooth.sh/images/comparison.gif)
by antves
2/6/2026 at 4:44:04 PM
are your evals / comparisons publicly/3rd party reproducible?If it's "trust me, I did a fair comparison", that's not going to fly today. There's too much lying in society, trusting people trying to sell you something to be telling the truth is not the default anymore, skepticism is
by verdverm
2/6/2026 at 4:56:19 PM
That's a great point, we'll publish everything on our docs as soon as possibleby antves
2/6/2026 at 5:26:48 PM
How does your approach differ from BrowserOS, not in the product sense(their product is ane enterprise browser based off chrome). but in how they designed the interface between the browser and the models?by itissid
2/6/2026 at 6:14:50 PM
This is a good idea. Do you use something like browser-use or Fara-7b behind the scenes? Or maybe you don't want to give up your secrets (which is fine if that's the case).by ilaksh
2/6/2026 at 6:26:00 PM
Thanks for asking! We developed our browser agent that uses a mix of custom and frontier models for different parts of the systemby antves
2/6/2026 at 8:46:48 PM
Is this essentially a cloud-managed specialized subagent with an LLM-friendly API?Seems like an interesting new category.
by oofbaroomf
2/6/2026 at 9:25:07 PM
yes that's right! I think this might be the way AI agents adoption plays out more broadlyAgents that start using subagents rather than humans using the subagents directly
by antves
2/6/2026 at 8:51:03 PM
The new SaaS is subagent as a service?by rahulyc
2/6/2026 at 9:28:47 PM
indeed! there is no reason why tooling for AI agents shouldn't use AI when tooling for humans is shifting towards AIby antves
2/6/2026 at 5:29:42 PM
I'm a bit curious. Why did you link the docs instead of the site in this post?by lasgawe
2/6/2026 at 5:39:22 PM
Our website does not dive as deep as the docs on the Smooth CLI yetby antves
2/6/2026 at 5:59:24 PM
Curious how this compares to https://sentienceapi.com/. My understanding is that Sentience uses deterministic "semantic snapshots" to try and give agents a more reliable browser interface.by sandgraham
2/6/2026 at 11:40:27 PM
Vercel also released a similar tool with a unique interface/dsl - https://github.com/vercel-labs/agent-browser> agent-browser click "#submit" > agent-browser fill "#email" "test@example.com" > agent-browser find role button click --name "Submit"
I appreciate that there’s innovation in the space, we will get closer to the interface that’s most appropriate for models to tool-call. I’m going to check your link out, sounds interesting.
by threecheese
2/6/2026 at 11:59:32 PM
it's interesting to see how things will play out, but I really believe that doing Claude Code (maybe with Opus 4.6) + click tool + move_mouse tool + snapshot page tool + another 114 more tools is definitely not the best approachthe main issue with this interface is that the commands are too low-level and that there is no way of controlling the context over time
once a snapshot is added to the context those tokens will take up very precious context window space, leading to context rot, higher cost, and higher latency
that's why agents need to use very large models for these kind of systems to work and, unfortunately, even then they're very slow, expensive, and less reliable than using a purpose-made system
I wonder if a standardized interface will organically emerge over time. At the moment SKILL.md + CLI seem to be the most broadly adopted interface - even more than MCP maybe
by antves
2/6/2026 at 5:31:46 PM
Interesting idea as an open source tool I could hack locally, but no way in hell am I adding yet another bill and using a web browser of all things as SaaS. I'll make my own web-specialized subagent.by quotemstr
2/6/2026 at 2:25:07 PM
Frontend QA is the final frontier, good luck, you are over the target.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.
by waynenilsen
2/7/2026 at 4:43:32 AM
frontend QA is exactly where i've seen the biggest ROI with browser agents. the gap with Playwright MCP specifically is that it assumes the agent can reason about CSS selectors and DOM state, which breaks constantly on anything with dynamic rendering, client-side routing, or shadow DOM.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.
by tiny-automates
2/6/2026 at 3:45:42 PM
It's amazing how agents like Claude Code become very much more autonomous when they have the ability to verify their work. That's part of the reason why they work much better for unit-testable work.I think this paradigm was very visible in yesterday's blog post from Anthropic (https://www.anthropic.com/engineering/building-c-compiler) when they mentioned that giving the agents the ability to verify against GCC was the key to unlock further progress
Giving a browser to these agents is a no brainer, especially if one works in QA or develops web-based services
by antves
2/6/2026 at 2:22:28 PM
Congrats for shipping.How does it compare to Agent Browser by Vercel?
by franze
2/6/2026 at 3:24:24 PM
Thanks for asking! There are a few core differences: 1. we expose a higher level interface which allows the agent to think about what to do as opposed to what to do 2. we developed a token-efficient representation of the webpages that combines both visual and textual elements, heavily optimized for what LLMs are good at. 3. because we control the agentic loop, it also means that we can do fancy things on contextual injections, compressions, asynchronous manipulations, etc which are impossible to achieve when exposing the navigation interface 4. we use a coding agent under the hood, meaning that it can express complex actions efficiently and effectively compared to the CLI interface that agent-browser exposes 5. because we control the agent, we can use small and efficient LLMs which make the system much faster, cheaper, and more reliableAlso, our service comes with batteries included: the agent can use browsers in our cloud with auto-captcha solvers, stealth mode, we can proxy your own ip, etc
by antves
2/6/2026 at 6:42:25 PM
typo: what to do as opposed to how to do itby antves
2/6/2026 at 2:42:47 PM
i can see a new token efficient mirror web possibly emerging using content type headers on the request sideforms, PRG, semantic HTML and no js needed
by waynenilsen
2/6/2026 at 3:28:52 PM
Totally agree! The web for agents is evolving very fast and it's still unclear what it will look likeOur take is that, while that happens, agents today need to be able to access all the web resources that we can access as humans
Also, browsers are a really special piece of software because they provide access to almost every other kind of software. This makes them arguably the single most important tool for AI agents, and that’s why we believe that a browser might be all agents need to suddenly become ten times more useful than they already are
by antves
2/6/2026 at 4:46:11 PM
seems unlikely, you're asking the entire internet to update their software for dubious improvementsby verdverm
2/6/2026 at 5:20:13 PM
I believe this shift will actually happen organically over timethere will be demand for AI-first online services as people continue to delegate more and more tasks to agents and this will drive implementation
by antves
2/6/2026 at 5:23:18 PM
If it's machine-machine comms, just use an APISeems dumb to create some other representation when we have an ubiquitous machine readable format that Ai understands quite well
by verdverm
2/6/2026 at 4:50:13 PM
i believe agent native sites will stand up and the incumbents will be forced to adaptsuch as agent native shopping platforms whereby a human will bring you something from walmart or what not could spring up and disrupt your instacart of the world
this of course is just one simple example, when it works better for the clawdbot or whatever comes next what are the users going to choose they'll say 'get me some apples from walmart using instacartforbots' because they know the agent success rate will be higher
by waynenilsen
2/6/2026 at 5:00:29 PM
> disrupt your instacartInstacrats primary resource is not the website, it's the network of shoppers. You cannot replace that with Ai
I stopped using these services very quickly because the person (or machine) on the other side will never pick the same way I do. They don't care about quality, they care about time & money. My use of Ai is not going to change their incentives
by verdverm
2/6/2026 at 4:48:21 PM
Interesting approach. Exposing high-level goals rather than UI actions definitely reduces token overhead, but reproducible comparisons with open-source setups would strengthen the claim. Also, remote browsers introduce a new attack surface—sandboxing helps, but I’d like to see clear isolation guarantees against malicious pages or rogue scripts.by KevinChasse
2/6/2026 at 2:31:10 PM
Ironically, the landing page and docs pages of Smooth aren't all that token-efficient!by behnamoh
2/6/2026 at 3:26:03 PM
Ahah, indeed that's true... That's why we've just released Smooth CLI (https://docs.smooth.sh/cli/overview) and the SKILL.md (smooth-sdk/skills/smooth-browser/SKILL.md) associated with it. That should contain everything your agent needs to know to use Smooth. We will definitely add a LLM-friendly reference to it in the landing page and the docs introduction.by liukidar
2/6/2026 at 5:23:00 PM
Look this is cool idea, but subscribing to anything these days is a hard sell, we are all tired of subscription plans. You probably would be more succesful if you could find this to package in a way that is not subscription.by desireco42
2/6/2026 at 5:30:27 PM
would love to hear what pricing model would work best for youour current model is a subscription plan that determines the number of browsers available + credits top-ups for increased usage
by antves
