Claude Code Projects: coordinatore, thread e limitazioni della beta

Anthropic ha recentemente riprogettato Projects in Claude Code. Ora è un’unica conversazione di coordinamento che avvia sessioni cloud parallele, i thread, per svolgere attività e riceve i loro resoconti. Vale la pena creare un progetto quando il tuo lavoro ha un obiettivo che durerà più di una singola sessione e genererà nuove attività, per esempio sviluppare un repository GitHub nell’arco di diverse settimane. La sola necessità di lavorare in parallelo non basta. Se devi correggere rapidamente un singolo file qui e ora, è sufficiente una normale sessione.

Il lavoro è guidato da un coordinatore, una conversazione di lunga durata in cui Claude decide quali parti del tuo messaggio trasformare in attività per un thread. I thread scrivono il codice: ciascuno è una sessione Claude Code separata nel cloud, sul proprio branch del repository. Più thread possono essere attivi contemporaneamente, ognuno con il proprio contesto e branch. Il coordinatore vede il resoconto del thread al termine, ma non ogni passaggio che compie. Ti segnala le pull request completate (richieste di unire le modifiche) e, su tua richiesta, chiede a un thread di rivederle o unirle. Di seguito trovi una panoramica basata sulla documentazione ufficiale di Anthropic: cosa configurare, come viene organizzato il lavoro e quali sono le limitazioni della beta.

La beta viene resa disponibile gradualmente, a partire dagli account Pro e Max che hanno già usato sessioni cloud di Claude Code e non hanno creato un progetto nella chat normale o in Cowork. Se la sezione Projects non è ancora visibile, puoi iscriverti alla lista d’attesa.

Che cos’è Claude Code Projects, in parole semplici#

Un progetto è un’unica conversazione di lunga durata con un coordinatore, a cui sono associati repository, memoria e istruzioni. Scrivi al coordinatore e sarà lui a decidere se rispondere subito o avviare un thread. Non devi aprire manualmente una nuova sessione per ogni attività.

Un thread è una sessione Claude Code completa nel cloud: ha un proprio contesto e un branch del repository e, quando serve, apre una pull request. Il coordinatore può tenere aperti più thread contemporaneamente, per esempio uno corregge un bug, un altro scrive test e un terzo aggiorna la documentazione, mentre risponde alle tue domande nella conversazione principale.

Per fare un confronto, immagina diverse schede con sessioni Claude Code locali, ciascuna nella propria copia di lavoro di un repository. Questa copia si chiama worktree, una cartella separata per un branch, così le sessioni locali non interferiscono tra loro. Sei tu a passare da una sessione all’altra e a decidere cosa assegnare a ciascuna. I thread cloud non hanno bisogno di un worktree: ogni thread clona i repository nel proprio ambiente cloud isolato. Projects si occupa del coordinamento e decide quando creare un nuovo thread e quando non è necessario.

Un progetto ha memoria e istruzioni condivise, che vengono fornite a ogni nuovo thread. La sezione sulla configurazione spiega cosa salvare al loro interno e come vengono passate ai thread.

In cosa si distingue da una normale sessione e da un team di agenti#

Se già esegui subagenti annidati all’interno di una singola sessione Claude Code, è utile distinguerli dai team di agenti e dai thread di progetto. Un team di agenti è un altro modo per delegare il lavoro: una sessione avvia sessioni di collaboratori per un’attività specifica. Puoi usarlo sia sul tuo computer sia all’interno di una sessione cloud.

• Team di agenti—sessioni di collaboratori per una singola attività specifica, avviabili in locale o nel cloud. Non sono thread di progetto separati.
• Un progetto e i suoi thread—il lavoro si svolge nel cloud. Ogni thread è una sessione separata sul proprio branch e continua a funzionare anche dopo che chiudi il portatile. Una sessione locale non può far parte di un progetto.
• Vista Agent—una schermata per osservare diverse sessioni locali sul tuo computer. Non ha un coordinatore: decidi tu cosa assegnare a ciascuna.

La documentazione ufficiale di Anthropic sottolinea un punto distinto: il solo lavoro parallelo non è un motivo per creare un progetto. In un progetto, Claude avvia le sessioni e ne riceve autonomamente i resoconti; inoltre, tutte le sessioni partono con repository, istruzioni e memoria condivisi. Per tutta la durata dell’attività, il lavoro rimane nel cloud.

Un approccio simile, in cui un coordinatore distribuisce le attività tra gli agenti, è implementato in un altro strumento, descritto nell’articolo su Cursor Projects. Il meccanismo è diverso, ma anche in questo caso il coordinatore decide a chi assegnare cosa.

Cosa configurare prima del primo progetto#

Prima di creare un progetto, controlla tre cose.

1. Account GitHub e Claude GitHub App. Se hai già collegato GitHub tramite /web-setup, quel token consente alle normali sessioni cloud di accedere al repository. Per i thread di progetto non è sufficiente: ti serve un account GitHub collegato con accesso in scrittura al repository e la Claude GitHub App installata per quel repository. Senza questi requisiti, un thread non può clonare il repository né aprire una pull request.

2. Istruzioni del progetto. Le istruzioni del progetto sono un testo fino a 16 000 caratteri, inviato a ogni nuovo thread e anche al coordinatore. Inserisci qui le informazioni che altrimenti dovresti ripetere in ogni sessione: la struttura del repository, le convenzioni per il codice e i controlli richiesti prima di una pull request.

3. Modello e livello di impegno. Per impostazione predefinita, un nuovo progetto usa il modello Opus con livello di impegno alto per ogni thread e livello basso per il coordinatore. La documentazione afferma che questa configurazione «consuma più rapidamente la disponibilità del tuo piano» (traduzione; originale: draws on your plan fastest). Se le tue attività sono semplici, puoi scegliere un modello meno costoso o ridurre il livello di impegno in Project settings > General. Le impostazioni dei thread e del coordinatore si modificano separatamente; la documentazione descrive opzioni più economiche.

La memoria del progetto è archiviata come normali file, con un file indice chiamato MEMORY.md. All’avvio, ogni nuovo thread lo legge e accede agli altri file quando necessario. Le scoperte di un thread salvate nella memoria diventano disponibili al successivo senza doverle ripetere.

Cosa fare se i thread modificano lo stesso codice#

Ogni thread lavora sul proprio branch e apre autonomamente una pull request se il lavoro lo richiede. Il coordinatore, però, non garantisce che le attività non si sovrappongano mai: se più thread finiscono per lavorare nella stessa area del codice, puoi chiedere al thread interessato di risolvere il conflitto tramite l’interfaccia. Accanto alla sua pull request c’è un pulsante Resolve conflicts che invia al thread un’istruzione come messaggio da parte tua.

La documentazione ufficiale suggerisce di specificare nelle istruzioni del progetto le preferenze sul numero di thread: per esempio, chiedere al coordinatore di avviarne al massimo due contemporaneamente oppure di riutilizzare un thread esistente per nuove attività nella stessa area. Si tratta di una preferenza che il coordinatore cerca di rispettare, non di un limite rigido. Da sola non garantisce che i thread non entrino in conflitto sullo stesso file: un conflitto esistente va risolto separatamente. Per attività correlate nella stessa area, puoi riutilizzare un thread attivo o inattivo. Se è rimasto inattivo per più di un’ora, quando riceve un nuovo messaggio rilegge l’intera cronologia, incidendo sul consumo della disponibilità dell’abbonamento.

Più le attività sono chiaramente suddivise per file o moduli, più è facile lavorare in parallelo. Un articolo a parte spiega come suddividere una grande attività in parti indipendenti: come delegare la programmazione a migliaia di agenti. La scala è diversa, ma il principio di suddividere il lavoro è lo stesso.

Finché la cache della conversazione è attiva (nei piani Pro e Max, entro un’ora, se i limiti del tuo piano lo consentono), un thread usa meno token della disponibilità dell’abbonamento per rielaborare la cronologia. Quando la cache scade, prima di iniziare a lavorare il thread rilegge l’intera cronologia dopo aver ricevuto un nuovo messaggio. Per una nuova attività indipendente, potrebbe essere più conveniente chiedere al coordinatore di creare un thread da zero: dopo la scadenza della cache, questo può consumare meno token della stessa disponibilità dell’abbonamento rispetto a continuare una vecchia sessione con una cronologia estesa.

Limitazioni della beta da conoscere in anticipo#

Prima di creare un progetto per un’attività importante, controlla le limitazioni della beta:

• Disponibile solo su Pro e Max. Team ed Enterprise non sono ancora supportati.
• Un limite di 200 nuovi thread al giorno per account, sommando tutti i progetti.
• Un progetto appartiene a un solo utente. Non puoi dare a un’altra persona accesso condiviso al progetto o a un singolo thread e la beta non dispone di impostazioni organizzative per i team.
• Accesso solo tramite claude.ai/code, l’app desktop e l’app mobile. Projects non funziona nel terminale CLI, tramite Amazon Bedrock, Google Cloud Agent Platform o Microsoft Foundry.
• Un progetto non può vedere file e strumenti locali. I thread lavorano con repository GitHub, file caricati e cartelle Google Drive, ma non con ciò che esiste soltanto sul tuo computer.

Se ti serve accedere al terminale o agli strumenti disponibili solo sul tuo computer, usa una sessione locale oppure Agent view per più sessioni di questo tipo. Se più persone devono collaborare in un unico spazio di lavoro, Anthropic offre un prodotto distinto per i team su Team ed Enterprise: Claude Tag. Si trova in un canale Slack: ogni membro può assegnare un’attività a Claude e tutte le persone nel canale possono vedere e dirigere il lavoro. Un progetto funziona diversamente: appartiene soltanto a te. Se ti servono solo determinati file locali, puoi caricarli nel progetto e ogni thread potrà accedervi. Questo non consente di accedere agli strumenti locali.

E adesso?#

Prima di trasferire il tuo flusso di lavoro a Projects, prova a creare un progetto di test in un repository non critico: collega la GitHub App, scrivi istruzioni brevi, assegna al coordinatore un’attività indipendente e osserva come la gestisce. Questa prima prova ti mostrerà se hai capito l’interfaccia del coordinatore e dei thread. Non permette di valutare il lavoro in parallelo, i conflitti o il consumo della disponibilità tra più attività: questi aspetti vanno testati separatamente.