Show HN: Blast – Fast, multi-threaded serving engine for web browsing AI agents
45 comments
·May 2, 2025diggan
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?
calebhwin
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)
rollcat
> 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.
calebhwin
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.
lostmsu
> 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.
diggan
> 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 :)
calebhwin
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".
xena
How do I block your service? Do you read robots.txt and have an identifiable user agent?
diggan
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.
ATechGuy
Can browser-use be blocked using Anubis or other anti-bot measures?
pal9000i
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
croemer
...when there is an API. Often there isn't.
calebhwin
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.
dejobaan
> 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.
calebhwin
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.
lostmsu
Curious: if a user has an ad blocker, are they browsing responsibly?
xena
I will for my typical hourly rate plus the consulting bonus.
adrmtu
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
calebhwin
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.
gitroom
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?
mtrovo
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?
joshstrange
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.
calebhwin
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.
barbazoo
Looking forward to hearing more about that MCP successor you’re working on.
pal9000i
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
pal9000i
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
calebhwin
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.
triyambakam
Someone above said it's using browser-use which uses patchright
TheTaytay
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)
calebhwin
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.
anxman
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
null
badmonster
How does BLAST handle browser instance isolation and resource contention under high concurrency?
ivape
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.
calebhwin
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).
lgiordano_notte
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.
grahamgooch
Interesting. Could I use this to automate testing of massive web applications (100s of screens). And potentially load test?
diggan
> 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.
Hi HN!
BLAST is a high-performance serving engine for browser-augmented LLMs, designed to make deploying web-browsing AI easy, fast, and cost-manageable.
The goal with BLAST is to ultimately achieve google search level latencies for tasks that currently require a lot of typing and clicking around inside a browser. We're starting off with automatic parallelism, prefix caching, budgeting (memory and LLM cost), and an OpenAI-Compatible API but have a ton of ideas in the pipe!
Website & Docs: https://blastproject.org/ https://docs.blastproject.org/
MIT-Licensed Open-Source: https://github.com/stanford-mast/blast
Hope some folks here find this useful! Please let me know what you think in the comments or ping me on Discord.
— Caleb (PhD student @ Stanford CS)