Is Kitesurf Free

Is Kitesurf free? Yes, while it is in beta, but the useful allowance on Workers Free is capped at 10 browser minutes per account per day, three concurrent Browser Sessions, and one new session every 20 seconds. That is enough for a measured pilot, not proof that your complete agent stack costs nothing.

Is Kitesurf Free?

Kitesurf is free while the browser is in beta. Cloudflare says that directly in its September 28, 2026 update, with an equally important qualifier: access sits behind per-account Browser Run limits.

Kitesurf is Cloudflare's stateless browser engine for AI agents. It runs on Workers and trades human-browser features for a smaller agent-oriented runtime. There is no separate Kitesurf engine charge today, but Browser Run is still the meter around it.

The current Browser Run limits and Browser Run pricing create four boundaries worth putting beside each other:

Free is therefore a useful product answer and an incomplete budget answer. It tells you what Cloudflare charges for Kitesurf during beta. It does not tell you whether your workflow fits the account caps, whether you need Workers Paid, or what your agent's model will cost.

Pricing and limits in this guide were verified against Cloudflare's live public pages on September 29, 2026. No authenticated Browser Run job was available for this review, so there is no invented dashboard bill, elapsed-time result, or tool-call success rate here.

What Actually Changed on September 28, 2026

The September update made Kitesurf credible for a wider pilot because it connected the engine to the interfaces agent builders already use. The original August launch introduced the browser. This update added the practical surfaces around it.

First, Kitesurf now supports WebMCP, a browser API through which a website exposes named tools with structured inputs. An agent can call a site's searchFlights()-style function instead of inferring buttons from pixels. Cloudflare's WebMCP documentation says Kitesurf can list and execute those tools through Chrome DevTools Protocol, usually shortened to CDP.

Second, Kitesurf now has full Browser Run API coverage. It can be selected through CDP, Playwright, Puppeteer, or MCP. Quick Actions, Cloudflare's one-request interfaces for screenshots, HTML, PDFs, and other common outputs, can also select Kitesurf from a Worker through env.BROWSER.quickAction().

Third, the renderer can run in compatible terminals through the Kitty graphics protocol, with a pure ANSI text mode when Kitty is unavailable. That is useful for seeing the page from the agent browser's point of view without opening a separate desktop browser. It is an inspection convenience, not a new production billing tier.

Cloudflare also reports in the September update that Kitesurf now passes more than 730,000 Web Platform Test subtests, over 500,000 more than at launch. That is a meaningful compatibility increase. It is not a guarantee that an arbitrary customer portal will render correctly, which is why a bounded site list still belongs in the pilot.

Kitesurf Beta Limits: Can Ten Daily Tasks Fit?

Ten daily tasks fit only if each complete task averages 60 browser seconds or less. The Workers Free allowance is 10 minutes, which is 600 browser seconds. Divide that budget by 10 tasks and the threshold is 60 seconds per task.

The useful formula is daily task ceiling = floor(600 / measured browser seconds per task). Do not substitute wall-clock time from an application log. For Quick Actions, Cloudflare returns the browser time in the X-Browser-Ms-Used response header, according to its pricing documentation. Record that value for the same task and target sites you intend to operate.

Time is not the only limit. The limits page says a Free account can run three Browser Sessions concurrently, start one new session every 20 seconds, and make one Quick Actions request every 10 seconds. The default inactivity timeout is 60 seconds. Cloudflare allows a longer keep_alive window in supported session integrations, but its WebMCP page says Kitesurf does not accept keep_alive in the Chrome DevTools MCP configuration.

The same limits page gives /crawl another Free boundary: five crawl jobs per day and no more than 100 pages per crawl. A research agent that turns one question into several crawls can exhaust the job count long before it uses all 10 browser minutes.

Closure discipline also changes capacity. Cloudflare warns that a session left open continues consuming browser time until it times out. An explicit close records NormalClosure; an idle timeout records BrowserIdle. Put browser.close() in a finally block, then inspect the close reason rather than assuming the code cleaned up.

The decision rule is blunt: if the measured median stays at or below 60 seconds and the rate limits do not queue the work, a 10-task pilot fits. If it does not, reduce the page set or task scope before paying to scale an inefficient loop.

Cloudflare Kitesurf Pricing Has Three Cost Boundaries

The price is not one number because Kitesurf, the Workers account, Browser Run usage, and the reasoning model are different services. Treating them as one "free agent" line hides the first bill that will move.

The current raw browser overage is small for a short task. Under the published Browser Run rate, after the 10 included Workers Paid hours, one 60-second task costs $0.0015 at $0.09 per hour, before concurrency, Workers compute, model usage, or an upstream SaaS charge. The same included 10 hours hold 600 one-minute browser tasks if the work is evenly sized.

That arithmetic should not be turned into a promise about Kitesurf after beta. Cloudflare has not published a Kitesurf-specific post-beta rate on the update, Kitesurf docs, Browser Run pricing page, or Workers pricing page. The $5 Workers Paid minimum buys the Workers account tier. It does not lock in a future Kitesurf price.

For a buyer, the clean budget has separate rows for browser time, session concurrency, Workers, the model, and any paid system the agent touches. A free browser engine can still sit inside a paid workflow.

Kitesurf Browser Run: What It Means for Builders, Operators, and Buyers

The platform is ready for bounded stateless work, not as a universal Chromium replacement. The consequence changes by role.

Builders: Use the Smallest Interface That Finishes the Job

Builders should begin with a Quick Action when the output is a screenshot, page content, PDF, or structured extraction. Add browser=kitesurf to the endpoint, measure the returned browser time, and move to a full session only when the job needs navigation or state across several actions.

WebMCP is attractive when a compatible site exposes the exact action your agent needs. It replaces a fragile visual loop with a named tool. It does not remove the need to validate the site's implementation, permission boundary, and result.

When a client-facing session moves toward production, pair the engine choice with Browser Run controls. The existing guide to approved hosts and read-only client review covers the destination boundary that a browser choice alone does not provide.

Operators: Measure Normal Work and Failure Work Separately

Operators should record browser milliseconds, close reason, request result, and model usage for each task class. A successful extraction and a timed-out page are not the same workload. Averaging them together conceals whether the browser, the site, or the agent loop needs the fix.

For failed jobs, preserve the evidence before launching another run. Cloudflare's Browser Run inspection workflow can expose console, network, and final page state after a recorded session. The failed-job debugging guide explains when that evidence is more valuable than an immediate rerun.

Buyers: Buy Capacity Only After Compatibility

Buyers should not upgrade merely because the Free counter was reached. First confirm that Kitesurf renders the target sites and completes the task correctly. Then decide whether the bottleneck is daily browser time, request rate, concurrency, or the model.

Cloudflare's current product documentation gives the engine split. Choose Kitesurf for compatible one-shot rendering, extraction, and bursty stateless agent work. Choose Chromium when the workflow needs video, WebGL, a bot-challenge handshake with real TLS fingerprints, or a long-running authenticated session with persistent state.

The decision can be made before a broad rollout: one representative task, one target-site set, one measured browser-time distribution, and one explicit fallback. If the fallback fires frequently, the smaller engine is not saving operational cost.

Who Should Act Now, Who Should Wait, and Who Is Unaffected

Act now if you own a support, research, or QA workflow built around public or low-risk pages. Good pilots include capturing a help-center screenshot, extracting a release note, checking a rendered component, or calling a WebMCP search tool on a compatible site. These tasks are short, auditable, and easy to compare with a known result.

Wait if the workflow depends on persistent login state, video, WebGL, bot-challenge compatibility, or unattended confirmation of sensitive WebMCP actions. Kitesurf sessions do not appear in wrangler browser list and have no live view. Cloudflare says a Kitesurf agent session therefore cannot complete a tool that pauses for human confirmation; the manual playground is required for that interaction.

Also wait on a budget commitment that extends beyond beta. The current browser is free, but there is no published post-beta Kitesurf price to place in a long contract or a fixed-margin client quote.

You are largely unaffected if a stable Chromium Browser Run workflow already meets its cost and reliability target. The September release gives you another backend to evaluate. It does not make a working production browser migration mandatory.

What's Overhyped About the Free Beta

The word "free" is doing too much work when it is used to describe the whole agent. It covers Kitesurf's beta availability, not the model, operator time, target SaaS, or a future commercial price.

WebMCP also does not eliminate browser failure. Cloudflare documents four material gaps in Kitesurf's current implementation: no WebMCP tools permission policy or origin filtering, no iframe or popup tools exposed through CDP, no live view for Kitesurf sessions, and no agent-side confirmation for tools that require a person. A named function is more reliable than pixel clicking only when the page exposes and secures the right function.

The terminal renderer is useful visibility, not a deployment strategy. It helps a builder inspect what Kitesurf sees. It does not change browser minutes, concurrency, model cost, or site compatibility.

The performance story needs the same restraint. In Cloudflare's own median benchmark across five Quick Action runs on a 14-URL corpus, Kitesurf used 380 ms of CPU for a screenshot versus 1,173 ms for warm-pool Chromium, and 57.8 MiB of memory versus 271.0 MiB. It was also slower in wall time: 1,148 ms versus 637 ms. Lower resource use is valuable for scale, but it does not mean every single request finishes faster.

Finally, more than 730,000 passing subtests is evidence of fast progress, not evidence of full-web parity. A compatibility matrix built from your target sites is still worth more than a global test count.

The Monday Move: Run One Bounded Pilot

The right next step is a controlled account test, not an architecture migration. This page did not execute an authenticated Browser Run request, so the sequence below is a reproducible pilot rather than a claimed first-hand benchmark.

1. 1

   Inspect the public surface

   Open the Kitesurf playground on Cloudflare Radar. In DevTools, open Application > WebMCP and record the tools Cloudflare says Radar exposes, including navigate-to and set-location. Do not treat their presence as proof that your target site exposes equivalent tools.

2. 2

   Run one representative task

   Use an existing test account for one content or screenshot request. Cloudflare's documented screenshot shape is:

   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

   Use a non-sensitive target first. Record whether the output is correct before optimizing for speed.

3. 3

   Record every cost boundary

   Capture the Workers plan, X-Browser-Ms-Used for a Quick Action, Browser Run usage, session close reason, and model usage. For a Browser Session, close it explicitly and confirm NormalClosure rather than BrowserIdle.

4. 4

   Calculate the allowance

   Divide 600 by the measured browser seconds per successful task and round down. A 10-task day requires a measured average of 60 seconds or less. Keep the model bill in a separate column, then decide whether the pilot fits Free, needs a tighter task, or justifies Workers Paid.

That one run gives you the missing evidence: compatibility, browser time, close behavior, and model cost for a task your business would genuinely repeat.

If you want the next agent-infrastructure price or limit change translated into a concrete operating decision, join the newsletter.