Kitesurf kostenlos? Diese Limits gelten in der Beta

Kitesurf kostenlos nutzen? Ja, solange sich der Browser in der Beta befindet. Das praktisch nutzbare Kontingent im Workers-Free-Tarif ist jedoch auf 10 Browser-Minuten pro Konto und Tag, drei gleichzeitige Browser Sessions und eine neue Sitzung alle 20 Sekunden begrenzt. Das reicht für einen klar eingegrenzten Pilottest – ist aber kein Beleg dafür, dass der gesamte Agenten-Stack nichts kostet.

Kitesurf kostenlos: Was gilt in der Beta?

Kitesurf ist kostenlos, solange sich der Browser in der Beta befindet. Cloudflare schreibt das ausdrücklich im Update vom 28. September 2026, ergänzt aber eine ebenso wichtige Einschränkung: Der Zugriff unterliegt den Browser-Run-Limits des jeweiligen Kontos.

Kitesurf ist Cloudflares zustandslose Browser-Engine für KI-Agenten. Sie läuft auf Workers und verzichtet zugunsten einer schlankeren, auf Agenten zugeschnittenen Laufzeit auf Funktionen klassischer Browser für Menschen. Für die Kitesurf-Engine fällt derzeit keine separate Gebühr an, Browser Run bildet aber weiterhin den Nutzungs- und Abrechnungsrahmen.

Die aktuellen Limits von Browser Run und die Preise von Browser Run ergeben vier Grenzen, die im direkten Vergleich besonders relevant sind:

„Kostenlos“ ist damit eine hilfreiche Produktaussage, aber keine vollständige Budgetaussage. Sie beschreibt, was Cloudflare während der Beta für Kitesurf berechnet. Offen bleibt, ob ein Workflow innerhalb der Kontolimits bleibt, ob Workers Paid nötig ist und welche Kosten das Modell des Agenten verursacht.

Die Preis- und Limitangaben in diesem Leitfaden wurden am 29. September 2026 anhand der öffentlich zugänglichen Cloudflare-Seiten geprüft. Für diesen Test stand kein authentifizierter Browser-Run-Auftrag zur Verfügung. Deshalb werden hier weder eine erfundene Dashboard-Rechnung noch vermeintlich gemessene Laufzeiten oder Erfolgsquoten von Tool-Aufrufen ausgewiesen.

Was änderte sich am 28. September 2026?

Das September-Update macht Kitesurf für breiter angelegte Piloten interessanter, weil die Engine nun mit den Schnittstellen verbunden ist, die Entwickler von Agenten ohnehin einsetzen. Der ursprüngliche Start im August brachte den Browser; das Update ergänzt die praxistauglichen Zugänge rundherum.

Erstens unterstützt Kitesurf jetzt WebMCP. Über diese Browser-API kann eine Website benannte Tools mit strukturierten Eingaben bereitstellen. Ein Agent kann damit beispielsweise eine Funktion nach Art von searchFlights() aufrufen, statt Schaltflächen aus Pixeln ableiten zu müssen. Laut Cloudflares WebMCP-Dokumentation kann Kitesurf solche Tools über das Chrome DevTools Protocol – meist kurz CDP genannt – auflisten und ausführen.

Zweitens deckt Kitesurf inzwischen die vollständige Browser Run API ab. Die Engine lässt sich über CDP, Playwright, Puppeteer oder MCP auswählen. Auch Quick Actions – Cloudflares Ein-Anfrage-Schnittstellen für Screenshots, HTML, PDFs und andere gängige Ausgaben – können Kitesurf aus einem Worker über env.BROWSER.quickAction() auswählen.

Drittens kann der Renderer in kompatiblen Terminals über das Kitty-Grafikprotokoll laufen; steht Kitty nicht zur Verfügung, gibt es einen reinen ANSI-Textmodus. So lässt sich die Seite aus Sicht des Agenten-Browsers betrachten, ohne einen separaten Desktop-Browser zu öffnen. Das erleichtert die Prüfung, stellt aber keinen neuen Abrechnungstarif für den Produktivbetrieb dar.

Cloudflare berichtet im September-Update außerdem, dass Kitesurf inzwischen mehr als 730,000 Untertests der Web Platform Tests besteht – über 500,000 mehr als zum Start. Das ist ein erheblicher Kompatibilitätsfortschritt, garantiert aber nicht, dass jedes beliebige Kundenportal korrekt gerendert wird. Eine klar begrenzte Liste von Zielseiten gehört deshalb weiterhin in den Pilottest.

Kitesurf-Beta-Limits: Passen zehn tägliche Aufgaben ins Kontingent?

Zehn Aufgaben pro Tag passen nur dann in das Kontingent, wenn jede vollständige Aufgabe im Durchschnitt höchstens 60 Browser-Sekunden benötigt. Im Workers-Free-Kontingent sind 10 Minuten enthalten, also 600 Browser-Sekunden. Auf 10 Aufgaben verteilt ergibt das höchstens 60 Sekunden pro Aufgabe.

Die passende Formel lautet daily task ceiling = floor(600 / measured browser seconds per task). Statt der Gesamtlaufzeit aus einem Anwendungsprotokoll muss die tatsächliche Browser-Zeit verwendet werden. Bei Quick Actions liefert Cloudflare diese laut Preisdokumentation im Antwort-Header X-Browser-Ms-Used. Gemessen werden sollte genau die Aufgabe auf genau den Zielseiten, die später tatsächlich zum Einsatz kommen.

Die Zeit ist nicht das einzige Limit. Laut Limitübersicht kann ein Free-Konto drei Browser Sessions gleichzeitig ausführen, alle 20 Sekunden eine neue Sitzung starten und alle 10 Sekunden eine Quick-Actions-Anfrage senden. Das voreingestellte Inaktivitäts-Timeout beträgt 60 Sekunden. Cloudflare erlaubt in unterstützten Sitzungsintegrationen ein längeres keep_alive-Fenster; laut WebMCP-Seite akzeptiert Kitesurf jedoch kein keep_alive in der Chrome-DevTools-MCP-Konfiguration.

Die gleiche Limitübersicht nennt für /crawl eine weitere Free-Grenze: fünf Crawl-Aufträge pro Tag und höchstens 100 Seiten pro Crawl. Ein Recherche-Agent, der aus einer Frage mehrere Crawls erzeugt, kann das Auftragslimit daher lange vor den 10 Browser-Minuten ausschöpfen.

Auch sauberes Schließen wirkt sich auf die Kapazität aus. Cloudflare weist darauf hin, dass eine offen gelassene Sitzung bis zum Timeout weiter Browser-Zeit verbraucht. Ein explizites Schließen protokolliert NormalClosure, ein Inaktivitäts-Timeout dagegen BrowserIdle. Deshalb gehört browser.close() in einen finally-Block; anschließend sollte der Schließgrund geprüft werden, statt stillschweigend von einer erfolgreichen Bereinigung auszugehen.

Die Entscheidungsregel ist eindeutig: Bleibt der gemessene Median bei höchstens 60 Sekunden und führen die Ratenlimits zu keiner Warteschlange, passt ein Pilottest mit 10 Aufgaben ins Kontingent. Andernfalls sollten zunächst die Seitenauswahl oder der Aufgabenumfang reduziert werden, bevor Geld in die Skalierung einer ineffizienten Schleife fließt.

Cloudflare Kitesurf Preise: Drei getrennte Kostengrenzen

Es gibt nicht den einen Preis, denn Kitesurf, das Workers-Konto, die Browser-Run-Nutzung und das Reasoning-Modell sind unterschiedliche Dienste. Wer alles als einen „kostenlosen Agenten“ verbucht, übersieht, welche Position zuerst Kosten verursacht.

Der reine Browser-Aufpreis für eine kurze Aufgabe ist derzeit gering. Nach den 10 in Workers Paid enthaltenen Stunden kostet eine 60-Sekunden-Aufgabe gemäß dem veröffentlichten Browser-Run-Tarif bei $0.09 pro Stunde $0.0015 – noch ohne parallele Sitzungen, Workers-Rechenleistung, Modellnutzung oder Gebühren eines angebundenen SaaS-Dienstes. Die enthaltenen 10 Stunden reichen entsprechend für 600 Browser-Aufgaben von jeweils einer Minute, wenn die Aufgaben gleichmäßig dimensioniert sind.

Aus dieser Rechnung lässt sich kein Preisversprechen für Kitesurf nach der Beta ableiten. Cloudflare hat weder im Update noch in der Kitesurf-Dokumentation, auf der Browser-Run-Preisseite oder auf der Workers-Preisseite einen eigenen Kitesurf-Tarif für die Zeit nach der Beta veröffentlicht. Der Mindestpreis von $5 für Workers Paid gilt für die Kontostufe und schreibt keinen künftigen Kitesurf-Preis fest.

Ein belastbares Käuferbudget führt Browser-Zeit, Sitzungsparallelität, Workers, das Modell und jedes kostenpflichtige System, auf das der Agent zugreift, separat auf. Auch eine kostenlose Browser-Engine kann Teil eines kostenpflichtigen Workflows sein.

Kitesurf Browser Run: Folgen für Entwicklung, Betrieb und Einkauf

Die Plattform eignet sich für klar eingegrenzte zustandslose Aufgaben, nicht als universeller Ersatz für Chromium. Was das konkret bedeutet, hängt von der jeweiligen Rolle ab.

Entwicklung: Die kleinste passende Schnittstelle wählen

Wenn lediglich ein Screenshot, Seiteninhalt, PDF oder eine strukturierte Extraktion benötigt wird, sollte zunächst eine Quick Action zum Einsatz kommen. Dafür wird dem Endpunkt browser=kitesurf hinzugefügt, die zurückgegebene Browser-Zeit gemessen und nur dann zu einer vollständigen Sitzung gewechselt, wenn Navigation oder Zustand über mehrere Aktionen hinweg erforderlich sind.

WebMCP ist attraktiv, wenn eine kompatible Website genau die benötigte Aktion bereitstellt. Eine benannte Funktion ersetzt dann eine fehleranfällige visuelle Schleife. Trotzdem müssen Implementierung, Berechtigungsgrenze und Ergebnis der Website validiert werden.

Geht eine Sitzung mit Kundenbezug in Richtung Produktivbetrieb, sollte die Engine-Auswahl mit den Kontrollen von Browser Run kombiniert werden. Der bestehende Leitfaden zu freigegebenen Hosts und schreibgeschützter Kundenprüfung behandelt die Zielgrenze, die sich allein durch die Wahl des Browsers nicht absichern lässt.

Betrieb: Erfolgreiche und fehlgeschlagene Arbeit getrennt messen

Für jede Aufgabenklasse sollten Browser-Millisekunden, Schließgrund, Anfrageergebnis und Modellnutzung protokolliert werden. Eine erfolgreiche Extraktion und eine Seite mit Timeout sind nicht dieselbe Arbeitslast. Wer beides mittelt, verdeckt, ob der Browser, die Website oder die Agentenschleife korrigiert werden muss.

Bei fehlgeschlagenen Aufträgen sollten die Belege gesichert werden, bevor ein weiterer Lauf startet. Der Inspektionsworkflow von Cloudflare Browser Run kann Konsole, Netzwerk und letzten Seitenzustand nach einer aufgezeichneten Sitzung sichtbar machen. Der Leitfaden zur Fehleranalyse vor einem erneuten Lauf zeigt, wann diese Belege wertvoller sind als ein sofortiger Neustart.

Einkauf: Kapazität erst nach dem Kompatibilitätstest buchen

Ein Upgrade ist nicht allein deshalb sinnvoll, weil der Free-Zähler ausgeschöpft ist. Zuerst muss feststehen, dass Kitesurf die Zielseiten korrekt rendert und die Aufgabe richtig abschließt. Erst danach lässt sich beurteilen, ob die tägliche Browser-Zeit, das Anfragetempo, die Parallelität oder das Modell zum Engpass wird.

Die aktuelle Produktdokumentation von Cloudflare beschreibt die Aufgabenteilung der Engines: Kitesurf eignet sich für kompatibles einmaliges Rendering, Extraktionen und stoßweise anfallende zustandslose Agentenaufgaben. Chromium bleibt die Wahl, wenn ein Workflow Video, WebGL, einen Bot-Challenge-Handshake mit echten TLS-Fingerprints oder eine lang laufende authentifizierte Sitzung mit dauerhaftem Zustand benötigt.

Die Entscheidung lässt sich vor einem breiten Rollout treffen: eine repräsentative Aufgabe, eine Gruppe von Zielseiten, eine gemessene Verteilung der Browser-Zeit und ein klarer Fallback. Wird der Fallback häufig benötigt, senkt die kleinere Engine die Betriebskosten nicht.

Wer jetzt handeln sollte, wer warten sollte und für wen sich nichts ändert

Jetzt handeln sollten Verantwortliche für Support-, Recherche- oder QA-Workflows, die mit öffentlichen oder risikoarmen Seiten arbeiten. Geeignete Piloten sind etwa ein Screenshot aus einem Hilfe-Center, die Extraktion einer Release Note, die Prüfung einer gerenderten Komponente oder der Aufruf eines WebMCP-Suchtools auf einer kompatiblen Website. Solche Aufgaben sind kurz, prüfbar und lassen sich einfach mit einem bekannten Ergebnis vergleichen.

Warten sollten Teams, deren Workflow einen dauerhaften Login-Zustand, Video, WebGL, Kompatibilität mit Bot-Challenges oder die unbeaufsichtigte Bestätigung sensibler WebMCP-Aktionen voraussetzt. Kitesurf-Sitzungen erscheinen nicht in wrangler browser list und bieten keine Live-Ansicht. Laut Cloudflare kann eine Kitesurf-Agentensitzung deshalb kein Tool abschließen, das für eine menschliche Bestätigung pausiert; für diese Interaktion ist der manuelle Playground erforderlich.

Auch mit einer langfristigen Budgetzusage über die Beta hinaus sollte gewartet werden. Der Browser ist derzeit kostenlos, doch es gibt keinen veröffentlichten Kitesurf-Preis für die Zeit nach der Beta, der sich in einen langen Vertrag oder ein Kundenangebot mit fester Marge übernehmen ließe.

Weitgehend unverändert bleibt die Lage für alle, deren stabiler Chromium-Browser-Run-Workflow seine Kosten- und Zuverlässigkeitsziele bereits erfüllt. Das September-Release stellt ein weiteres Backend zur Prüfung bereit, erzwingt aber keine Migration eines funktionierenden Produktiv-Browsers.

Was am kostenlosen Beta-Angebot übertrieben wird

Der Begriff „kostenlos“ wird überdehnt, sobald er den gesamten Agenten beschreiben soll. Er gilt für die Verfügbarkeit von Kitesurf während der Beta, nicht für das Modell, die Arbeitszeit im Betrieb, das Ziel-SaaS oder einen künftigen kommerziellen Preis.

Auch WebMCP beseitigt Browser-Fehler nicht. Cloudflare dokumentiert vier wesentliche Lücken der aktuellen Kitesurf-Implementierung: keine Berechtigungsrichtlinie oder Herkunftsfilterung für WebMCP-Tools, keine über CDP verfügbaren Tools aus Iframes oder Pop-ups, keine Live-Ansicht für Kitesurf-Sitzungen und keine agentenseitige Bestätigung für Tools, die eine Person erfordern. Eine benannte Funktion ist nur dann zuverlässiger als das Klicken auf Pixel, wenn die Seite die richtige Funktion bereitstellt und angemessen absichert.

Der Terminal-Renderer verbessert die Sichtbarkeit, ist aber keine Bereitstellungsstrategie. Er hilft bei der Prüfung dessen, was Kitesurf sieht, ändert jedoch weder Browser-Minuten noch Parallelität, Modellkosten oder Website-Kompatibilität.

Auch die Leistungswerte verlangen Zurückhaltung. In Cloudflares eigenem Median-Benchmark über fünf Quick-Action-Läufe mit einem Korpus aus 14 URLs benötigte Kitesurf für einen Screenshot 380 ms CPU-Zeit gegenüber 1,173 ms bei Chromium aus dem Warm-Pool sowie 57.8 MiB Arbeitsspeicher gegenüber 271.0 MiB. Bei der Gesamtlaufzeit war Kitesurf dagegen langsamer: 1,148 ms gegenüber 637 ms. Der geringere Ressourcenbedarf ist für Skalierung wertvoll, bedeutet aber nicht, dass jede einzelne Anfrage schneller fertig wird.

Mehr als 730,000 bestandene Untertests belegen schließlich einen schnellen Fortschritt, nicht die vollständige Gleichwertigkeit mit dem gesamten Web. Eine Kompatibilitätsmatrix der eigenen Zielseiten ist weiterhin aussagekräftiger als eine globale Testzahl.

Der nächste Schritt am Montag: Ein klar begrenzter Pilottest

Als Nächstes steht ein kontrollierter Kontotest an, keine Architektur-Migration. Für diesen Beitrag wurde keine authentifizierte Browser-Run-Anfrage ausgeführt. Die folgende Abfolge ist daher ein reproduzierbarer Pilottest und kein angeblich selbst gemessener Benchmark.

1. 1

   Öffentliche Oberfläche prüfen

   Den Kitesurf Playground auf Cloudflare Radar öffnen. In DevTools unter Application > WebMCP die Tools erfassen, die Radar laut Cloudflare bereitstellt, darunter navigate-to und set-location. Deren Vorhandensein ist kein Beleg dafür, dass eine eigene Zielseite gleichwertige Tools anbietet.

2. 2

   Eine repräsentative Aufgabe ausführen

   Mit einem vorhandenen Testkonto genau eine Inhalts- oder Screenshot-Anfrage ausführen. Cloudflares dokumentierte Form einer Screenshot-Anfrage lautet:

   curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/screenshot?browser=kitesurf' \
     -H 'Authorization: Bearer <API_TOKEN>' \
     -H 'Content-Type: application/json' \
     -d '{"url":"https://example.com"}' \
     --output screenshot.png

   Zunächst ein nicht sensibles Ziel verwenden. Vor jeder Geschwindigkeitsoptimierung prüfen, ob die Ausgabe korrekt ist.

3. 3

   Jede Kostengrenze erfassen

   Workers-Tarif, X-Browser-Ms-Used einer Quick Action, Browser-Run-Nutzung, Schließgrund der Sitzung und Modellnutzung erfassen. Eine Browser Session ausdrücklich schließen und NormalClosure statt BrowserIdle bestätigen.

4. 4

   Kontingent berechnen

   600 durch die gemessenen Browser-Sekunden pro erfolgreicher Aufgabe teilen und abrunden. Für 10 Aufgaben pro Tag darf der gemessene Durchschnitt höchstens 60 Sekunden betragen. Die Modellrechnung in einer separaten Spalte führen und anschließend entscheiden, ob der Pilottest in Free passt, eine enger zugeschnittene Aufgabe braucht oder Workers Paid rechtfertigt.

Dieser eine Lauf liefert die fehlenden Belege: Kompatibilität, Browser-Zeit, Schließverhalten und Modellkosten für eine Aufgabe, die das Unternehmen tatsächlich wiederholen würde.

Wer die nächste Preis- oder Limitänderung bei Agenten-Infrastruktur in eine konkrete Betriebsentscheidung übersetzt erhalten möchte, kann den Newsletter abonnieren.