Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Browser Use (YC W25) – open-source web agents

github.com

Post reply on HN
Print view View original

21–30 of 107 posts

Re: Launch HN: Browser Use (YC W25) – open-source web agents

#21

Post by MagMueller »

moralestapia wrote: post #7

Ha! I just saw this win an AI Hackaton in Toronto but they said it was their own thing, quite dishonest. Everyone was rightfully impressed, me as well not gonna lie. I was a bit sus someone could come up with something like this in a weekend, but they were from U of Waterloo, Vector Institute and whatnot, so I said "maybe". Now I know they were just a bunch of scammers, sad. Anyway, this is a great project, congratul…

For me, it simply demonstrates how easy and fast you can build these tools now. We have many fellow YC founders who build great products on top of browser-use. They don't have to quote us. I think it's awesome to enable so many new startup ideas.

Re: Launch HN: Browser Use (YC W25) – open-source web agents

#22

Post by MagMueller »

jackienotchan wrote: post #14

AI agents have lead to a big surge in scraping/crawling activity on the web, and many don't use proper user agents and don't stick to any scraping best practices that the industry has developed over the past two decades (robots.txt, rate limits). This comes with negative side effects for website owners (costs, downtime, etc.), as repeatedly reported on HN. Do you have any built-in features that address these issues?

Yes, some hosting services have experienced a 100%-1000% increase in hosting costs.

On most platforms, browser use only requires the interactive elements, which we extract, and does not need images or videos. We have not yet implemented this optimization, but it will reduce costs for both parties.

Our goal is to abstract backend functionality from webpages. We could cache this, and only update the cache if eTags change.

Websites that really don't want us will come up with audio captchas and new creative methods.

Agents are different from bots. Agents are intended as a direct user clone and could also bring revenue to websites.

Re: Launch HN: Browser Use (YC W25) – open-source web agents

#23

Post by [deleted] »

mritchie712 wrote: post #5

How do you keep your service from being blocked on LinkedIn? LinkedIn's API sucks. I run an analytics platform[0] that uses it and it only has 10% of what our customers are asking for. It'd be great to use browser-use, but in my experience, you run into all sort of issues with browser automation on LinkedIn. 0 - https://www.definite.app/

[deleted]

Re: Launch HN: Browser Use (YC W25) – open-source web agents

#24

Post by MagMueller »

mritchie712 wrote: post #5

How do you keep your service from being blocked on LinkedIn? LinkedIn's API sucks. I run an analytics platform[0] that uses it and it only has 10% of what our customers are asking for. It'd be great to use browser-use, but in my experience, you run into all sort of issues with browser automation on LinkedIn. 0 - https://www.definite.app/

If you run it locally, you can connect it to your real browser and user profile where you are already logged in. This works for me for LinkedIn automation, e.g., to send friend requests or answer messages.

A bigger problem on LinkedIn for us is all the nested UI elements and different scrolling elements. With some configuration in our extraction layer in buildDomTree.js and some custom actions, I believe someone could build a really cool LinkedIn agent.

Re: Launch HN: Browser Use (YC W25) – open-source web agents

#25

Post by erellsworth »

MagMueller wrote: post #22
jackienotchan wrote: post #14

AI agents have lead to a big surge in scraping/crawling activity on the web, and many don't use proper user agents and don't stick to any scraping best practices that the industry has developed over the past two decades (robots.txt, rate limits). This comes with negative side effects for website owners (costs, downtime, etc.), as repeatedly reported on HN. Do you have any built-in features that address these issues?

Yes, some hosting services have experienced a 100%-1000% increase in hosting costs. On most platforms, browser use only requires the interactive elements, which we extract, and does not need images or videos. We have not yet implemented this optimization, but it will reduce costs for both parties. Our goal is to abstract backend functionality from webpages. We could cache this, and only update the cache if eTags chan…

>Websites that really don't want us will come up with audio captchas and new creative methods.

Which you or other AIs will then figure a way around. You literally mention "extract data behind login walls" as one of your use cases so it sounds like you just don't give a shit about the websites you are impacting.

It's like saying, "If you really don't want me to break into your house and rifle through your stuff, you should just buy a more expensive security system."

Re: Launch HN: Browser Use (YC W25) – open-source web agents

#26

Post by gregpr07 »

cookiengineer wrote: post #10

I've been following your progress for a while now and I'm super impressed how far you've got already. Are you working on unifying the tools that the LLM uses with the MCP / model context protocol? As far as I understand, lots of other providers (like Bolt/Stackblitz etc) are migrating towards this. Currently, there's not many tools available in the upstream specification other than File I/O and some minor interaction…

hmm, I though about this a lot. But tbh I think MCP is sort of a gimmick... probably the better way is for agents just to understand the http apis directly. Maybe I'm wrong, very happy to be convinced differently. Do you think MCP server for the cloud version would be useful?

Re: Launch HN: Browser Use (YC W25) – open-source web agents

#27

Post by gregpr07 »

arjunchint wrote: post #8

Have you inspected or thought through the security of your open source library? You are using debugger tools such as CDP, launching playwright without a sandbox, and guiding users to launch Chrome in debugger mode to connect to browser-use on their main browser. The debugging tools you use have active exploits that Google doesn't fix because they are supposed to be for debugging and not for production/general use. Th…

how would that work? Can you control the browser without debug mode? Especially in production the browsers are anyway running on single instance docker containers so the file system is not accesible... are there exploits that can do harm from a virtual machine?

Re: Launch HN: Browser Use (YC W25) – open-source web agents

#28

Post by gregpr07 »

OsrsNeedsf2P wrote: post #18

Does anyone have experience comparing this to Skyvern[0]? I originally thought the $30/month would be the killer feature, but it's only $30 worth of credits. Otherwise they both seem to have the same offering [0] https://www.skyvern.com/

I think our cloud is much simpler (just one prompt and go). But it's also sort of a different service. The main differences come from the open source side - we are essentially building more of a framework for anytime to use and they are just a web app.

Re: Launch HN: Browser Use (YC W25) – open-source web agents

#29

Post by gregpr07 »

xnx wrote: post #13

Is it possible to mix browser-use with traditional DOM/XPath/CSS-selector automation? e.g. Have certain automation steps that are more fuzzy/AI like "click on the image of a cat"

We are experimenting with this. Currently the library api is very raw but technically possible (we introduced this notion of initial actions, which are just deterministic actions before the LLM kicks in) - https://github.com/browser-use/browser-use/blob/main/example....

The other way to achieve this with Browser Use is to save the history from `history = agent.run()` and rerun it with `agent.rerun_history(history)`.

I'd love to see if this can of any use to you!

Re: Launch HN: Browser Use (YC W25) – open-source web agents

#30

Post by nostrebored »

gregpr07 wrote: post #26
cookiengineer wrote: post #10

I've been following your progress for a while now and I'm super impressed how far you've got already. Are you working on unifying the tools that the LLM uses with the MCP / model context protocol? As far as I understand, lots of other providers (like Bolt/Stackblitz etc) are migrating towards this. Currently, there's not many tools available in the upstream specification other than File I/O and some minor interaction…

hmm, I though about this a lot. But tbh I think MCP is sort of a gimmick... probably the better way is for agents just to understand the http apis directly. Maybe I'm wrong, very happy to be convinced differently. Do you think MCP server for the cloud version would be useful?

strong agree with this -- I don't understand outside of integration with Claude Desktop why to use MCP rather than a dedicated API endpoint.
Post reply on HN