Kitesurf gratis: limiti reali, prezzi e casi d’uso

Kitesurf gratis? Sì, finché resta in beta. Ma con Workers Free la quota effettivamente utilizzabile è limitata a 10 minuti di browser al giorno per account, tre Browser Sessions simultanee e una nuova sessione ogni 20 secondi. Basta per un progetto pilota ben delimitato, non per concludere che l'intero stack dell'agente non costi nulla.

Kitesurf gratis: lo è davvero?

Kitesurf è gratuito finché il browser resta in beta. Cloudflare lo dichiara nel suo aggiornamento del 28 settembre 2026, aggiungendo però una precisazione decisiva: l'accesso è soggetto ai limiti per account di Browser Run.

Kitesurf è il motore browser stateless di Cloudflare per gli agenti AI. Funziona su Workers e sacrifica le funzioni pensate per l'uso umano a favore di un runtime più leggero, progettato per gli agenti. Al momento il motore Kitesurf non ha un costo separato, ma Browser Run resta il contatore che ne misura l'utilizzo.

Gli attuali limiti di Browser Run e i prezzi di Browser Run definiscono quattro soglie che conviene confrontare direttamente:

«Gratis», quindi, descrive bene il prodotto ma non basta per fare un budget. Dice quanto Cloudflare addebita per Kitesurf durante la beta; non dice se il workflow rientra nei limiti dell'account, se serve Workers Paid o quanto costerà il modello usato dall'agente.

Prezzi e limiti riportati in questa guida sono stati verificati sulle pagine pubbliche live di Cloudflare il 29 settembre 2026. Per questa recensione non era disponibile un job Browser Run autenticato: non compaiono quindi importi inventati da una dashboard, risultati fittizi sui tempi di esecuzione o percentuali di successo delle chiamate prive di riscontro.

Che cosa è cambiato davvero il 28 settembre 2026

L'aggiornamento di settembre ha reso Kitesurf una scelta più credibile per un numero maggiore di progetti pilota, collegando il motore alle interfacce già usate da chi sviluppa agenti. Il lancio originale di agosto aveva introdotto il browser; questo aggiornamento ha aggiunto gli strumenti pratici che gli ruotano attorno.

Per prima cosa, Kitesurf ora supporta WebMCP, un'API browser con cui un sito espone tool identificati per nome e input strutturati. Un agente può richiamare una funzione come searchFlights() anziché ricostruire i pulsanti a partire dai pixel. La documentazione WebMCP di Cloudflare spiega che Kitesurf può elencare ed eseguire questi tool tramite Chrome DevTools Protocol, di solito abbreviato in CDP.

In secondo luogo, Kitesurf ora offre la copertura completa delle API di Browser Run. Si può selezionare tramite CDP, Playwright, Puppeteer o MCP. Anche Quick Actions, le interfacce Cloudflare a richiesta singola per screenshot, HTML, PDF e altri output comuni, possono selezionare Kitesurf da un Worker tramite env.BROWSER.quickAction().

Infine, il renderer può funzionare nei terminali compatibili tramite il protocollo grafico Kitty, passando a una modalità testuale ANSI pura quando Kitty non è disponibile. È un modo pratico per vedere una pagina dalla prospettiva del browser dell'agente senza aprire un browser desktop separato. Si tratta di uno strumento di ispezione, non di un nuovo livello tariffario per la produzione.

Nell'aggiornamento di settembre, Cloudflare segnala inoltre che Kitesurf supera ora più di 730,000 sottotest dei Web Platform Test, oltre 500,000 in più rispetto al lancio. È un progresso significativo sul fronte della compatibilità, ma non garantisce che un qualsiasi portale clienti venga renderizzato correttamente. Per questo un elenco circoscritto di siti deve continuare a far parte del progetto pilota.

Limiti della beta di Kitesurf: bastano per dieci attività al giorno?

Dieci attività al giorno rientrano nel piano solo se ogni attività completa richiede in media 60 secondi di browser o meno. La quota di Workers Free è di 10 minuti, cioè 600 secondi di browser. Dividendo il budget per 10 attività, la soglia è di 60 secondi per attività.

La formula utile è daily task ceiling = floor(600 / measured browser seconds per task). Non sostituite questo dato con il tempo trascorso riportato nel log di un'applicazione. Per Quick Actions, Cloudflare restituisce il tempo del browser nell'header di risposta X-Browser-Ms-Used, come specifica la sua documentazione dei prezzi. Registrate quel valore usando la stessa attività e gli stessi siti di destinazione previsti in produzione.

Il tempo non è l'unico vincolo. La pagina dei limiti indica che un account Free può eseguire tre Browser Sessions simultanee, avviare una nuova sessione ogni 20 secondi ed effettuare una richiesta Quick Actions ogni 10 secondi. Il timeout predefinito per inattività è di 60 secondi. Cloudflare consente una finestra keep_alive più lunga nelle integrazioni di sessione supportate, ma la pagina WebMCP specifica che Kitesurf non accetta keep_alive nella configurazione MCP di Chrome DevTools.

La stessa pagina dei limiti assegna a /crawl un altro vincolo nel piano Free: cinque job di crawl al giorno e non più di 100 pagine per crawl. Un agente di ricerca che trasforma una domanda in più crawl può esaurire il numero di job molto prima di consumare tutti i 10 minuti di browser.

Anche la disciplina con cui si chiudono le sessioni incide sulla capacità. Cloudflare avverte che una sessione lasciata aperta continua a consumare tempo del browser fino al timeout. Una chiusura esplicita registra NormalClosure; un timeout per inattività registra BrowserIdle. Inserite browser.close() in un blocco finally, quindi controllate il motivo della chiusura anziché dare per scontato che il codice abbia fatto pulizia.

La regola decisionale è netta: se la mediana misurata resta pari o inferiore a 60 secondi e i rate limit non accodano il lavoro, un progetto pilota da 10 attività rientra nel piano. In caso contrario, riducete l'insieme delle pagine o il perimetro dell'attività prima di pagare per scalare un ciclo inefficiente.

Prezzi di Cloudflare Kitesurf: tre voci di costo da separare

Non esiste un solo prezzo, perché Kitesurf, l'account Workers, l'utilizzo di Browser Run e il modello di reasoning sono servizi distinti. Riunirli sotto un'unica voce «agente gratuito» nasconde il primo costo destinato a crescere.

Per un'attività breve, il costo grezzo dell'eccedenza del browser è contenuto. Alla tariffa pubblicata di Browser Run, dopo le 10 ore incluse in Workers Paid, un'attività da 60 secondi costa $0.0015 a $0.09 all'ora, prima di considerare concorrenza, capacità di calcolo di Workers, uso del modello o un eventuale servizio SaaS esterno. Le stesse 10 ore incluse consentono 600 attività browser da un minuto, se il lavoro è distribuito in modo uniforme.

Questa aritmetica non va trasformata in una promessa sul prezzo di Kitesurf dopo la beta. Cloudflare non ha pubblicato una tariffa Kitesurf specifica per il periodo successivo alla beta nell'aggiornamento, nella documentazione di Kitesurf, nella pagina dei prezzi di Browser Run né nella pagina dei prezzi di Workers. Il minimo di $5 per Workers Paid copre il livello di account Workers, non blocca un futuro prezzo di Kitesurf.

Per chi acquista, il budget più chiaro assegna righe separate al tempo del browser, alla concorrenza delle sessioni, a Workers, al modello e a ogni sistema a pagamento toccato dall'agente. Anche un motore browser gratuito può far parte di un workflow a pagamento.

Cloudflare Kitesurf e Browser Run: che cosa cambia per sviluppatori, operatori e buyer

La piattaforma è pronta per attività stateless ben delimitate, non per sostituire Chromium in ogni scenario. Le conseguenze cambiano a seconda del ruolo.

Sviluppatori: scegliete l'interfaccia più semplice che completa il lavoro

Quando l'output è uno screenshot, il contenuto di una pagina, un PDF o un'estrazione strutturata, conviene partire da una Quick Action. Aggiungete browser=kitesurf all'endpoint, misurate il tempo del browser restituito e passate a una sessione completa solo se il job richiede navigazione o stato tra più azioni.

WebMCP è interessante quando un sito compatibile espone esattamente l'azione necessaria all'agente. Sostituisce un fragile ciclo visuale con un tool dotato di nome, ma non elimina la necessità di verificare implementazione, confini delle autorizzazioni e risultato del sito.

Quando una sessione destinata a un cliente si avvicina alla produzione, alla scelta del motore vanno affiancati i controlli di Browser Run. La guida esistente su host approvati e revisione client in sola lettura copre il confine delle destinazioni che la sola scelta del browser non può garantire.

Operatori: misurate separatamente il lavoro riuscito e quello fallito

Per ogni classe di attività, gli operatori dovrebbero registrare millisecondi del browser, motivo della chiusura, esito della richiesta e utilizzo del modello. Un'estrazione riuscita e una pagina andata in timeout non rappresentano lo stesso carico di lavoro. Fare la media insieme nasconde se il problema da correggere si trovi nel browser, nel sito o nel ciclo dell'agente.

Per i job falliti, conservate le prove prima di avviare un'altra esecuzione. Il workflow di ispezione di Browser Run può mostrare console, rete e stato finale della pagina dopo una sessione registrata. La guida al debug di un job fallito prima di rieseguirlo spiega quando queste informazioni valgono più di un nuovo tentativo immediato.

Buyer: acquistate capacità solo dopo aver verificato la compatibilità

Non ha senso passare a un piano superiore soltanto perché il contatore Free è arrivato al limite. Prima verificate che Kitesurf renderizzi i siti target e completi correttamente l'attività. Solo allora stabilite se il collo di bottiglia è il tempo giornaliero del browser, la frequenza delle richieste, la concorrenza o il modello.

L'attuale documentazione di prodotto Cloudflare chiarisce la distinzione tra i motori. Scegliete Kitesurf per rendering, estrazione e carichi agentici stateless compatibili, anche quando arrivano a raffiche. Scegliete Chromium quando il workflow richiede video, WebGL, un handshake anti-bot con fingerprint TLS reali oppure una sessione autenticata di lunga durata con stato persistente.

La decisione si può prendere prima di un rollout esteso: un'attività rappresentativa, un insieme di siti target, una distribuzione misurata dei tempi del browser e un fallback esplicito. Se il fallback scatta spesso, il motore più piccolo non sta riducendo i costi operativi.

Chi dovrebbe agire ora, chi dovrebbe aspettare e chi non è coinvolto

Agite ora se gestite un workflow di supporto, ricerca o QA basato su pagine pubbliche o a basso rischio. Tra i progetti pilota adatti rientrano l'acquisizione di uno screenshot di un centro assistenza, l'estrazione di una nota di rilascio, la verifica di un componente renderizzato o la chiamata a un tool di ricerca WebMCP su un sito compatibile. Sono attività brevi, verificabili e facili da confrontare con un risultato noto.

Aspettate se il workflow dipende da uno stato di login persistente, video, WebGL, compatibilità con challenge anti-bot o conferma senza supervisione di azioni WebMCP sensibili. Le sessioni Kitesurf non appaiono in wrangler browser list e non hanno una live view. Per questo, spiega Cloudflare, una sessione agentica Kitesurf non può completare un tool che si mette in pausa per chiedere una conferma umana; per quell'interazione serve il playground manuale.

Conviene aspettare anche prima di assumere un impegno di spesa che vada oltre la beta. Il browser attuale è gratuito, ma non esiste un prezzo Kitesurf pubblicato per il periodo successivo da inserire in un contratto lungo o in un preventivo a margine fisso per un cliente.

Per voi cambia poco se un workflow stabile su Chromium Browser Run soddisfa già gli obiettivi di costo e affidabilità. La release di settembre offre un backend in più da valutare; non rende obbligatoria la migrazione di un browser di produzione che funziona.

Che cosa viene sopravvalutato nella beta gratuita

La parola «gratis» viene caricata di troppi significati quando la si usa per descrivere l'intero agente. Riguarda la disponibilità di Kitesurf durante la beta, non il modello, il tempo dell'operatore, il SaaS di destinazione o un futuro prezzo commerciale.

Nemmeno WebMCP elimina i possibili errori del browser. Cloudflare documenta quattro lacune rilevanti nell'attuale implementazione di Kitesurf: nessuna policy di autorizzazione o filtro per origine sui tool WebMCP, nessun tool di iframe o popup esposto tramite CDP, nessuna live view per le sessioni Kitesurf e nessuna conferma lato agente per i tool che richiedono una persona. Una funzione nominata è più affidabile di un clic sui pixel solo quando la pagina espone e protegge la funzione corretta.

Il renderer da terminale migliora la visibilità, ma non è una strategia di deployment. Aiuta chi sviluppa a controllare che cosa vede Kitesurf; non cambia minuti di browser, concorrenza, costo del modello o compatibilità dei siti.

Anche i dati sulle prestazioni vanno letti con cautela. Nel benchmark mediano di Cloudflare, eseguito su cinque run di Quick Action con un corpus di 14 URL, Kitesurf ha consumato 380 ms di CPU per uno screenshot contro 1,173 ms di Chromium in warm pool, e 57.8 MiB di memoria contro 271.0 MiB. È risultato però più lento nel tempo totale: 1,148 ms contro 637 ms. Consumare meno risorse è utile su larga scala, ma non significa che ogni singola richiesta termini più rapidamente.

Infine, superare più di 730,000 sottotest dimostra la rapidità dei progressi, non la parità con l'intero web. Una matrice di compatibilità costruita sui propri siti target vale ancora più di un conteggio globale di test.

La mossa per lunedì: un solo progetto pilota circoscritto

Il passo successivo corretto è un test controllato sull'account, non una migrazione dell'architettura. Questa pagina non ha eseguito una richiesta Browser Run autenticata, quindi la sequenza che segue è un progetto pilota riproducibile, non un benchmark spacciato per esperienza diretta.

1. 1

   Esaminate la superficie pubblica

   Aprite il playground di Kitesurf su Cloudflare Radar. In DevTools, aprite Application > WebMCP e annotate i tool che Cloudflare dichiara esposti da Radar, tra cui navigate-to e set-location. La loro presenza non dimostra che il vostro sito target esponga tool equivalenti.

2. 2

   Eseguite un'attività rappresentativa

   Usate un account di test esistente per una singola richiesta di contenuto o screenshot. La forma documentata da Cloudflare per uno screenshot è:

   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

   Partite da una destinazione non sensibile. Verificate che l'output sia corretto prima di ottimizzare la velocità.

3. 3

   Registrate ogni voce di costo

   Raccogliete il piano Workers, X-Browser-Ms-Used per una Quick Action, l'utilizzo di Browser Run, il motivo della chiusura della sessione e l'uso del modello. Per una Browser Session, chiudetela esplicitamente e verificate NormalClosure anziché BrowserIdle.

4. 4

   Calcolate la disponibilità

   Dividete 600 per i secondi di browser misurati per ogni attività riuscita e arrotondate per difetto. Una giornata da 10 attività richiede una media misurata pari o inferiore a 60 secondi. Tenete il costo del modello in una colonna separata, quindi decidete se il progetto pilota rientra nel piano Free, richiede un'attività più circoscritta o giustifica Workers Paid.

Questa singola esecuzione fornisce le informazioni mancanti: compatibilità, tempo del browser, comportamento alla chiusura e costo del modello per un'attività che l'azienda ripeterebbe davvero.

Se volete trasformare il prossimo cambiamento di prezzo o di limiti nell'infrastruttura per agenti in una decisione operativa concreta, iscrivetevi alla newsletter.