What measures are you using to make sure you're not bombarding websites with a ton of requests, since you seem to automatically "scale up" the concurrency to create even more requests/second? Does it read any of the rate-limit headers from the responses or do something else to back-off in case what it's trying to visit suddenly becomes offline or starts having slower response times?
Slightly broader question: Do you feel like there is any ethical considerations one should think about before using something like this?
The main sort of parallelism we exploit is across distinct websites. For example "find me the cheapest rental" spawning tasks to look at many different websites. There is another level of parallelism that could be exploited within a web site/app. And yes we would have to make our planner rate limit aware for that.
Absolutely agree there are ethical considerations with web browsing AI in general. (And the whole general ongoing shift from using websites to using chatgpt/perplexity)
> There is another level of parallelism that could be exploited within a web site/app. And yes we would have to make our planner rate limit aware for that.
People are already deploying tools like Anubis[1] or go-away[2] to cope with the insane load that bots put on their server infrastructure. This is an arms race. In the end, the users lose.
IMO it depends on how this tech is deployed. One way I see this being extremely useful is for developers to quickly build AI automation for their own sites.
E.g. if I'm the developer of a workforce management app (e.g. https://WhenIWork.com) I could deploy BLAST to quickly provide automation for users of my app.
That's my point. You can use a knife to slice bread or to stab your neighbor. We're seeing an unprecedented amount of stabbings. People are getting away with murder, there's no accountability. Refining the stilettos doesn't help the problem.
I think it would take more substantiation to claim this. Maybe 10 out of 1000 websites will get closed, but the users will be able to use AI tools to use the remaining 990. Not sure about you, but sounds like a win for users to me.
this may be true for the time being (or not), but will sure change if/when more [websites] become aware of what is going on. The result will be 10 out of 1000 websites will remain open, and not the ones you actually want.
The more pressure there is on the sites/servers, the more these will have to act to stay online to begin with.
Maybe more of a legal than ethical consideration but web browsing AI makes scraping trivial. You could use that for surveillance, profiling (get a full picture of a user's whole online life before they even hit Sign Up), cutting egress cost in certain cases. Right now CAPTCHA is actually holding up pretty well against web browsing AI for sites that really want to protect their IP but it will be interesting to see if that devolves into yet another instance of an AI vs AI "arms race".
It's not immediately clear to me if this is a tool for ages (e.g. a MCP server), a browser engine (e.g. browserless) or some sort of OpenAI compatible LLM proxy that injects a web browser tool? It appears to expose itself via an openAI compatible API which makes me think the latter?
I'm guessing because of the amount of flags, you could probably come up with a unique fingerprint for browser-use, based on available features, screen/canvas size and so on, that could be reused for blocking everyone using Blast/browser-use.
If calebhwin wanted to make Blast easier to identify, they could set a custom user-agent for browser-use that makes it clear it's Blast doing the browsing for the user.
I think these kind of requests can not be blocked. It is like asking if Claude computer control can be blocked from visiting websites. It is not detectable.
You could ofc display captchas which are difficult to solve for an AI.
Browser-use just switched to patchright https://github.com/Kaliiiiiiiiii-Vinyzu/patchright which is an “undetectable” version of Playwright and can rotate/randomize fingerprints. Another extension uses residential proxies and pulls real fingerprints of real people.
The whole point of AI browser automation is mimicking human behaviour, fighting the anti-bot detection systems. If the point is interacting with systems, we'd be using APIs
How can I find for myself an affordable accommodation in Iceland across several websites aggregating cheap accommodation but without signing API access contract with all of them and without building a middleware to abstract them?
I think it's cool that you're experimenting in this area, but I'm not a huge fan of this as answer to a question about responsible/respectful web crawling. This stuff seems like it should be table stakes (even if you wanted to make it optional for the end user), but "yeah probably; learn the codebase, fork it, make changes, then we'll review it" really puts the onus onto the original poster.
Ah you're right, my bad. Hope I didn't sound dismissive because I think some sort of robots.txt needs to exist for AI that's scraping the web both at train or test time.
I'm really not excited at all about the "scrape other people's data" use case for BLAST and if we can prevent it then awesome. I'm excited about BLAST automating science, legacy web apps, internal tools, adding AI automation to your own app, etc.
Cool project! How does the prefix cache work exactly? What’s your invalidation strategy when the page’s structure drifts (and how often do you refresh)? And how do you match an incoming question or task to the correct cached prefix? What criteria or fingerprinting logic do you use to ensure high hit rates without false positives
Thank you! It's currently based on task lineage, exact match of task descriptions, and an optional user-provided cache_control argument that can control whether results or plans are cached.
One use-case for this is conversations: So for example if I invoke /chat/completions with [{"role": "user", "content": "Go to google.com"}] and later with [{"role": "user", "content": "Go to google.com"}, {"role": "user", "content": "Search for gorilla vs 100 human"}] then we cache the browser state from the first invocation so it can be quickly restored (or reuse the browser if not evicted).
Caching will get much more sophisticated in a future version, it's the piece we're most actively working on.
Great work! I just tried it and Google immediately captcha'd me on the first attempt. Is it using playwright or patchright? patchright using chrome and not chromium is more robust
Also any plans to add remote browser control feature? For Human in the loop tasks, for example advanced captcha bypassing and troubleshooting tasks that are stuck
Yes, human-in-the-loop is definitely on the roadmap. It's orthogonal to the central goal of low latency but necessary for completeness. Either via VNC or something simpler we have in mind.
I don't work close to LLM APIs so not sure what exactly is the use case here? Is it something that could be adapted to work as a deep research feature on a custom product?
This looks really cool but wouldn't this be better as an MCP server? It feels like it's mixing too many concepts and can't be plugged into another system. What if I want to extend my agent to use this but I already have MCP servers tied in or I'm going through another OpenAI proxy-type thing? I wouldn't want to stack proxies.
Great point, we are working on an MCP server implementation which should address this. The main benefit of having a serving engine here is to abstract away browser-LLM specific optimizations like parallelism, caching, browser memory management, etc. It's closer to vllm but I agree an MCP server implementation will make integration easier.
Though ultimately I think the web needs something better than MCP and we're actively working on that as well.
I read through the docs and want to try this.
I couldn’t figure out what you were using g under the covers for the actual webpage “use”
I did see: “ What we’re not focusing on is building a better Browser-Use, Notte, Steel, or other vision LLM. Our focus is serving these systems in a way that is optimized under constraints”
Cool! That makes sense!but I was still curious what your default AI-driven browser use library was.
If I were to use your library right now on my MacBook, is it using “browser-use” under the covers by default? (I should poke around the source more. I just thought it might be helpful to ask here in case I misunderstand or in case others had the same question)
Yes! And browser-use is great though I'm hoping at some point we can swap it out for something leaner, maybe one day it'll just be a vision language model. All we'll have to do within BLAST is implement a new Executor and all the scheduling/planning/resource management stays the same.
I was a little unclear at first, after looking at the source code, it looks like Blast uses Browser Use which uses your local browser (in dev) under the hood
A queue? What else can you really do. Your server is at the mercy of OpenAI, so all you can do is queue up everyone's requests. I don't know how many parallel requests you can send out to OpenAI (infinite?), so that bottleneck is probably just dependent on your server stack (how many threads).
There's a lot of language being thrown out here, and I'm trying to see if we're using too much language to discuss basic concepts.
There's definitely opportunities to parallelize. BLAST exploits these with an LLM-planner and tool calls to dynamically spawn/join subtasks (there's also data parallelism and request hedging which further reduce latency).
Now you are right that at some point you'll get throttled either by LLM rate limits or a set budget for browser memory usage or LLM cost. BLAST's scheduler is aware of these constraints and uses them to effectively map tasks to resources (resource=browser+LLM).
You wanna load test the local DOM rendering or what? Otherwise, whatever endpoint is serving the HTML, you configure your load tests to hit that, if anything. Although you'd just be doing the same testing your HTTP server probably already doing before doing releases, usually you wanna load test your underlying APIs or similar instead.
Looks really cool.
Curious how you're handling action abstraction?
We've found that semantically parsing the DOM to extract high-level intents—like "click 'Continue'" instead of 'click div#xyz' helps reduce hallucination and makes agent planning more robust.
I know it's impossible to avoid name collisions at this stage of the game, but BLAST is basically the Google of biological sequence alignment / search:
What measures are you using to make sure you're not bombarding websites with a ton of requests, since you seem to automatically "scale up" the concurrency to create even more requests/second? Does it read any of the rate-limit headers from the responses or do something else to back-off in case what it's trying to visit suddenly becomes offline or starts having slower response times?
Slightly broader question: Do you feel like there is any ethical considerations one should think about before using something like this?
The main sort of parallelism we exploit is across distinct websites. For example "find me the cheapest rental" spawning tasks to look at many different websites. There is another level of parallelism that could be exploited within a web site/app. And yes we would have to make our planner rate limit aware for that.
Absolutely agree there are ethical considerations with web browsing AI in general. (And the whole general ongoing shift from using websites to using chatgpt/perplexity)
> There is another level of parallelism that could be exploited within a web site/app. And yes we would have to make our planner rate limit aware for that.
People are already deploying tools like Anubis[1] or go-away[2] to cope with the insane load that bots put on their server infrastructure. This is an arms race. In the end, the users lose.
[1]: https://anubis.techaro.lol
[2]: https://git.gammaspectra.live/git/go-away
IMO it depends on how this tech is deployed. One way I see this being extremely useful is for developers to quickly build AI automation for their own sites.
E.g. if I'm the developer of a workforce management app (e.g. https://WhenIWork.com) I could deploy BLAST to quickly provide automation for users of my app.
That's my point. You can use a knife to slice bread or to stab your neighbor. We're seeing an unprecedented amount of stabbings. People are getting away with murder, there's no accountability. Refining the stilettos doesn't help the problem.
I just block every AI bot that doesn’t give me traffic or other benefits. I know I can’t block them all, but it won’t be for a lack of trying.
> In the end, the users lose.
I think it would take more substantiation to claim this. Maybe 10 out of 1000 websites will get closed, but the users will be able to use AI tools to use the remaining 990. Not sure about you, but sounds like a win for users to me.
Yes, and these are the websites that aren't behind CloudFlare or some other CDN. The holdouts of the open, independent Internet. Sure, let them burn.
>Maybe 10 out of 1000 websites will get closed
this may be true for the time being (or not), but will sure change if/when more [websites] become aware of what is going on. The result will be 10 out of 1000 websites will remain open, and not the ones you actually want. The more pressure there is on the sites/servers, the more these will have to act to stay online to begin with.
> Absolutely agree there are ethical considerations with web browsing AI in general.
I'm personally not sure there are, but I'm curious to hear what those are for you :)
Maybe more of a legal than ethical consideration but web browsing AI makes scraping trivial. You could use that for surveillance, profiling (get a full picture of a user's whole online life before they even hit Sign Up), cutting egress cost in certain cases. Right now CAPTCHA is actually holding up pretty well against web browsing AI for sites that really want to protect their IP but it will be interesting to see if that devolves into yet another instance of an AI vs AI "arms race".
It's not immediately clear to me if this is a tool for ages (e.g. a MCP server), a browser engine (e.g. browserless) or some sort of OpenAI compatible LLM proxy that injects a web browser tool? It appears to expose itself via an openAI compatible API which makes me think the latter?
How do I block your service? Do you read robots.txt and have an identifiable user agent?
Seems Blast uses browser-use (https://github.com/browser-use/browser-use) which seems to be some client specifically for AIs to connect to/run browser runtimes.
Unfortunately, it seems like browser-use tries to hide that it's controlled by an AI, and uses a typical browser user-agent: https://github.com/browser-use/browser-use/blob/d8c4d03d9ea9...
I'm guessing because of the amount of flags, you could probably come up with a unique fingerprint for browser-use, based on available features, screen/canvas size and so on, that could be reused for blocking everyone using Blast/browser-use.
If calebhwin wanted to make Blast easier to identify, they could set a custom user-agent for browser-use that makes it clear it's Blast doing the browsing for the user.
Can browser-use be blocked using Anubis or other anti-bot measures?
I think these kind of requests can not be blocked. It is like asking if Claude computer control can be blocked from visiting websites. It is not detectable. You could ofc display captchas which are difficult to solve for an AI.
As mentioned, browser-use doesn't seem "out of this world" hard to fingerprint since all instances would be using the exact same settings.
Browser-use just switched to patchright https://github.com/Kaliiiiiiiiii-Vinyzu/patchright which is an “undetectable” version of Playwright and can rotate/randomize fingerprints. Another extension uses residential proxies and pulls real fingerprints of real people.
Sorry if I'm missing something, but why can't Anubis not detect/block such AI agents? Is it because they use headful browsers?
The whole point of AI browser automation is mimicking human behaviour, fighting the anti-bot detection systems. If the point is interacting with systems, we'd be using APIs
How can I find for myself an affordable accommodation in Iceland across several websites aggregating cheap accommodation but without signing API access contract with all of them and without building a middleware to abstract them?
I don't have API for _that_.
No, it's to automate tasks that can't be done using an API, like RPA.
...when there is an API. Often there isn't.
Good point, we should probably integrate that. Feel free to submit a PR!
BLAST can also be used to add automation to your own site/app FWIW.
> Feel free to submit a PR!
I think it's cool that you're experimenting in this area, but I'm not a huge fan of this as answer to a question about responsible/respectful web crawling. This stuff seems like it should be table stakes (even if you wanted to make it optional for the end user), but "yeah probably; learn the codebase, fork it, make changes, then we'll review it" really puts the onus onto the original poster.
Ah you're right, my bad. Hope I didn't sound dismissive because I think some sort of robots.txt needs to exist for AI that's scraping the web both at train or test time.
I'm really not excited at all about the "scrape other people's data" use case for BLAST and if we can prevent it then awesome. I'm excited about BLAST automating science, legacy web apps, internal tools, adding AI automation to your own app, etc.
Curious: if a user has an ad blocker, are they browsing responsibly?
Very. Malvertising is a thing. Adtech surveillance is a thing.
Ad blocker is the least user can do.
That's not why most users use ad blockers.
I will for my typical hourly rate plus the consulting bonus.
Cool project! How does the prefix cache work exactly? What’s your invalidation strategy when the page’s structure drifts (and how often do you refresh)? And how do you match an incoming question or task to the correct cached prefix? What criteria or fingerprinting logic do you use to ensure high hit rates without false positives
Thank you! It's currently based on task lineage, exact match of task descriptions, and an optional user-provided cache_control argument that can control whether results or plans are cached.
One use-case for this is conversations: So for example if I invoke /chat/completions with [{"role": "user", "content": "Go to google.com"}] and later with [{"role": "user", "content": "Go to google.com"}, {"role": "user", "content": "Search for gorilla vs 100 human"}] then we cache the browser state from the first invocation so it can be quickly restored (or reuse the browser if not evicted).
Caching will get much more sophisticated in a future version, it's the piece we're most actively working on.
Great work! I just tried it and Google immediately captcha'd me on the first attempt. Is it using playwright or patchright? patchright using chrome and not chromium is more robust
Also any plans to add remote browser control feature? For Human in the loop tasks, for example advanced captcha bypassing and troubleshooting tasks that are stuck
Yes, human-in-the-loop is definitely on the roadmap. It's orthogonal to the central goal of low latency but necessary for completeness. Either via VNC or something simpler we have in mind.
Someone above said it's using browser-use which uses patchright
I don't work close to LLM APIs so not sure what exactly is the use case here? Is it something that could be adapted to work as a deep research feature on a custom product?
Looks sick tbh, way more power than I'd ever need for my own stuff - you think stuff like this ever just outpaces all the anti-bot blockers or nah?
This looks really cool but wouldn't this be better as an MCP server? It feels like it's mixing too many concepts and can't be plugged into another system. What if I want to extend my agent to use this but I already have MCP servers tied in or I'm going through another OpenAI proxy-type thing? I wouldn't want to stack proxies.
Great point, we are working on an MCP server implementation which should address this. The main benefit of having a serving engine here is to abstract away browser-LLM specific optimizations like parallelism, caching, browser memory management, etc. It's closer to vllm but I agree an MCP server implementation will make integration easier.
Though ultimately I think the web needs something better than MCP and we're actively working on that as well.
Looking forward to hearing more about that MCP successor you’re working on.
Cool!
I read through the docs and want to try this. I couldn’t figure out what you were using g under the covers for the actual webpage “use” I did see: “ What we’re not focusing on is building a better Browser-Use, Notte, Steel, or other vision LLM. Our focus is serving these systems in a way that is optimized under constraints”
Cool! That makes sense!but I was still curious what your default AI-driven browser use library was.
If I were to use your library right now on my MacBook, is it using “browser-use” under the covers by default? (I should poke around the source more. I just thought it might be helpful to ask here in case I misunderstand or in case others had the same question)
Yes! And browser-use is great though I'm hoping at some point we can swap it out for something leaner, maybe one day it'll just be a vision language model. All we'll have to do within BLAST is implement a new Executor and all the scheduling/planning/resource management stays the same.
I was a little unclear at first, after looking at the source code, it looks like Blast uses Browser Use which uses your local browser (in dev) under the hood
How does BLAST handle browser instance isolation and resource contention under high concurrency?
resource contention under high concurrency
A queue? What else can you really do. Your server is at the mercy of OpenAI, so all you can do is queue up everyone's requests. I don't know how many parallel requests you can send out to OpenAI (infinite?), so that bottleneck is probably just dependent on your server stack (how many threads).
There's a lot of language being thrown out here, and I'm trying to see if we're using too much language to discuss basic concepts.
There's definitely opportunities to parallelize. BLAST exploits these with an LLM-planner and tool calls to dynamically spawn/join subtasks (there's also data parallelism and request hedging which further reduce latency).
Now you are right that at some point you'll get throttled either by LLM rate limits or a set budget for browser memory usage or LLM cost. BLAST's scheduler is aware of these constraints and uses them to effectively map tasks to resources (resource=browser+LLM).
Interesting. Could I use this to automate testing of massive web applications (100s of screens). And potentially load test?
> And potentially load test?
You wanna load test the local DOM rendering or what? Otherwise, whatever endpoint is serving the HTML, you configure your load tests to hit that, if anything. Although you'd just be doing the same testing your HTTP server probably already doing before doing releases, usually you wanna load test your underlying APIs or similar instead.
Looks really cool. Curious how you're handling action abstraction? We've found that semantically parsing the DOM to extract high-level intents—like "click 'Continue'" instead of 'click div#xyz' helps reduce hallucination and makes agent planning more robust.
I know it's impossible to avoid name collisions at this stage of the game, but BLAST is basically the Google of biological sequence alignment / search:
https://blast.ncbi.nlm.nih.gov/Blast.cgi
Right I figured there isn't a huge overlap of interested communities so hopefully not a point of confusion. I guess that could change!
The bigger collision is https://withblast.com/ (found via https://kagi.com/search?q=blast+llm )