Cursor entra nel code hosting con Origin, una nuova infrastruttura che permette alla piattaforma di ospitare direttamente il codice e riunisce repository, pull request, navigazione della codebase e agenti AI nello stesso ambiente. La early beta è partita il 17 agosto 2026 su tutti i piani a pagamento, con la possibilità per gli amministratori delle organizzazioni Enterprise di disabilitarla.
Cursor presenta questa prima versione come il nucleo essenziale di Origin: repository, pull request, code browsing e sincronizzazione con GitHub, progettati dichiaratamente per operare alla scala richiesta dagli agenti. Ulteriori funzionalità definite agent-native arriveranno successivamente.
L’annuncio segue di appena tre giorni il completamento dell’acquisizione di Cursor da parte di SpaceX, chiusa il 14 agosto. Il collegamento temporale non implica che Origin sia un prodotto derivato dall’operazione – Cursor aveva già presentato pubblicamente Origin come una «Git forge for the agentic era» – ma l’ingresso nel gruppo SpaceX cambia le risorse infrastrutturali disponibili per sviluppare i modelli che alimentano gli agenti destinati a lavorare anche sui repository Origin.
Origin ospita direttamente i repository Git
La nuova scheda Codebase diventa il punto di accesso ai repository Origin. La creazione avviene dall’interfaccia assegnando un nome al repository; Cursor fornisce quindi le istruzioni per installare la CLI e i comandi necessari per clonare il repository oppure effettuare il push di un progetto locale.
Con il primo repository viene scelto anche il nome della codebase, che entra nell’URL utilizzato da Origin. Il codice inviato attraverso Git viene quindi ospitato direttamente dall’infrastruttura di Cursor.
È un’estensione rilevante del perimetro tecnico della piattaforma perché Cursor gestisce ora anche il repository sul quale operano i suoi agenti. Nell’annuncio l’azienda riassume questa integrazione con una formulazione precisa: codice, pull request e agenti si trovano nello stesso ambiente.
L’agente può essere interrogato sul codice che l’utente sta navigando e dispone anche di capacità operative sul repository: può modificare il codice, aggiornare una pull request ed effettuare il push di un branch.
I repository GitHub possono rimanere su GitHub
Origin è stato progettato anche per convivere con repository esistenti su GitHub. Dopo aver collegato GitHub a Cursor, l’utente sceglie l’organizzazione e seleziona i repository da sincronizzare. La scelta rimane reversibile e un repository può essere disconnesso successivamente.
I repository sincronizzati vengono aggiornati in tempo reale. La copia presente in Origin può essere utilizzata per navigare e cercare il codice ed eseguire operazioni di pull.
La proprietà del flusso Git rimane però chiaramente definita: per i repository nati su GitHub, i push continuano a essere indirizzati a GitHub e GitHub rimane la source of truth. Origin mantiene la copia sincronizzata e l’interfaccia utilizza icone differenti per distinguere i repository ospitati direttamente da Cursor da quelli provenienti da GitHub.
Questa architettura permette quindi di utilizzare Origin senza trasferire necessariamente l’hosting del repository. I due modelli possono convivere nella stessa Codebase: repository nativi Origin e repository GitHub sincronizzati.
Le pull request vengono sincronizzate in entrambe le direzioni
Ogni repository Origin dispone delle proprie pull request. L’interfaccia consente di visualizzare timeline, commit, check e file modificati, esaminare i diff, inserire commenti ed eseguire il merge.
La sincronizzazione con GitHub comprende anche questo livello del workflow. Per i repository collegati, le pull request vengono sincronizzate bidirezionalmente: un commento inserito in Cursor viene pubblicato su GitHub, mentre reazioni e risposte effettuate su GitHub compaiono in Cursor, secondo l’azienda nell’arco di pochi secondi.
Anche una review assegnata attraverso GitHub può essere eseguita da Cursor e completata con il merge senza cambiare ambiente.
Origin porta così nello stesso spazio operativo il codice conservato nel repository, la discussione sulle modifiche e gli agenti incaricati di intervenire sulla codebase. È precisamente su questa integrazione che Cursor concentra il riferimento alla agent scale della nuova infrastruttura, rimandando però a una fase successiva i dettagli delle ulteriori funzionalità agent-native.
Un contesto segnato dai problemi di disponibilità di GitHub
L’arrivo di Origin coincide inoltre con una fase nella quale l’affidabilità di GitHub è sottoposta a una pressione crescente. La stessa GitHub ha riconosciuto di non avere rispettato i propri standard di disponibilità e ha collegato parte dell’instabilità alla rapida crescita dei carichi generati dai nuovi workflow di sviluppo agentico. Nel solo febbraio 2026 la piattaforma ha registrato sei incidenti con degrado dei servizi; il 9 febbraio due episodi collegati hanno prodotto complessivamente circa 2 ore e 43 minuti di servizio degradato, coinvolgendo github.com, API, Actions, operazioni Git, Copilot, Issues, pull request, webhook, Pages e Codespaces. La sequenza è proseguita nei mesi successivi: GitHub ha contato quattro incidenti a marzo, dieci ad aprile, nove a maggio e sei a giugno.
Il 17 agosto, nelle stesse ore dell’annuncio di Origin, un nuovo incidente ha interessato nuovamente servizi centrali di GitHub, coinvolgendo API e pagine web e facendo registrare un failure rate del 50% su raw.githubusercontent.com, con conseguenze anche sull’installazione dei pacchetti e sulle build Docker. Il problema dell’affidabilità assume particolare rilevanza mentre cresce il carico prodotto dagli agenti: GitHub ha dichiarato che dalla seconda metà di dicembre 2025 stanno aumentando rapidamente creazione di repository, attività sulle pull request, utilizzo delle API, automazione e workload sui repository di grandi dimensioni, tanto da avere rivisto i propri obiettivi infrastrutturali da una capacità pari a 10 volte quella precedente a una progettazione capace di sostenere 30 volte la scala attuale.
Vercel collega le pull request ai preview deployment
Il code hosting si collega alla restante toolchain attraverso un sistema di app extension che, nella prima versione di Origin, comprende Vercel, Depot e Buildkite, con ulteriori integrazioni già annunciate. Vercel può essere collegato direttamente dalla scheda Apps del repository: in questo modo ogni pull request genera un preview deployment sul quale è possibile eseguire test e inserire commenti, mentre dopo il merge il flusso prosegue verso il deployment in produzione.
Sul fronte della continuous integration, Origin supporta Depot e Buildkite, entrambi compatibili con i workflow GitHub Actions già esistenti; Buildkite aggiunge inoltre il supporto alle proprie pipeline native. La configurazione delle integrazioni rimane gestibile a livello di singolo repository, insieme allo stato della sincronizzazione con GitHub e agli utenti autorizzati ad accedere.
Origin nasce per una scala di sviluppo sempre più agentica
L’indicazione più significativa fornita direttamente da Cursor riguarda il criterio con cui sono state progettate queste funzioni iniziali: gli elementi fondamentali di Origin sono «designed for agent scale».
Il riferimento si inserisce nell’evoluzione già documentata dei prodotti Cursor. Gli agenti hanno progressivamente acquisito la capacità di lavorare sulla codebase, utilizzare strumenti e svolgere attività più lunghe e articolate. Origin aggiunge a questo ambiente il livello nel quale il codice viene conservato, sottoposto a revisione e integrato.
Cursor aveva già sintetizzato l’obiettivo di Origin definendolo una «Git forge for the agentic era», accompagnando questa definizione con l’affermazione che il codice sta avanzando a una velocità superiore a quella per cui sono state costruite le infrastrutture esistenti.
La early beta del 17 agosto concretizza quella impostazione con le prime componenti disponibili agli utenti. Cursor non ha ancora specificato quali saranno le future funzioni agent-native, quindi la portata di questa parte dell’architettura potrà essere valutata solo con le prossime release.
L’acquisizione di Cursor porta Origin dentro l’infrastruttura SpaceX
Il debutto di Origin avviene in una fase particolarmente importante per l’infrastruttura sulla quale Cursor può costruire i propri modelli. Il 14 agosto SpaceX ha completato l’acquisizione di Anysphere, la società che sviluppa Cursor, con una valutazione implicita di 60 miliardi di dollari.
Il rapporto fra le due aziende era iniziato prima del closing. Il 21 aprile Cursor aveva annunciato una partnership con SpaceX finalizzata esplicitamente ad aumentare la scala del training dei propri modelli. L’azienda spiegava allora che la disponibilità di compute era diventata il collo di bottiglia per ulteriori progressi e che avrebbe utilizzato l’infrastruttura Colossus di SpaceXAI per aumentare la capacità di training.
L’accordo aveva una base infrastrutturale precisa. La documentazione pubblicata da SpaceX in vista della quotazione indicava che il gruppo avrebbe fornito a Cursor capacità di calcolo su cluster GPU per attività di sviluppo, training e miglioramento dei modelli AI e di altre tecnologie. Cursor avrebbe contribuito con personale, dati e dataset, documentazione, know-how tecnico, workflow, prompt, specifiche e codice software.
Con il completamento dell’acquisizione, Cursor ha dichiarato che avrà accesso alla più grande flotta di GPU al mondo, un’affermazione dell’azienda che non è accompagnata da un confronto quantitativo omogeneo con le infrastrutture degli altri grandi operatori AI. Il dato industriale documentato è l’accesso di Cursor alla capacità computazionale del gruppo SpaceX.
Cursor collega direttamente questa disponibilità di compute alla possibilità di costruire modelli più capaci e meno costosi da eseguire. Già nella partnership di aprile aveva spiegato che ogni incremento di compute ottenuto durante lo sviluppo di Composer si era tradotto in miglioramenti delle capacità dei modelli: Composer 1.5 aveva aumentato di oltre 20 volte la scala del reinforcement learning rispetto al predecessore, mentre Composer 2 aveva aggiunto il continued pretraining.
Compute, modelli, agenti e repository
Origin aggiunge quindi un nuovo componente a un’infrastruttura Cursor che comprende ormai diversi livelli tecnici documentabili separatamente: modelli proprietari, agenti che operano sul codice e, adesso, hosting e gestione dei repository. L’acquisizione aggiunge a monte l’accesso alla capacità di calcolo di SpaceX utilizzata per il training e lo sviluppo dei modelli.
Sono piani distinti e Cursor non afferma che Origin utilizzi direttamente Colossus per ospitare i repository o eseguire le normali operazioni Git. Il collegamento riguarda i modelli e gli agenti: la capacità computazionale SpaceX viene utilizzata per sviluppare e migliorare l’intelligenza che Cursor porta nei propri prodotti, mentre Origin fornisce agli agenti un ambiente nel quale codice, branch e pull request possono essere gestiti direttamente.
La distinzione è importante perché evita di attribuire a Origin un’architettura infrastrutturale che Cursor non ha documentato. L’accesso al compute SpaceX riguarda ufficialmente training, sviluppo e miglioramento dei modelli AI; Origin riguarda il code hosting e l’integrazione degli agenti con i repository.
A tre giorni dal closing dell’acquisizione, i due sviluppi mostrano comunque le componenti che Cursor ha oggi a disposizione: capacità di calcolo per sviluppare i modelli, agenti capaci di intervenire sul software e una Git forge nella quale quegli agenti possono operare direttamente su repository e pull request. Le prossime funzionalità agent-native di Origin chiariranno quanto strettamente questi livelli verranno integrati nel workflow di sviluppo.
