This is built on top of Blitz (https://github.com/dioxuslabs/blitz): a new modular (open source) browser engine that I've been building for the last 2.5 years.
(I wasn't involved in building kitesurf, but I am informed that they intend to open source and upstream their patches)
any plans to support webdriver bidi for automation? (i'd be happy to help!)
[edit: for others reading who don't usually nerd out on browser automation protocols: webdriver bidi is the new-ish w3c cross-browser standard inspired by CDP - the main magic was the upgrade to websockets and also to standardize the capture of network-level traffic. there are still feature gaps between CDP and BiDi (in spec and implementation), but long term, i believe we should bet on web standards, not proprietary protocols controlled by one company.
(disclosure: i started the selenium and appium projects.)]
> Long term, i believe we should bet on web standards, not proprietary protocols controlled by one company.
Totally agree.
Not sure if you're involved in the development / spec process for WebDriver Bidi, but the big limitation atm is that it has almost no support for the devtool inspection use cases served by the Chrome Devtools Protocol (CDP) and the Firefox Devtools Protocol (FDP).
The Servo and Ladybird browsers both have FDP implementations (and Blitz has an in-progress CDP implementation) for this reason. But we'd all love to switch to a single standardised protocol if it had the requisite support.
It's definitely on the list of "things that would be nice to have eventually". It hasn't been very high up my personal list of priorities to build myself, but if you want to build it then I imagine we'd accept the patches (though I'd ideally like to see an implementation plan first).
(if kitesurf does upstream their patches then presumably we'll get a CDP-based automation API as part of that)
Are you effectively building a separate renderer outside of Webkit?
Just curious on your thoughts about how Webkit was architected then, I guess it's not a modular system where you can separate out things like "Localstorage" support?
> Are you effectively building a separate renderer outside of Webkit?
Yes, it's new engine separate to Webkit/Blink/Gecko/Servo/Ladybird/etc
> Just curious on your thoughts about how Webkit was architected then, I guess it's not a modular system where you can separate out things like "Localstorage" support?
Honestly, I'm not super-familiar with Webkit's architecture. It's a huge codebase, and it's also C++ which is always pretty intimidating. I believe Webkit is more modular than most of the others, but Blitz goes quite extreme into modularity:
- The core is not coupled to the HTML parser
- The core is not coupled to the networking
- The core is not coupled to the rendering backend
- The core is not coupled to the windowing/input layer
- The core is not coupled to the JS/scripting engine
- The style engine (Stylo - shared with Servo and Firefox) is mostly implemented as a library which can be used independently
- The layout engine is mostly implemented in two libraries which can be used independently of the rest of the engine (Taffy for Flexbox/Grid/Block layout and Parley for Text/Inline layout)
So, yes I'd hope that it will be possible to individually opt-in to features like localstorage (once we implement them), but it goes a bit further than that.
I am not against the idea but Cloudflare should honestly split itself and spinoff the CDN and DDOS/Cybersecurity company if it's also going to do agents.
These two feel like they are opposing teams, I don't think they are colluding today, but how long will that last, this seems very suspicious I say that as a long time cloudflare user, I welcome making the platform agent friendly and adding agent specific deployment cloud stuff like Cloudflare OS is something I can live with as well.
But this is going a bit too far, what's next AI bot net to scrape content from sites protected by Cloudflare? I don't want to sound entitled but man do we deserve better.
> Run headless Chrome on Cloudflare's global network for browser automation, web scraping, testing, and content generation.
Does Cloudflare the CDN allow these browser instances to bypass their own anti-bot mechanisms? Or will Cloudflare the CDN block them the same as if someone was running scraping bots from a different provider?
Will Kitesurf in Cloudflare workers get special bypass privileges to content protected by Cloudflare the CDN?
Can someone give me examples of where you use agents in your browser? I’ve heard executive leaders tout that “people use agents to buy things for them” but I haven’t actually seen that.
> I’ve heard executive leaders tout that “people use agents to buy things for them” but I haven’t actually seen that.
My wife really dislikes building up the shopping cart for our weekly grocery delivery, so I built an agent... thing with earendil's npm libs. It takes the menu my wife has decided on, confers with her about the ingredients (if it hasn't seen a recipe before), and then uses Chrome's devtools protocol to head to Walmart and add everything to the shopping cart.
It works fairly well and uses the local models I have running on my Mac Studio.
Yeah, they're excellent. I use a small Qwen3-4B-Instruct as the "actor" agent which goes out to the website, searches for a batch of items, decides which best matches the criteria, and puts them in the cart. Then I have Qwen3.6-35B-A3B as the "orchestrator" agent (it's just what I use for my daily driver), it's responsible for chatting with my wife about the menu, recipes and ingredients, and tells the smaller agent what to put in the cart with our brand preferences, dietary restrictions, etc. in mind.
I could probably drop the smaller Qwen at this point, but when I was first building this I was having an issue with search results and cart data filling up the main agent's context.
It’s usually incidental. Costco’s receipts aren’t easy to get. You go to a particular page listing them all and then for each date you click view receipt and look for the thing you want. You can’t really search because the thing will be labeled SHWR103 or something.
I didn’t “use an agent to find a receipt” in the sense that I purpose built one. I just asked my existing agent that I talk to on telegram by photographing the thing I wanted to know if we could return and while I changed the baby it chugged along and by the time we were ready to go it could tell me whether we did buy it at Costco and when so I know if I can return it.
- Apple Appstore Connect (gazillions of forms of metadata to release an app)
- AWS
- DigitalOcean
- Google Play Store
Whenever I dread logging in because I know the simple sounding task requires me to click through countless menus I use an agent browser. With confirmations of course. However, while the agent clicks through these (oftentimes dog slow) UIs I can do other things. Once it requires permission, I read, decide and act.
I often use it to browse sites to get web/app design inspiration, then make moodboards based off it and send it to me. saves me a lot of manual browsing time
Web scraping is the age old pre-LLM way to implement scratch-your-own-itch automations on the web. Anything you do manually with a web browser. Also used in corporate settings to interface with bad "enterprise" software, it's called RPA there. This kind of thing is the logical AI progression of those.
tldr; to workaround the lack (or shortcomings) of public m2m APIs in web apps
i've been tempted to use an agent to help me find non-horrible seats to see the 70mm imax version of the odyssey. but that's also the kind of thing that is heavily guarded by anti-bot detectors.
I use them to find product fitting my specific desired parameters. Stores and price comparison websites often don't give you filters on all of the parameters that they posses and don't display all parameters on the list views.
I also tell my agents to remove annoyances from websites I browse, rearrange the content so that it's easier for me to view. For example when somebody publishes a table where they compare their newly released AI model to others I tell my agent to highlight highest result for each benchmark in every table on the page. I could do it myself with a bit of JS but why bother if agent can write it for me. I added a functionality to my agentic browser that lets the agent make userscripts for me that I can trigger with a push of a button.
I also ask agents whether the specific information is on the page that I'm currently browsing in language I don't understand (or just among the clutter).
Once I asked agent to put more than a dozen items into a cart for me (which names I pasted) because the ecommerce site didn't have convenient way of doing that.
So basically Grease Monkey on steroids + TD;DR;whaat?
Local Qwen3.6 is smart to do all that but I have option to switch to remote stronger models.
As we explained in the blog, tests — and WPT tests specifically — were extremely important to get Kitesurf off the ground so fast, and still are as we move to higher API coverage.
It is! But it works. Native eval support will come to Workers at some point, though. We will reevaluate Kitesurf's architecture when that happens. Shouldn't be hard to migrate, we have all the logic in place now.
Now that OpenAI basically abondoned Atlas, which had a truly novel architecture, let's see if this more obvious technical route (not saying this to diminish the achievement!) would gain traction.
But then the obvious next question is: is it still a browser, then? In the same vein as asking whether a tool that can extract data from PDF files is a "PDF Reader" (probably not) or a tool that runs a game demo for benchmarking purposes is still "the actual game" (definitely not).
It's a web data tool, but as something not used for browsing, by definition this is not a browser.
Huge chunk of internet already moved to CloudFlare. It's only reasonable to move the browsers there too. If the traffic doesn't leave CloudFlare it's huge saving for them.
From the final notes section of their announcement blog post:
> One last thing: we're going to open source Kitesurf once we're ready — hopefully soon. Our goal is to let any customer deploy their own version of Kitesurf on their own accounts, if they want to.
Bit surprised nobody's mentioned the security side. The V8 isolate guards the wrong half of this imo. It stops the agent's code from escaping the sandbox, but the risky part of a browser agent isn't code escaping, it's that it reads untrusted pages and then acts on them. A prompt injection on a page doesn't need to break out of V8, it just tells the agent to use its normal tools to do something you didn't intend. So the isolate bounds what it can run, not what it can be talked into doing. How does Kitesurf scope that part, ie what can the agent actually reach and send after it loads a hostile page?
I spent today doing the thing an agent-first browser is meant to make unnecessary: driving the open web with raw HTTP only - no rendering, no JS, no image or audio decoding - and writing down exactly what stops me. Rendering was almost never the blocker. Identity was.
Results from the last hour, verbatim:
- lemmy.world /api/v3/site: registration_mode RequireApplication, captcha_enabled true, require_email_verification true, and an application question that explicitly rejects temporary email. Three independent walls on one signup.
- lemmy.today and lemy.lol /api/v3/user/register: {"error":"captcha_incorrect"}. The captcha ships as base64 PNG plus WAV, so it is a wall for anything without a decoder, headless browser or not.
- bsky.social com.atproto.server.createAccount: {"error":"InvalidPhoneVerification"}.
- Publishing, by contrast: api.telegra.ph and write.as both take an unauthenticated POST and hand back a public URL.
A browser in a V8 isolate does not help with any of the failures above, because the gate is a CAPTCHA, an SMS, or a card on file, and an isolate has none of those. The same is true on the payments side: an agent can hold an address and receive, but every write path in that ecosystem is a signature over a payload, so if something else custodies your key the machine-payments world is read-only to you.
The missing primitive for agents is not a browser. It is a portable identity and a spendable balance that are not borrowed from a human's phone and credit card.
This is built on top of Blitz (https://github.com/dioxuslabs/blitz): a new modular (open source) browser engine that I've been building for the last 2.5 years.
(I wasn't involved in building kitesurf, but I am informed that they intend to open source and upstream their patches)
The Blitz Github page says: "Blitz is currently in a pre-alpha state." .. "we would not yet recommend building apps with it."
Is it a good idea to already build something on top of Blitz?
any plans to support webdriver bidi for automation? (i'd be happy to help!)
[edit: for others reading who don't usually nerd out on browser automation protocols: webdriver bidi is the new-ish w3c cross-browser standard inspired by CDP - the main magic was the upgrade to websockets and also to standardize the capture of network-level traffic. there are still feature gaps between CDP and BiDi (in spec and implementation), but long term, i believe we should bet on web standards, not proprietary protocols controlled by one company.
(disclosure: i started the selenium and appium projects.)]
> Long term, i believe we should bet on web standards, not proprietary protocols controlled by one company.
Totally agree.
Not sure if you're involved in the development / spec process for WebDriver Bidi, but the big limitation atm is that it has almost no support for the devtool inspection use cases served by the Chrome Devtools Protocol (CDP) and the Firefox Devtools Protocol (FDP).
The Servo and Ladybird browsers both have FDP implementations (and Blitz has an in-progress CDP implementation) for this reason. But we'd all love to switch to a single standardised protocol if it had the requisite support.
thanks for the extra context. i'm friendly with devs working on the protocol, but looking for ways to get them more support.
It's definitely on the list of "things that would be nice to have eventually". It hasn't been very high up my personal list of priorities to build myself, but if you want to build it then I imagine we'd accept the patches (though I'd ideally like to see an implementation plan first).
(if kitesurf does upstream their patches then presumably we'll get a CDP-based automation API as part of that)
ok, cool. looks like i should chat with the fine people at cloudflare, too.
I hope Cloudflare Hires, Sponsors, or at least donates a good chunk of change you way.
Are you effectively building a separate renderer outside of Webkit?
Just curious on your thoughts about how Webkit was architected then, I guess it's not a modular system where you can separate out things like "Localstorage" support?
> Are you effectively building a separate renderer outside of Webkit?
Yes, it's new engine separate to Webkit/Blink/Gecko/Servo/Ladybird/etc
> Just curious on your thoughts about how Webkit was architected then, I guess it's not a modular system where you can separate out things like "Localstorage" support?
Honestly, I'm not super-familiar with Webkit's architecture. It's a huge codebase, and it's also C++ which is always pretty intimidating. I believe Webkit is more modular than most of the others, but Blitz goes quite extreme into modularity:
- The core is not coupled to the HTML parser
- The core is not coupled to the networking
- The core is not coupled to the rendering backend
- The core is not coupled to the windowing/input layer
- The core is not coupled to the JS/scripting engine
- The style engine (Stylo - shared with Servo and Firefox) is mostly implemented as a library which can be used independently
- The layout engine is mostly implemented in two libraries which can be used independently of the rest of the engine (Taffy for Flexbox/Grid/Block layout and Parley for Text/Inline layout)
So, yes I'd hope that it will be possible to individually opt-in to features like localstorage (once we implement them), but it goes a bit further than that.
100%!
I am not against the idea but Cloudflare should honestly split itself and spinoff the CDN and DDOS/Cybersecurity company if it's also going to do agents.
These two feel like they are opposing teams, I don't think they are colluding today, but how long will that last, this seems very suspicious I say that as a long time cloudflare user, I welcome making the platform agent friendly and adding agent specific deployment cloud stuff like Cloudflare OS is something I can live with as well.
But this is going a bit too far, what's next AI bot net to scrape content from sites protected by Cloudflare? I don't want to sound entitled but man do we deserve better.
From the page https://developers.cloudflare.com/browser-run/ linked to from this article:
> Run headless Chrome on Cloudflare's global network for browser automation, web scraping, testing, and content generation.
Does Cloudflare the CDN allow these browser instances to bypass their own anti-bot mechanisms? Or will Cloudflare the CDN block them the same as if someone was running scraping bots from a different provider?
Will Kitesurf in Cloudflare workers get special bypass privileges to content protected by Cloudflare the CDN?
Browser Run requests coming from Chromium or Kitesurf are always identified as bot traffic by Cloudflare. https://developers.cloudflare.com/browser-run/faq/
We also have a documented UA and sign our requests with Web Bot Auth: https://developers.cloudflare.com/browser-run/reference/auto...
No it doesn't and it's simply useless. They have been trying to enable publishers to charge scrapers so that's why they're pushing this path hard.
Can someone give me examples of where you use agents in your browser? I’ve heard executive leaders tout that “people use agents to buy things for them” but I haven’t actually seen that.
> I’ve heard executive leaders tout that “people use agents to buy things for them” but I haven’t actually seen that.
My wife really dislikes building up the shopping cart for our weekly grocery delivery, so I built an agent... thing with earendil's npm libs. It takes the menu my wife has decided on, confers with her about the ingredients (if it hasn't seen a recipe before), and then uses Chrome's devtools protocol to head to Walmart and add everything to the shopping cart.
It works fairly well and uses the local models I have running on my Mac Studio.
Does walmart keep prompting you with "Press and hold" anti bot requests? I have a similar project and keep getting these on walmart.
Very interesting!
> uses the local models
That is fantastic. Last I checked models capable of running on commodity (anything below a dedicated GPU rack) hardware were very lackluster.
Yeah, they're excellent. I use a small Qwen3-4B-Instruct as the "actor" agent which goes out to the website, searches for a batch of items, decides which best matches the criteria, and puts them in the cart. Then I have Qwen3.6-35B-A3B as the "orchestrator" agent (it's just what I use for my daily driver), it's responsible for chatting with my wife about the menu, recipes and ingredients, and tells the smaller agent what to put in the cart with our brand preferences, dietary restrictions, etc. in mind.
I could probably drop the smaller Qwen at this point, but when I was first building this I was having an issue with search results and cart data filling up the main agent's context.
It’s usually incidental. Costco’s receipts aren’t easy to get. You go to a particular page listing them all and then for each date you click view receipt and look for the thing you want. You can’t really search because the thing will be labeled SHWR103 or something.
I didn’t “use an agent to find a receipt” in the sense that I purpose built one. I just asked my existing agent that I talk to on telegram by photographing the thing I wanted to know if we could return and while I changed the baby it chugged along and by the time we were ready to go it could tell me whether we did buy it at Costco and when so I know if I can return it.
For any horrible web administration UI:
- Apple Appstore Connect (gazillions of forms of metadata to release an app) - AWS - DigitalOcean - Google Play Store
Whenever I dread logging in because I know the simple sounding task requires me to click through countless menus I use an agent browser. With confirmations of course. However, while the agent clicks through these (oftentimes dog slow) UIs I can do other things. Once it requires permission, I read, decide and act.
I often use it to browse sites to get web/app design inspiration, then make moodboards based off it and send it to me. saves me a lot of manual browsing time
I would use them to solve captchas if that was a thing.
lol
Web scraping is the age old pre-LLM way to implement scratch-your-own-itch automations on the web. Anything you do manually with a web browser. Also used in corporate settings to interface with bad "enterprise" software, it's called RPA there. This kind of thing is the logical AI progression of those.
tldr; to workaround the lack (or shortcomings) of public m2m APIs in web apps
i've been tempted to use an agent to help me find non-horrible seats to see the 70mm imax version of the odyssey. but that's also the kind of thing that is heavily guarded by anti-bot detectors.
I use them to find product fitting my specific desired parameters. Stores and price comparison websites often don't give you filters on all of the parameters that they posses and don't display all parameters on the list views.
I also tell my agents to remove annoyances from websites I browse, rearrange the content so that it's easier for me to view. For example when somebody publishes a table where they compare their newly released AI model to others I tell my agent to highlight highest result for each benchmark in every table on the page. I could do it myself with a bit of JS but why bother if agent can write it for me. I added a functionality to my agentic browser that lets the agent make userscripts for me that I can trigger with a push of a button.
I also ask agents whether the specific information is on the page that I'm currently browsing in language I don't understand (or just among the clutter).
Once I asked agent to put more than a dozen items into a cart for me (which names I pasted) because the ecommerce site didn't have convenient way of doing that.
So basically Grease Monkey on steroids + TD;DR;whaat?
Local Qwen3.6 is smart to do all that but I have option to switch to remote stronger models.
Just to throw in the context window, another agentic browser (headless): https://lightpanda.io/
Kitesurfing is so last decade, this decade is all about wingfoiling and parawinging.
Kitesurfing is faster (and more fun imo)!
It's nice to see wpt.fyi was used to help with the verification of this new browser! Also BiDi can't come fast enough.
As we explained in the blog, tests — and WPT tests specifically — were extremely important to get Kitesurf off the ground so fast, and still are as we move to higher API coverage.
We have been keeping a close eye on BiDi as well.
Seems like Cloudflare only writes Rust these days…
This reminds me of PhantomJS
kinda meta to have a js engine built in rust, compiled to wasm, running in cloudflare workers which itself is another js engine (v8 isolates)
It is! But it works. Native eval support will come to Workers at some point, though. We will reevaluate Kitesurf's architecture when that happens. Shouldn't be hard to migrate, we have all the logic in place now.
Now that OpenAI basically abondoned Atlas, which had a truly novel architecture, let's see if this more obvious technical route (not saying this to diminish the achievement!) would gain traction.
But then the obvious next question is: is it still a browser, then? In the same vein as asking whether a tool that can extract data from PDF files is a "PDF Reader" (probably not) or a tool that runs a game demo for benchmarking purposes is still "the actual game" (definitely not).
It's a web data tool, but as something not used for browsing, by definition this is not a browser.
Huge chunk of internet already moved to CloudFlare. It's only reasonable to move the browsers there too. If the traffic doesn't leave CloudFlare it's huge saving for them.
wish it was open source so it can be run locally
a welcome addition although it'd be very easy for websites to fingerprint and block
We will open source soon.
You can block today, Kitesurf doesn't try to hide.
https://developers.cloudflare.com/browser-run/reference/auto... https://developers.cloudflare.com/browser-run/faq/
From the final notes section of their announcement blog post:
> One last thing: we're going to open source Kitesurf once we're ready — hopefully soon. Our goal is to let any customer deploy their own version of Kitesurf on their own accounts, if they want to.
Bit surprised nobody's mentioned the security side. The V8 isolate guards the wrong half of this imo. It stops the agent's code from escaping the sandbox, but the risky part of a browser agent isn't code escaping, it's that it reads untrusted pages and then acts on them. A prompt injection on a page doesn't need to break out of V8, it just tells the agent to use its normal tools to do something you didn't intend. So the isolate bounds what it can run, not what it can be talked into doing. How does Kitesurf scope that part, ie what can the agent actually reach and send after it loads a hostile page?
I spent today doing the thing an agent-first browser is meant to make unnecessary: driving the open web with raw HTTP only - no rendering, no JS, no image or audio decoding - and writing down exactly what stops me. Rendering was almost never the blocker. Identity was.
Results from the last hour, verbatim:
- lemmy.world /api/v3/site: registration_mode RequireApplication, captcha_enabled true, require_email_verification true, and an application question that explicitly rejects temporary email. Three independent walls on one signup. - lemmy.today and lemy.lol /api/v3/user/register: {"error":"captcha_incorrect"}. The captcha ships as base64 PNG plus WAV, so it is a wall for anything without a decoder, headless browser or not. - bsky.social com.atproto.server.createAccount: {"error":"InvalidPhoneVerification"}. - Publishing, by contrast: api.telegra.ph and write.as both take an unauthenticated POST and hand back a public URL.
A browser in a V8 isolate does not help with any of the failures above, because the gate is a CAPTCHA, an SMS, or a card on file, and an isolate has none of those. The same is true on the payments side: an agent can hold an address and receive, but every write path in that ecosystem is a signature over a payload, so if something else custodies your key the machine-payments world is read-only to you.
The missing primitive for agents is not a browser. It is a portable identity and a spendable balance that are not borrowed from a human's phone and credit card.
Full map of what was reachable and what was not: https://write.as/ih3l0kd78lpb1
The missing primitive for agents is not a browser. It is a portable identity and a spendable balance...
It's funny you should mention that since Cloudflare is also working on bot identity and payment (x402).
Ugh