Cursor AI vs Cloudflare Workers: i 2 limiti ancora aperti

Il 13 maggio, Cursor AI ha introdotto gli ambienti cloud multi-repository per gli agenti. La pagina di prodotto di Cursor afferma che oltre il 30% delle pull request integrate dall'azienda viene ormai creato da agenti autonomi che operano in sandbox cloud.

Cosa ha davvero lanciato Cursor AI il 13 maggio

La novità principale sono gli ambienti cloud multi-repository per gli agenti. Ora un agente può lavorare su più repository all'interno di un unico ambiente configurato, proseguendo il percorso iniziato con i workspace multi-root rilasciati da Cursor il 24 aprile. L'ambiente si riutilizza tra una sessione e l'altra: in concreto, non occorre riconfigurare ogni volta la stessa macchina di sviluppo quando parte un agente.

La configurazione passa da un Dockerfile. I segreti necessari alla build restano circoscritti a quella fase e non vengono trasmessi all'agente in esecuzione. Si elimina così uno degli errori più comuni nell'infrastruttura per agenti: incorporare per sbaglio una chiave API durante la build e ritrovarsela nella memoria di lavoro dell'agente. Cursor può anche configurare il Dockerfile analizzando repository, strumenti e dipendenze. Questo flusso è ancora in private beta per i team Enterprise.

Il salto prestazionale più netto riguarda la cache dei layer. Quando la cache viene riutilizzata, le build sono ora più veloci del 70%, perché vengono ricostruiti soltanto i layer modificati del Dockerfile. Per gli agenti che vengono avviati di continuo in un team, è la differenza tra aspettare e lavorare.

Il versante operativo è quello che i concorrenti continuano a sottovalutare. Ogni ambiente dispone di una cronologia delle versioni con rollback, riservato agli amministratori. Un audit log registra tutte le azioni compiute dai membri del team sugli ambienti. Allowlist per il traffico in uscita e ambiti dei segreti sono definiti per singolo ambiente: un segreto disponibile nell'ambiente A non è accessibile dall'ambiente B. È l'infrastruttura poco appariscente ma indispensabile prima di lasciare che un agente apra pull request sul codice di produzione.

Il caso concreto citato da Cursor nell'annuncio è Amplitude. Le sue Cursor Automations monitorano i canali Slack pubblici, analizzano i problemi segnalati, individuano i repository coinvolti e aprono pull request in quelli corretti. È un agente multi-repository che svolge il primo livello di triage in un'azienda reale e su scala reale. Non è una demo.

Il dato di Cursor sulle pull request integrate è la prova che conta

Cursor dichiara che oltre il 30% delle pull request integrate dall'azienda viene ormai creato da agenti autonomi attivi in sandbox cloud. Il denominatore è decisivo: si parla di pull request integrate, non di tentativi compiuti dagli agenti. È il dato che dimostra come il ciclo possa arrivare fino in fondo — revisione, correzioni e passaggio di consegne — senza che una persona debba inviare ogni commit.

Dal 2 settembre 2026, Self-Hosted Machines di Cursor consente ai team di spostare modifiche ai file, comandi da terminale, strumenti di computer use ed esecuzione locale di MCP su worker gestiti dal cliente, mentre Cursor mantiene nel proprio cloud il ciclo dell'agente, l'inferenza e la pianificazione. In questo modo viene colmato il divario legato al luogo di esecuzione privato, ma Cursor non diventa un runtime durevole programmabile.

La scelta non è più tra uno stato limitato alla sessione e uno stato durevole. Cursor conserva lo stato delle conversazioni nel proprio backend, così le esecuzioni possono essere riaperte e riprese; inoltre, i Self-Hosted Team Pools possono ripristinare un workspace in ibernazione. La distinzione più precisa è tra stato dell'agente gestito dal fornitore e stato dell'applicazione programmabile. Cloudflare espone uno stato SQLite per ogni Agent e step durevoli dei workflow controllabili via codice.

Cosa offre già il mio stack Cloudflare Workers con Agents SDK

Gestisco sei agenti in produzione su Cloudflare. Il runtime è Workers; lo stato risiede nei Durable Objects con SQLite per istanza; l'orchestrazione di lunga durata gira su Cloudflare Workflows. È un progetto individuale, su un unico account, analizzato qui in dettaglio. Ad aprile 2026, l'intero stack Cloudflare è costato $19.14. È una fattura di produzione riferita a un periodo preciso, non un prezzo di listino della piattaforma. Per Enterprise, Cursor indica un prezzo Custom; i Team Pools richiedono Enterprise e Self-Hosted Machines comporta comunque il costo del modello selezionato, oltre alla spesa per i propri worker.

Questo stack si distingue dall'attuale prodotto Cursor in tre modi.

Multi-repository via codice. Un Worker può recuperare risorse tramite HTTP durante l'esecuzione. Browser Run, in precedenza Browser Rendering, può controllare un browser headless quando il contesto si trova dietro un sito web. Cursor confeziona l'accesso multi-repository come configurazione riutilizzabile dell'ambiente; Cloudflare lascia allo sviluppatore il recupero dei dati, l'autenticazione e la logica dei repository. Non è meglio né peggio: cambia l'interfaccia di controllo.

Stato durevole programmabile. Un Cloudflare Agent salva automaticamente lo stato dell'applicazione nel proprio database SQLite e lo ricarica dopo un riavvio o un'ibernazione. Anche Cursor conserva lo stato delle conversazioni e permette di riprendere le esecuzioni. La differenza è nel controllo: Cursor gestisce l'archivio delle conversazioni e il runtime dell'agente, mentre Cloudflare espone al codice lo stato dell'applicazione e il relativo schema.

Step durevoli, non esecuzione exactly-once automatica. In Workflows ogni step può essere ritentato singolarmente e può emettere stato, così l'esecuzione persiste e prosegue dopo un errore di rete o dell'infrastruttura. step.do accetta una configurazione dei tentativi per ogni step, NonRetryableError interrompe i tentativi in caso di errore terminale e gli ID delle istanze sono univoci per ciascun Workflow. Tuttavia, uno step può essere eseguito più di una volta e Cloudflare specifica chiaramente che le chiamate con effetti collaterali devono essere idempotenti. Il vantaggio sta nella durata e nei tentativi definiti dallo sviluppatore, non in una protezione automatica da pull request, email o addebiti duplicati.

I due limiti che Cursor AI non ha ancora superato

Limite 1: stato programmabile dell'agente sotto il controllo del cliente. Cursor ha risolto la ripresa di base: per impostazione predefinita, lo stato delle conversazioni viene conservato a tempo indeterminato, mentre gli snapshot delle VM gestite seguono una finestra mobile di 90 giorni di inattività. Self-Hosted Machines sposta l'esecuzione degli strumenti, ma Cursor continua a gestire il ciclo dell'agente e a conservare la conversazione. Un Cloudflare Agent espone invece lo stato basato su SQLite direttamente nel runtime dell'applicazione. La differenza conta quando un agente monitora incidenti, coordina una migrazione o mantiene lo stato di business durante un onboarding di più giorni.

È un divario più circoscritto rispetto a quello descritto a maggio. Cursor può riprendere le esecuzioni degli agenti all'interno del proprio prodotto. Non espone però una macchina a stati di proprietà del cliente che l'applicazione possa interrogare, estendere e coordinare indipendentemente da una chat di Cursor.

Limite 2: una superficie di step durevoli definita dallo sviluppatore. La documentazione attuale di Cloud Agent e Self-Hosted Machines di Cursor non espone alcuna primitiva applicativa equivalente a uno step di Workflow con stato persistente e configurazione dei tentativi per singolo step. Cloudflare sì. La differenza emerge quando un agente di coding entra nel perimetro di fatturazione, email, deployment o di un altro effetto collaterale esterno.

Spostare le chiamate agli strumenti sulla propria macchina non colma questo divario: cambia il luogo di esecuzione, non il contratto di orchestrazione. Neppure Cloudflare garantisce effetti collaterali exactly-once; uno step soggetto a nuovi tentativi deve comunque essere reso idempotente.

Non è una critica a Cursor, ma una distinzione tra categorie. Cursor è un prodotto per il coding con esecuzione degli strumenti sia gestita sia affidata al cliente. Cloudflare è un runtime applicativo programmabile. Il rilascio di settembre riduce il divario infrastrutturale, ma tra i due resta il confine relativo a stato e orchestrazione.

Cosa dovrebbero fare questa settimana founder e CTO

Tre profili richiedono tre scelte diverse.

Per un piccolo team di prodotto che sviluppa nuove funzionalità, la scelta giusta sono i Cloud Agents gestiti da Cursor, se gli ambienti e i controlli di rete riescono a riprodurre la build. Il rilascio del 13 maggio copre configurazione multi-repository, segreti di build, cache e auditabilità; la dichiarazione di Cursor su oltre il 30% delle pull request integrate è il riscontro pubblico. Non ha senso gestire una flotta di worker senza un requisito di policy che lo imponga.

Se Cloudflare o Vercel ospitano già processi in background di lunga durata, conviene mantenere lì lo stato durevole dell'applicazione e l'orchestrazione. Cursor Self-Hosted Machines può ora usare l'infrastruttura Cloudflare o Vercel per eseguire gli strumenti, ma il ciclo dell'agente resta sotto il controllo di Cursor. Sul versante consumer, vale la pena leggere questo caso parallelo, che mostra come Anthropic stia confezionando primitive simili per le PMI: la convergenza delle piattaforme sugli agenti si vede ormai ovunque.

Se è in programma un'adozione enterprise, il punto di partenza sono i Cloud Agents gestiti, quando allowlist, Tailscale, AWS PrivateLink o Cloudflare Tunnel soddisfano i requisiti di accesso. I Team Pools servono invece quando checkout, esecuzione degli strumenti, hardware personalizzato o immagine del worker devono restare sotto il proprio controllo. I Team Pools richiedono Enterprise, il cui prezzo è Custom, mentre i Dockerfile configurati da Cursor sono ancora in private beta.

Cosa è cambiato dopo maggio

Due segnali.

Primo: Cursor ora documenta lo stato della conversazione separatamente dal workspace di runtime. Per impostazione predefinita, lo stato della conversazione viene conservato a tempo indeterminato, così le esecuzioni possono essere riaperte e riprese; gli snapshot delle VM gestite scadono dopo 90 giorni di inattività, a meno che un avvio o una ripresa non estendano la finestra. La possibilità di riprendere un'esecuzione non è più un limite. Lo sono la proprietà e la programmabilità.

Secondo: il luogo di esecuzione privato non è più un limite. Self-Hosted Machines lo risolve, pur lasciando nel cloud di Cursor il ciclo dell'agente, l'inferenza e la pianificazione. Le due differenze ancora sostanziali sono lo stato dell'agente sotto il controllo del cliente e una superficie di step durevoli definita dallo sviluppatore.

Il rilascio di Cursor del 13 maggio rende superflua un'infrastruttura self-hosted per gli agenti?

No. Cursor offre ora un proprio percorso self-hosted: My Machines per i flussi personali e Team Pools per le flotte Enterprise. L'esecuzione degli strumenti si sposta nella rete del cliente, ma Cursor continua a gestire il ciclo dell'agente e a conservare lo stato delle conversazioni. I team che hanno bisogno di un runtime applicativo programmabile o di step durevoli dei workflow devono comunque predisporre l'infrastruttura per questi livelli.

Quanto sono veloci oggi le build in cache degli agenti cloud di Cursor?

Dopo l'aggiornamento del 13 maggio alla cache dei layer, le build con cache hit sono più veloci del 70%. In caso di cache hit vengono ricostruiti soltanto i layer modificati del Dockerfile.

Che cosa indica il dato interno di Cursor sulle pull request integrate?

La pagina ufficiale attuale di Cursor afferma che oltre il 30% delle pull request integrate dall'azienda viene creato da agenti autonomi attivi in sandbox cloud. È un dato utile sull'adozione in produzione perché misura le pull request integrate, non le attività tentate.

Gli agenti cloud di Cursor sono sicuri per il codice che accede ai segreti di produzione?

Il rilascio del 13 maggio definisce traffico in uscita e segreti per singolo ambiente, isola i segreti di build dall'agente in esecuzione e mette a disposizione cronologia delle versioni, rollback e audit log. Self-Hosted Machines può mantenere sul worker il checkout completo e le credenziali locali della macchina, ma contenuti dei file necessari, output degli strumenti, diff, screenshot e risultati MCP locali possono comunque essere inviati a Cursor. La sicurezza dipende dalla valutazione e dall'approvazione di entrambi i confini.

Posso usare Cloudflare Workers e gli agenti cloud di Cursor insieme?

Sì. Cursor indica Cloudflare tra le integrazioni di Self-Hosted Machines e il suo template di riferimento usa un Cloudflare Worker come controller per avviare un Cloudflare Container per ogni richiesta acquisita. Cursor può occuparsi del ciclo dell'agente di coding, mentre Workers, Durable Objects e Workflows gestiscono stato durevole dell'applicazione e orchestrazione. I prodotti ora si sovrappongono nell'esecuzione degli strumenti, ma non al confine del ciclo dell'agente.