Come funziona questa calcolatrice
UN singola conversazione cumulativa la gestione di N attività invia nuovamente la cronologia completa a ogni turno: l'input dell'attività i è contesto base + (i-1) × token di output precedente. Sommando N attività, il termine storico cresce come N × (N-1) / 2 - quadratico in N - anche se il lavoro di ciascuna attività ha dimensioni identiche. Fan-out verso subagenti isolati fornisce a ogni attività un nuovo contesto: contesto di base + attività, oltre a un prompt di invio fisso dell'orchestratore per avviarlo e l'output del subagente riletto come input dell'orchestratore. Questo sovraccarico è per attività, non cumulativo, quindi la scala totale del fan-out linearmente in N, più una fase finale di sintesi.
Ai valori predefiniti (20 attività, 4.000 token di contesto di base, 1.200 token di output/attività, invio di 300 token, prezzi di classe Sonnet), il termine della cronologia a thread singolo da solo aggiunge circa 19×20/2 = 190 blocchi extra di "output precedente" di 1.200 token all'input delle attività successive: un costo a thread singolo che il fan-out semplicemente non accumula mai. La N piccola favorisce il thread singolo poiché evita il sovraccarico di invio/acquisizione; la tabella di scansione mostra esattamente dove si trova il crossover del carico di lavoro.
Domande frequenti
Perché una singola lunga conversazione diventa più costosa per attività man mano che procede?
Poiché la maggior parte delle API di completamento della chat sono stateless, ogni turno invia nuovamente la cronologia completa delle conversazioni come token di input. L'attività 1 invia solo il contesto di base. L'attività 20 invia il contesto di base più l'output delle attività 1-19. Quel termine storico cresce con ogni attività, quindi i token di input totali su N attività scalano come N*(N-1)/2 – quadratico in N – anche se il lavoro di ogni singola attività ha la stessa dimensione.
Perché il fan-out verso subagenti isolati evita tale crescita?
Ogni subagente ottiene una nuova finestra di contesto: il proprio contesto di base più la sua attività, niente dalle altre attività N-1. L'orchestratore paga solo per una breve richiesta di invio per avviare ciascun agente secondario e un breve riepilogo per rileggere ciascun risultato. Tale sovraccarico è fisso per attività, quindi il costo totale scala linearmente con N anziché quadraticamente. Il compromesso è il sovraccarico di invio/acquisizione stesso dell'orchestratore, motivo per cui il fan-out non è automaticamente più economico a N molto piccoli.
A quale conteggio delle attività il fan-out inizia a vincere?
Dipende da quanto è grande l'output per attività rispetto al sovraccarico di invio/acquisizione dell'orchestratore: output più grandi rendono più veloce il fumetto del termine della cronologia a thread singolo, abbassando il punto di crossover su un N più piccolo. Utilizza la tabella di scansione seguente con il tuo contesto di base, dimensione di output e sovraccarico dell'orchestratore per trovare il crossover esatto invece di fare affidamento su una regola empirica.
Questo si applica allo stesso modo ai subagenti di Claude Code, LangGraph o CrewAI?
La matematica di base è la stessa per qualsiasi framework in cui un orchestratore invia lavoratori in un contesto isolato e raccoglie brevi risultati: subagenti di Claude Code, sottografi di LangGraph, team di CrewAI o un ciclo di fan-out lanciato a mano. Ciò che differisce tra i framework è l'esatto invio e il sovraccarico di acquisizione per subagente, motivo per cui qui si tratta di input separati anziché codificati.