Selezione del Modello in Cursor nel 2026: Quando Usare Composer 2.5 Standard, Fast o Frontier

L'articolo su Cursor 3.0 si basava su un'affermazione economica: orchestrare molti agenti amplifica la propagazione degli errori più velocemente di quanto amplifichi l'output utile. Composer 2.5 rompe uno degli input di quell'equazione — il prezzo di una chiamata al modello è appena sceso di un ordine di grandezza nel tier Standard. Il resto dell'equazione ha retto. Ecco cosa è cambiato, e come pianificare di conseguenza.

Sei settimane dopo il rewrite 3.0, la forma della scommessa di Cursor è chiara. L'articolo 3.0 inquadrava l'Agents Window, i git worktree e l'ecosistema MCP come l'architettura degli agenti paralleli autonomi. Ciò che è stato rilasciato da allora — le versioni 3.3, 3.4 e Composer 2.5 — è la parte che rende quell'architettura economicamente seria: un modello proprietario abbastanza economico da far sì che far girare dieci agenti in parallelo smetta di essere una decisione di budget, e un'infrastruttura cloud che li esegue fuori dal proprio laptop, nella propria topologia di deployment, con la governance enterprise integrata.

La domanda interessante per chi guida un'organizzazione di sviluppo non è se tutto ciò sia impressionante. Lo è. La domanda è se agenti più economici e veloci cambino la conclusione a cui era giunto l'articolo 3.0 — che il collo di bottiglia è il giudizio, non la generazione. Non la cambiano. Ma spostano la linea, e dove si sposta determina come si dovrebbero instradare i lavori, pianificare la spesa e gestire i merge.

Cosa è uscito: la timeline delle sei settimane

La progressione è coerente. Gli aggiornamenti enterprise danno agli amministratori il controllo sulla spesa e sui modelli; la 3.3 fornisce visibilità su cosa consuma il budget di contesto; la 3.4 sposta l'esecuzione degli agenti in ambienti Dockerizzati riproducibili che possono attraversare più repository; Composer 2.5 rende economico il modello che gira in quegli ambienti. Ogni passo abbassa il costo marginale di inviare un agente. Questa è la tesi che Cursor sta eseguendo — portare il costo per agente verso zero e il flusso di lavoro con agenti paralleli diventa il default anziché l'esperimento.

Composer 2.5: Kimi K2.5 Addestrato da Cursor su Larga Scala

Composer 2.5 è costruito sul checkpoint open-weight Kimi K2.5 di Moonshot AI — la stessa base di Composer 2 — poi post-addestrato su larga scala dal team di Cursor. Capire cosa è stato modificato, e in che misura, spiega perché il prezzo ha potuto scendere mentre i numeri dei benchmark hanno tenuto (Cursor, 2026a).

Cursor ha investito l'85% del budget totale di calcolo per questo modello nella propria pipeline di post-training — non nel pretraining del modello base. Quella pipeline includeva reinforcement learning con feedback testuale, continued pretraining e training mirato su 25× più task sintetici di coding rispetto a quelli usati da Composer 2. Uno schema degno di nota: la "feature deletion," in cui una feature funzionante viene rimossa da una codebase e il modello deve ricostruirla usando solo la test suite come segnale di reward. Nessuna valutazione umana, reward automatico e verificabile. Il modello ha ricevuto anche una ricerca deliberata sul reward hacking per migliorare la robustezza nelle sessioni lunghe senza supervisione — un vero failure mode quando gli agenti girano per minuti anziché secondi (Cursor, 2026a).

Risultati dei benchmark

Questi sono numeri pubblicati da Cursor, quindi vanno trattati come un segnale da valutare, non come un verdetto definitivo. CursorBench v3.1 è la suite interna di Cursor per task reali sottospecificati, dove non esiste un'unica risposta corretta. Il fatto che Composer 2.5 superi Opus 4.7 nel tipo di task più rappresentativo del lavoro agentico reale — pur restando entro frazioni di punto sui benchmark esterni — è il segnale rilevante (Cursor, 2026a).

Il calo dei prezzi

Con Composer 2.5 arrivano due tier di prezzo. La distinzione conta ed è ignorata dalla maggior parte dei commenti.

Il benchmark indipendente è il segnale più chiaro. Il Coding Agent Index di Artificial Analysis — che misura il prezzo di un mix fisso di task end-to-end anziché per token — ha posizionato Composer 2.5 al terzo posto assoluto, dietro solo alle varianti ad alto effort di Claude Opus 4.7 e ChatGPT 5.5 (Artificial Analysis, 2026). L'indice è un composito di SWE-Bench-Pro-Hard-AA, Terminal-Bench v2 e SWE-Atlas-QnA — un set più difficile e vario di qualsiasi singolo benchmark.

Cursor è per la prima volta sulla frontiera di Pareto costo-qualità. Le versioni precedenti di Composer erano competitive sul costo ma distaccate in modo significativo sulle valutazioni esterne. Composer 2.5 chiude quel gap fino al rumore statistico su due dei tre benchmark, il che significa che la scelta del tier riguarda davvero i trade-off tra latenza e spesa — non la qualità sacrificata.

Cosa cambia nella matematica del 3.0

L'articolo 3.0 assumeva che il best-of-n — eseguire lo stesso prompt su più agenti paralleli — fosse una scelta deliberata e costosa, riservata ai refactoring ad alto rischio. Con i prezzi del tier Standard, campionare lo spazio delle soluzioni su più agenti paralleli smette di essere un'occasione speciale. Dieci candidati Composer-Standard costano all'incirca quanto uno su Opus 4.7. Questo abbassa genuinamente il lato generazione dell'equazione.

Non fa nulla al lato revisione. La generazione più economica non rende un diff più facile da ispezionare, un confine di sicurezza più facile da ragionare, o una dipendenza cross-service più facile da rilevare. Dieci candidati economici sono dieci cose da revisionare, non una. Se la capacità di revisione è fissa, abbassare il costo della generazione non aumenta il throughput — aumenta la coda. La leva sta nello scalare la revisione almeno tanto velocemente quanto si scala la generazione.

Un framework di routing per i responsabili tecnici

Il cambiamento nel modello operativo è la vera storia, ed è dove un tech lead guadagna il proprio valore. Un modello più economico non significa "usalo per tutto" — è una decisione di routing, e il routing si mappa direttamente sulla tassonomia dei task su cui si chiudeva l'articolo 3.0: il lavoro spec-chiaro e verificabile automaticamente va al modello economico; il lavoro di giudizio resta al frontier o all'essere umano.

La regola pratica da interiorizzare: un modello economico è economico solo se il diff risultante è circoscritto, testabile e facile da ispezionare. Non appena si instrada verso Composer un lavoro che produce una modifica ampia, difficile da revisionare e che tocca confini di fiducia, il risparmio sui token viene eclissato dal costo di revisione e incidente. Si instrada sulla verificabilità, non sulla fiducia.

Un modo per codificare questa strategia di routing è un file di istruzioni per agenti che le regole di Cursor ereditano. Ecco un pattern minimale:

# Agent Routing Policy
# This file is read by Cursor agents as a system instruction.

## Model selection

Use Standard tier (lower latency acceptable) for:
- Generating or expanding test files
- Scaffolding new files from an existing pattern
- Mechanical refactors (rename symbol, extract constant, update import paths)
- Documentation updates and inline comment additions
- Schema migrations matching a documented pattern

Use Fast tier (interactive, latency-sensitive) for:
- Multi-file feature work with a clear spec
- Iterative bug-fixing where you expect several rounds

STOP and ask a human for any task involving:
- Changes to authentication, authorisation, or session management
- Cross-service API contracts (adding / removing fields another service reads)
- Infrastructure or Dockerfile changes
- Any file in /secrets, /certs, or /.github/workflows

La pipeline: genera → filtra → seleziona

Quando la generazione parallela è economica, la configurazione produttiva diventa breadth-first: generare più candidati, lasciar eliminare quelli rotti dalla CI, poi selezionare il diff migliore che supera i test per la revisione umana. La pipeline che segue comprime quello che era un ciclo seriale "scrivi → revisiona → itera" in un ciclo parallelo "genera molti → filtra duramente → revisiona uno."

Il passo di filtraggio è portante. Una pipeline CI che gira veloce e copre le cose giuste è ora una parte fondamentale dell'infrastruttura per agenti, non solo del workflow per sviluppatori umani. Ecco un workflow GitHub Actions che implementa i controlli chiave per le PR scritte dagli agenti:

name: Agent PR Gate
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  agent-gate:
    runs-on: ubuntu-latest
    if: startsWith(github.event.pull_request.title, '[agent]')
    steps:
      - uses: actions/checkout@v4

      - name: Run test suite
        run: npm test --ci

      - name: Enforce diff size limit
        run: |
          FILES=$(git diff --name-only origin/main...HEAD | wc -l)
          if [ "$FILES" -gt 20 ]; then
            echo "Agent PR touches $FILES files — exceeds 20-file limit"
            exit 1
          fi

      - name: Block trust-boundary files
        run: |
          if git diff --name-only origin/main...HEAD | grep -qE \
            '^(\.github/workflows|secrets/|certs/|infra/)'; then
            echo "Agent PR touches a protected path — requires human author"
            exit 1
          fi

            # Bugbot si integra tramite GitHub webhook — configurare nel dashboard Cursor.
      # Per le PR scritte dagli agenti si raccomanda il livello di effort "high".

Il costo che non si è mosso

L'inferenza più economica aiuta esattamente dove l'articolo 3.0 diceva che gli agenti già funzionavano. Non fa nulla per la categoria in cui falliscono: decisioni architetturali, confini di sicurezza, consistenza cross-service, performance su larga scala. Questi fallimenti non sono priced in token. Un'assunzione architetturale sbagliata costa lo stesso da generare, che il modello sia Opus 4.7 o Composer-Standard, e costa molto di più di entrambi da rilevare e correggere. Abbassare il costo di generazione non tocca quella voce — la rende solo una quota maggiore del totale.

L'esperimento self-driving, letto con attenzione

La ricerca interna di Cursor è la migliore evidenza dei limiti. Nel febbraio 2026 il team ha pubblicato "Towards self-driving codebases," descrivendo un sistema multi-agente interno che ha girato per una settimana continua con un picco di ~1.000 commit all'ora attraverso centinaia di agenti e 10 milioni di tool call, senza intervento umano una volta avviato. Il progetto: costruire un browser web da zero. È un risultato genuinamente notevole (Cursor, 2026b).

Ma, letto con attenzione, è anche l'argomento più forte a favore della tesi del 3.0 — per via dei trade-off che Cursor ha dovuto fare per raggiungere quel throughput:

Mille commit all'ora è una velocità di generazione. La policy di correttezza rilassata è la tassa di verifica resa esplicita. Il muro dell'I/O su disco è un promemoria che il build system e la struttura del monorepo sono ora infrastruttura critica per le performance degli agenti, non solo per gli sviluppatori umani. Portare la generazione verso l'infinito non riduce queste tre cose — le rende l'intero lavoro.

I cambiamenti strutturali sotto il modello

Tre cambiamenti nelle sei settimane contano più per l'adozione enterprise dei numeri benchmark.

Bugbot: la review fatturata a utilizzo

Bugbot è passato dall'abbonamento alla fatturazione a utilizzo — con effetto al prossimo rinnovo dopo l'8 giugno per i clienti esistenti (Cursor, 2026c). Il piano da $40/seat/mese viene sostituito da un prezzo per esecuzione con livelli di effort configurabili.

Non è una nota a margine sui prezzi — è Cursor che monetizza la review come servizio a consumo. L'azienda che vende il motore di generazione vende ora anche il motore di verifica, a esecuzione. Letto rispetto a dove si trova il vero collo di bottiglia, è una scommessa lucida su dove andrà la spesa.

Cloud agent: ambienti reali, non sandbox

I cloud agent della 3.4 girano in ambienti reali con la topologia di deployment effettiva, non in sandbox che la approssimano. Configurazione basata su Dockerfile, supporto multi-repo, storico delle versioni dell'ambiente con rollback e segreti limitati alla build significano che un agente può operare contro il proprio stack reale. Aspetto cruciale: i segreti di build sono limitati al passo di build e non raggiungono mai l'agente in esecuzione — il che chiude il foot-gun più comune nell'infra per agenti, ovvero una chiave API incorporata in un container in esecuzione.

# Stage di build: i segreti sono disponibili qui via --mount, non nell'immagine finale
FROM node:22-slim AS builder
WORKDIR /app
COPY package*.json ./

# Il segreto è montato solo al momento della build — mai scritto in un layer
RUN --mount=type=secret,id=NPM_TOKEN \
    NPM_TOKEN=$(cat /run/secrets/NPM_TOKEN) npm ci

COPY . .
RUN npm run build

# Stage di runtime: solo l'artifact compilato, zero credenziali di build
FROM node:22-slim AS runner
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules

# Il processo agente non ha accesso a NPM_TOKEN — non è mai stato scritto qui
CMD ["node", "dist/server.js"]

I report pratici sul caching sono positivi: le rebuild Dockerfile cached sono scese da circa nove minuti a meno di due quando cambia solo il layer applicativo, eliminando del tutto il loop Docker locale. Per un'organizzazione microservizi, il supporto multi-repo è lo sblocco chiave — un agente confinato a un solo repository non può ragionare sui servizi che una modifica reale attraversa. La scala di NVIDIA mostra cosa può supportare la piattaforma sottostante: 30.000 sviluppatori che usano Cursor, con 3× più codice committato su una codebase multi-repo estesa (Cursor, 2026d).

Governance: finalmente abbastanza per fare la differenza

Gli aggiornamenti enterprise del 4 maggio hanno aggiunto abbastanza controlli da rendere il "deployment governato" non più teorico. Le aggiunte chiave:

La superficie di fiducia si è espansa con le capacità

Ognuno di questi guadagni allarga ciò che un agente può toccare, e il modello di sicurezza sta ancora recuperando terreno. L'illustrazione più chiara è CVE-2026-26268, corretto nella versione 2.5 dell'applicazione Cursor.

I controlli di governance enterprise sopra descritti non sono finiture opzionali per un'organizzazione regolamentata — sono lo strato di mitigazione esattamente per questa classe di rischio. Postura pratica: bloccare le versioni e applicare le patch tempestivamente (il runtime per agenti ha rilasciato oltre dieci CVE nella finestra 2025–2026). Governare le connessioni MCP con approvazione esplicita per ogni server. Limitare le credenziali al passo di build. E trattare qualsiasi repository non redatto da sé stessi come input non fidato per l'agente, non solo per l'umano che lo legge.

Il "il giudizio resta costoso" dell'articolo 3.0 ha ora un corollario di sicurezza: anche i confini di fiducia restano costosi.

Il verdetto del senior engineer, aggiornato

La conclusione dell'articolo 3.0 era: delegare il lavoro meccanico agli agenti nei worktree, revisionare i diff puliti e mantenere stretto controllo sulle decisioni architetturali. Composer 2.5 acuisce quella conclusione invece di ribaltarla. Quando le esecuzioni degli agenti costano centesimi, la configurazione produttiva si sposta ulteriormente verso "genera molti candidati circoscritti, valuta selettivamente" — l'economia favorisce ora l'ampiezza di generazione in un modo che non faceva ad aprile.

Il dogfooding interno di Cursor è la prova del concetto. Il team riferisce che il 35% delle pull request merged internamente è ora scritto da agenti autonomi — ma all'interno di una CI solida, una cultura di code review e suite di test reali. Gli agenti lavorano all'interno del processo di sviluppo, non aggirarlo.

Quella precisazione è l'intera strategia. Dieci candidati economici sono dieci cose da revisionare, non una. Il conductor che sceglie il vincitore è esso stesso una superficie di giudizio che può sbagliare, e una selezione sbagliata fatta con sicurezza è più pericolosa di nessuna selezione. La generazione più economica rende la parte iniziale della pipeline più veloce e la parte finale più occupata.

Il vero vincolo

Composer 2.5 è la cosa più importante che Cursor abbia rilasciato dal rewrite 3.0, e cambia la matematica dei costi in modo reale e verificato indipendentemente. Non cambia la conclusione. La generazione è diventata un ordine di grandezza più economica — nel tier Standard. Il giudizio non è diventato affatto più economico. Ce n'è solo di più da fare, e un confine di fiducia più ampio su cui farlo.