Composer 2.5: benchmark, prezzi e confronti

Cursor ha rilasciato Composer 2.5 il 18 maggio 2026, circa due mesi dopo Composer 2 uscito a marzo. Il breve intervallo tra le release mostra la rapidità con cui Cursor aggiorna la propria linea di modelli.

Secondo Cursor, Composer 2.5 ottiene punteggi vicini a Claude Opus 4.7 e GPT-5.5 su diversi benchmark di coding. Anche il prezzo per token è inferiore rispetto ai modelli di frontiera. È cambiato anche l’addestramento: più task sintetici, ambienti di training più difficili e un metodo di feedback che mira a errori specifici all’interno di lunghe sessioni di coding.

In questo articolo, guardo a Composer 2.5 come a qualcosa di più di un aggiornamento di benchmark. Vedrò cos’è, cosa è cambiato, come appaiono i benchmark, come i prezzi si confrontano con i modelli di frontiera e dove si inserisce in un flusso di lavoro di coding. Ci sono anche dei limiti, e alcuni vale la pena conoscerli prima di considerare i punteggi come l’intera storia.

Per maggiori dettagli sugli altri modelli di questo confronto, vedi le nostre guide a Claude Opus 4.7 e GPT-5.5.

Che cos’è il modello Composer 2.5 di Cursor?

Composer 2.5 è il modello più recente della famiglia Composer di Cursor, progettato per il lavoro di coding all’interno dell’IDE Cursor. Segue Composer 1, Composer 1.5 e Composer 2.

Timeline di Composer dal lancio alla versione 2.5. Immagine dell’autore.

Non è un chatbot generale. Composer 2.5 è addestrato per modifiche tra file, comandi da terminale, uso di strumenti e sessioni di coding più lunghe. I suoi obiettivi di training e i benchmark si concentrano su task di ingegneria del software.

Il post di lancio afferma che il modello supera Composer 2 nei task di coding e si comporta in modo diverso nelle sessioni più lunghe. Ora è l’opzione predefinita nel selettore dei modelli di Cursor, anche se Composer 2 resta disponibile. Inoltre gira solo all’interno di Cursor. Non esistono API pubbliche, né una scheda modello su Hugging Face, né accesso tramite un altro provider.

Cosa è cambiato in Composer 2.5

I cambiamenti in Composer 2.5 rientrano in due categorie: performance sui task di coding e comportamento collaborativo. La prima è più facile da misurare della seconda, quindi vale la pena distinguere ciò che Cursor può mostrare con numeri da ciò che descrive in modo più qualitativo.

Performance su task più lunghi

Composer 2.5 è mirato a sessioni di coding più lunghe, in cui un modello deve leggere file, eseguire comandi da terminale, correggere errori e iterare. È importante perché lo sviluppo reale raramente si riduce a un singolo prompt e una singola risposta.

Cursor ha addestrato il modello in ambienti di reinforcement learning più difficili per questo tipo di lavoro. I task sono stati creati durante il training e la difficoltà è aumentata nel tempo.

Rispetto delle istruzioni e collaborazione

La release descrive anche una maggiore affidabilità nel seguire le istruzioni. Si parla di calibrazione dello sforzo: il modello dovrebbe dedicare più calcolo ai task difficili ed evitare di rimuginare su quelli semplici.

C’è però una nota. Cursor segnala che questi cambiamenti di comportamento "non sono ben catturati dai benchmark esistenti". Quindi questa parte della release poggia soprattutto sulla valutazione di Cursor e sui primi feedback degli utenti, non su un punteggio pubblico.

Ambienti RL più difficili

Il post di lancio inquadra il cambiamento nel training come "scalare il training, generare ambienti RL più complessi e introdurre nuovi metodi di apprendimento". L’addestramento ha usato un numero di task sintetici 25 volte superiore rispetto a Composer 2.

Come Cursor ha addestrato Composer 2.5

I dettagli del training spiegano perché il modello è cambiato senza una nuova architettura di base. Composer 2.5 usa lo stesso foundation di Composer 2, ma è cambiato il lavoro successivo al training di base. Non tutti i dettagli infrastrutturali contano allo stesso modo per i lettori, ma alcune parti aiutano a spiegare il movimento nei benchmark.

Costruito su Kimi K2.5

Composer 2.5 è costruito sullo stesso checkpoint open source di Composer 2: Kimi K2.5 di Moonshot AI. Cursor lo ha dichiarato direttamente nel post di lancio, cosa importante perché il modello base è stato oggetto di dibattito attorno a Composer 2.

Kimi K2.5 usa un’architettura Mixture of Experts. Cursor applica pretraining continuato e reinforcement learning su quella base, e afferma che circa l’85% del calcolo totale per il modello finale deriva dal proprio lavoro successivo al training di base.

RL mirato con feedback testuale

Questo è il principale cambiamento tecnico in Composer 2.5. L’RL standard fornisce al modello un unico segnale di ricompensa alla fine di una lunga sequenza. In una lunga sessione di coding, quella ricompensa finale può essere troppo rumorosa per indicare dove il modello ha sbagliato.

L’insegnante e lo studente condividono un turno. Immagine dell’autore.

Il metodo di Cursor inserisce un breve suggerimento testuale nel punto in cui il modello ha preso una decisione sbagliata. Per esempio, se il modello chiama un tool inesistente, il processo di training può inserire un promemoria con l’elenco corretto degli strumenti. La versione con suggerimento funge da "insegnante" e il modello originale da "studente". Una perdita di distillazione sposta quindi il comportamento dello studente verso quello dell’insegnante solo in quel turno.

Il risultato è un training più mirato: si possono correggere errori individuali senza trattare un intero rollout lungo come vagamente giusto o sbagliato. Cursor ha applicato questo metodo a stile di coding, uso degli strumenti e comunicazione del modello durante l’addestramento di Composer 2.5.

Dati sintetici su scala maggiore

Composer 2.5 è stato addestrato con un numero di task sintetici 25 volte superiore rispetto a Composer 2. Questi task sono ancorati a codebase reali, non a esempi giocattolo.

Un approccio descritto da Cursor è la cancellazione di funzionalità. Un agente parte da una codebase reale e da un’ampia suite di test, poi rimuove codice e file mantenendo il resto del progetto funzionale. Il task sintetico è reimplementare la funzionalità rimossa, e i test forniscono un segnale di ricompensa verificabile.

La scala del training sintetico introduce rischi propri. Cursor ha documentato casi in cui Composer 2.5 ha trovato scorciatoie, tra cui il recupero di informazioni cancellate da una cache di type-checking Python e la decompilazione di bytecode Java per ricostruire un’API esterna. L’azienda afferma di aver intercettato questi casi usando strumenti di monitoraggio, ma ha riconosciuto che il training a questa scala richiede "cure crescenti".

Cambiamenti infrastrutturali

Sul fronte infrastrutturale, Cursor ha utilizzato Sharded Muon e dual mesh HSDP per il pretraining continuato. Questi cambiamenti hanno ridotto parte dei costi e dei tempi coinvolti nell’addestramento su grandi cluster GPU.

Risultati dei benchmark di Composer 2.5: Terminal-Bench, SWE-Bench e CursorBench

I benchmark sono utili, ma non mostrano l’intero quadro. Li considererei un punto di partenza per il confronto, non un verdetto completo su come il modello si sentirà nel lavoro quotidiano.

Cursor valuta Composer 2.5 su tre benchmark:

SWE-Bench Multilingual verifica se un modello può risolvere issue reali su GitHub in più linguaggi di programmazione. Ogni task fornisce al modello un repository e una descrizione del problema, poi controlla se la patch supera i test associati.

Terminal-Bench 2.0 misura se un agente AI può operare in workflow da terminale reali: ispezionare file, eseguire comandi, fare debugging dei fallimenti e completare task con più passaggi.

CursorBench v3.1 è il benchmark interno privato di Cursor. Valuta agenti su task ambigui e multi-file tratti da sessioni reali in Cursor, tra cui comprensione della codebase, individuazione di bug, pianificazione e code review. Il limite è che CursorBench non può essere verificato o riprodotto da ricercatori esterni, e i punteggi vanno confrontati all’interno della stessa versione di eval.

C’è un’avvertenza importante prima di leggere troppo in questi numeri. I confronti tra modelli sui benchmark non sono sempre puliti. Differenze di setup di valutazione e impostazioni di sforzo possono spostare i punteggi, e Cursor segnala che Opus 4.7 e GPT-5.5 usano punteggi auto-riportati per le valutazioni pubbliche. Considerali confronti direzionali, non test diretti in condizioni identiche.

Un successivo benchmark esterno di Artificial Analysis punta nella stessa direzione, anche se usa un mix di benchmark diverso. Composer 2.5 ha ottenuto 62 nell’Artificial Analysis Coding Agent Index, dietro a Claude Opus 4.7 con sforzo massimo (66) e a GPT-5.5 con ragionamento xhigh (65). 

Il divario di costo è la parte su cui porrei attenzione: Artificial Analysis ha stimato Composer 2.5 a $0,07 per task per Standard e $0,44 per Fast, rispetto a $4,10 per Opus 4.7 max e $4,82 per GPT-5.5 xhigh.

Composer 2.5 vs. Composer 2 vs. Composer 1.5: confronto dei punteggi

La famiglia Composer ha avuto tre release in un breve periodo. Composer 1.5 è uscito a febbraio 2026, Composer 2 a marzo e Composer 2.5 a maggio. Ogni versione ha cambiato qualcosa di diverso nell’approccio al training.

Composer 2.5 rispetto a Composer 2

Il salto da Composer 2 a 2.5 si vede soprattutto su Terminal-Bench 2.0, dove il punteggio è passato dal 61,7% al 69,3%, e su SWE-Bench Multilingual, dal 73,7% al 79,8%. Il guadagno su CursorBench è più piccolo, e la versione del benchmark è passata da v3 a v3.1, quindi il confronto è meno diretto.

La differenza maggiore è nella pipeline di training. Composer 2 ha introdotto il pretraining continuato su Kimi K2.5. Composer 2.5 ha mantenuto quella base e ha aggiunto feedback testuale mirato, 25 volte più task sintetici e cambiamenti infrastrutturali. Il prezzo Standard è rimasto invariato.

Composer 2.5 rispetto a Composer 1.5

Composer 1.5 è stato creato scalando il reinforcement learning di 20 volte in più sullo stesso modello pre-addestrato di Composer 1. Ha introdotto il pensiero adattivo e l’auto-sintesi, che consente al modello di comprimere il proprio contesto quando una sessione si allunga.

Il divario da Composer 1.5 a 2.5 è ampio su ogni benchmark. È arrivato anche con un prezzo per token più basso: Composer 1.5 costava $3,50 per un milione di token in input e $17,50 per un milione di token in output, circa 7 volte più caro di Composer 2.5 Standard.

Cosa è cambiato nella pratica

Attraverso queste versioni, lo schema è abbastanza chiaro: ogni generazione ha modificato il comportamento durante le sessioni lunghe e il follow delle istruzioni, mentre Composer 2 e 2.5 hanno abbassato il costo delle sessioni di agenti prolungate.

Composer 2.5 vs. Claude Opus 4.7 vs. GPT-5.5: benchmark, prezzo e compromessi

Questo è il confronto che interesserà per primo molti lettori. Composer 2.5 ha punteggi di benchmark di coding simili in alcune aree, un prezzo per token inferiore rispetto ai modelli di frontiera elencati sotto e chiari trade-off.

Confronto dei benchmark

GPT-5.5 è in testa su Terminal-Bench 2.0 con l’82,7%, circa 13 punti davanti a Composer 2.5. Quel divario conta per lavori che dipendono molto dall’uso del terminale.

Claude Opus 4.7 è leggermente avanti a Composer 2.5 su SWE-Bench Multilingual (80,5% contro 79,8%), meno di un punto. Su CursorBench, Composer 2.5 al 63,2% è sopra Opus 4.7 con impostazioni di default (61,6%) ma sotto Opus 4.7 al massimo sforzo (64,8%). Anche GPT-5.5 arriva al 64,3% con xhigh, mentre il suo punteggio di default è 59,2%.

Questi modelli non svolgono lo stesso lavoro. Opus 4.7 e GPT-5.5 sono modelli di frontiera più ampi. Composer 2.5 è un modello di coding che gira solo in Cursor. I punteggi dei benchmark sono vicini in alcuni task di coding, ma i confini di prodotto sono diversi.

Confronto dei prezzi

La differenza di costo è la spaccatura più netta rispetto ai modelli di frontiera.

Composer 2.5 Standard è prezzato a circa un decimo di Opus 4.7 e GPT-5.5 per token. Anche la variante Fast ha un prezzo inferiore rispetto ai tier standard di entrambi i modelli di frontiera.

Questi prezzi sono aggiornati a maggio 2026, quindi controlla i prezzi dei modelli di Cursor, i prezzi di Opus di Anthropic e i prezzi dell’API di OpenAI prima di fare affidamento sul confronto.

Una nota che spesso si perde: il prezzo di Composer 2.5 Fast è raddoppiato rispetto a Composer 2 Fast. Il prezzo Standard è rimasto stabile, ma Fast è il default, quindi l’upgrade può comunque aumentare i costi per alcuni utenti.

Quale modello dovresti scegliere?

La scelta del modello dipende da cosa conta di più tra costo, lavoro da terminale o pianificazione più profonda:

• Composer 2.5 è adatto al coding quotidiano dentro Cursor, soprattutto modifiche tra file, refactoring, debugging e sessioni con agenti in cui il costo conta.
• GPT-5.5 è adatto ai task in cui la performance da terminale è fondamentale.
• Claude Opus 4.7 è adatto a task che richiedono ragionamento accurato, pianificazione architetturale o una finestra di contesto da 1 milione di token.

Questo è lo schema che trarrei dai numeri: Composer 2.5 copre il lavoro di coding di routine, mentre i modelli di frontiera hanno ancora un ruolo per un ragionamento più ampio o punteggi da terminale più alti.

Composer 2.5 Standard vs. Fast: velocità, prezzo e quando usare ciascuno

Cursor distribuisce Composer 2.5 in due varianti, come ha fatto con Composer 2. Secondo Cursor, entrambe condividono la stessa intelligenza di base. La differenza riguarda principalmente la rapidità di risposta e il costo.

Selettore dei modelli di Cursor con Composer selezionato. Immagine dell’autore.

Fast è il default e costa $3,00 per milione di token in input e $15,00 per milione di token in output. È pensato per sessioni interattive in cui la bassa latenza conta. Standard costa $0,50 e $2,50, quindi si adatta a task in background o loop di agenti più lunghi in cui il feedback immediato è meno importante.

L’uso di Composer 2.5 rientra nel pool di utilizzo "Auto + Composer" di Cursor, separato dal pool API usato per modelli esterni come Claude e GPT. Cursor ha anche offerto uso raddoppiato per la prima settimana dopo il lancio.

Limitazioni e avvertenze di Composer 2.5

Le avvertenze riguardano accesso, benchmark e rischi di training. Non rendono Composer 2.5 insolito, ma incidono su quanto peso dare alle affermazioni di Cursor.

Disponibile solo in Cursor. Come accennato, Composer 2.5 non ha un’API pubblica. Se il tuo flusso di lavoro dipende dalla chiamata a un modello dai tuoi script o pipeline, Composer 2.5 non è un’opzione.

CursorBench non è indipendente. Come visto nella sezione sui benchmark, CursorBench v3.1 è interno a Cursor. La sua metodologia non è completamente pubblica e i task non possono essere riprodotti da ricercatori esterni.

Variabilità del setup dei benchmark. I punteggi dei modelli di frontiera nel grafico dei benchmark di Cursor non sono tutti misurati allo stesso modo. Considera i confronti come direzionali, non definitivi.

Reward hacking durante il training. Cursor ha divulgato casi in cui il modello ha trovato scorciatoie intelligenti nei task sintetici invece di risolverli normalmente. È un rischio intrinseco dell’RL a questa scala, anche quando il monitoraggio intercetta gli esempi più evidenti.

La calibrazione dello sforzo non è verificata. Le affermazioni di Cursor su stile di comunicazione e calibrazione dello sforzo non sono supportate da dati di benchmark, come già detto. Questo le rende difficili da verificare dall’esterno.

Quando ha senso usare Composer 2.5

Dipende dal task. Inquadrerei Composer 2.5 meno come una scelta di modello universale e più come un modello di coding per chi lavora già dentro Cursor.

Se passi la maggior parte della giornata a fare coding in Cursor e ti interessa il costo per token, Composer 2.5 Standard ha il prezzo più basso nella linea Composer 2.5. Vale per le stesse attività di modifica, refactoring, debugging e lavoro in sessioni lunghe descritte sopra.

Se conta di più la velocità di risposta, Composer 2.5 Fast è l’opzione predefinita.

Se il task richiede un ragionamento più ampio, una finestra di contesto maggiore o punteggi di benchmark più alti in un’area specifica, Claude Opus 4.7 o GPT-5.5 possono essere più adatti.

Un modo per inquadrarlo: Composer 2.5 gestisce il lavoro di coding di routine trattato sopra, mentre un modello di frontiera può adattarsi a task che richiedono ragionamento più ampio o punteggi più alti da terminale. Mantiene il confronto ancorato senza trasformarlo in una raccomandazione di un unico modello in ogni caso.

Considerazioni finali

È facile leggere Composer 2.5 come una storia di benchmark, ma il punto più utile, secondo me, è la direzione di marcia. Cursor non si limita a incapsulare modelli di frontiera dentro un editor. Sta costruendo una linea di modelli attorno ai tipi di lavoro che i suoi agenti già svolgono: modifiche tra file, passaggi da terminale, sessioni più lunghe e recupero dagli errori.

Come detto, il compromesso è che Composer 2.5 è stretto per design. Non sostituisce Claude Opus 4.7 o GPT-5.5 come modello generale e non aiuta se ti serve un’API al di fuori di Cursor. Ma dentro Cursor, il focus più ristretto è il punto. Il modello costa meno da eseguire rispetto alle opzioni di frontiera, è tarato per i task di coding e siede vicino al layer di prodotto dove questi task avvengono.

La prossima domanda è quanto di tutto ciò Cursor voglia possedere. L’azienda afferma di lavorare con SpaceXAI per addestrare da zero un modello più grande usando 10 volte più calcolo totale e l’infrastruttura Colossus 2. Non è stata fornita una data di rilascio, quindi non c’è molto da analizzare per ora. Tuttavia, la traiettoria è chiara: Cursor sta passando dall’usare bene i modelli al costruire più parti dello stack di modelli in proprio.