Il costo di un workflow è il suo fan-out, ma nessuna guida sui workflow ne parla. La documentazione di Anthropic è il posto giusto per capire cosa sono i workflow dinamici e come scriverne uno. Questa pagina risponde alla domanda che ti viene subito dopo: quanto costa eseguirne uno e quale impostazione modifica il costo.
In breve: un workflow che distribuisce il lavoro a cinque subagent consuma all'incirca token equivalenti a cinque agenti, non a uno. È questo lo scopo del fan-out, ed è anche ciò che paghi.
I calcoli
# A workflow's cost is not "one task". It is the fan-out.
#
# workflow_cost = orchestrator_steps x step_cost
# + subagents x subagent_steps x step_cost
#
# A step is 25,000 in / 1,200 out — the same sizing used on
# every other cost page here, so these numbers are comparable.
#
# Claude Sonnet 5 $0.043 / step
# Claude Haiku 4.5 $0.022 / step
#
# Same job, three shapes:
#
# one thread, 20 steps, all Sonnet
# = 20 x $0.043 = $0.868
#
# 5 subagents x 8 steps + 6 orchestrator steps, all Sonnet
# = 46 x $0.043 = $2.00
#
# same fan-out, subagents on Haiku, orchestrator on Sonnet
# = 40 x $0.022 + 6 x $0.043 = $1.13
#
# The fan-out costs more than the single thread. Mapping the fan-out
# to the cheap tier is what buys most of it back.Leggi le tre configurazioni come lo stesso lavoro svolto in tre modi. Il fan-out è più costoso del thread singolo in ogni caso; ciò che cambia è di quanto, e questo dipende quasi interamente dal tier su cui vengono eseguiti i subagent.
L'unica riga che lo modifica
Il lavoro dei subagent in un workflow è solitamente circoscritto e meccanico: leggere un file, riassumere un diff, verificare una condizione, riferire il risultato. È questo il tipo di lavoro per cui serve un modello piccolo. L'orchestratore è l'opposto: mantiene il piano, e un piano sbagliato spreca il lavoro di tutti i subagent sottostanti; è quindi lì che un tier potente giustifica il prezzo.
# The one line that changes every workflow run: the tier the
# background and sub-task work lands on.
export ANTHROPIC_BASE_URL=https://api.kunavo.com
export ANTHROPIC_AUTH_TOKEN=sk-kn-...
export ANTHROPIC_MODEL=claude-sonnet-5 # orchestration
export ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-5-5 # agents that ask for opus
export ANTHROPIC_DEFAULT_SONNET_MODEL=claude-sonnet-5 # agents that ask for sonnet
export ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5 # the fan-outClaude Code instrada automaticamente le chiamate ai sottocompiti verso ciò che è associato al livello Haiku, quindi questa mappatura viene utilizzata a ogni esecuzione, anche se non usi esplicitamente i workflow. La riga Opus è necessaria perché il modello predefinito integrato di Claude Code e il suo alias opus puntano entrambi all’Opus più recente; se Kunavo non offre ancora quel modello, tutto ciò che vi ricade restituisce 404. La riga fissa entrambi su Opus 5.5 (claude-opus-5-5), che richiede Claude Code v2.1.280 o successivo (nelle versioni precedenti esegui claude update). La riga Sonnet è ancora più importante per i workflow: l’alias sonnet richiede Sonnet 5.5, che Kunavo non offre; senza questa impostazione restituiscono 404 tutti i subagenti configurati come model: sonnet, la fase di esecuzione di opusplan e /model sonnet. Il punto di pareggio per il livello dell’orchestratore — quanto deve essere peggiore un modello più economico prima di smettere di essere più economico — è spiegato in Opus vs Sonnet vs Haiku.
Due elementi che la stima non considera
Nuovi tentativi. Se un subagent fallisce e viene eseguito di nuovo, viene addebitato due volte; il fan-out aumenta la probabilità che almeno uno fallisca. Questo non compare in nessuna stima fatta al momento della pianificazione e si vede solo nel registro di utilizzo.
Contesto memorizzato nella cache. Dall'altra parte, i subagent avviati dallo stesso orchestratore condividono spesso un prefisso stabile, e un hit della cache viene fatturato a una frazione della tariffa di input. In un workflow lungo, questa è la maggiore riduzione singola disponibile, superiore al cambio di tier descritto sopra. Il meccanismo e i tre modi in cui il routing attraverso un gateway lo interrompe sono spiegati in Claude prompt caching.
Decidere se usare il fan-out
I workflow non sono un'ottimizzazione dei costi, ed è importante chiarirlo perché l'inquadramento determina la risposta. Offrono latenza e ampiezza: diversi subagent che lavorano contemporaneamente finiscono prima e coprono più terreno di un singolo thread che procede attraverso lo stesso elenco. La domanda è se questo valga il multiplo; i calcoli sopra indicano il multiplo per il tuo caso.
Per la funzione in sé — come definire un workflow, come vengono orchestrati i subagent e quale sia la sintassi — la documentazione di Anthropic è autorevole e questa pagina non cerca di ripeterla. Ciò che esegue i modelli sottostanti è un URL di base e una chiave; il lato della decisione tra abbonamento e token è trattato in Claude Pro e limiti Max.
Domande frequenti
Quanto costa un workflow Claude Code?
Più dello stesso lavoro in un singolo thread, perché il costo di un workflow dipende dal suo fan-out. Modellalo come passaggi dell’orchestratore più il numero di subagenti moltiplicato per i loro passaggi, il tutto moltiplicato per il costo di un passaggio. Alle tariffe Kunavo, un passaggio con 25.000 token di input e 1.200 di output costa $0,043 su Claude Sonnet 5: un singolo thread di 20 passaggi costa circa $0,868, mentre cinque subagenti da otto passaggi ciascuno più sei passaggi dell’orchestratore equivalgono a 46 passaggi e circa $2,00. Il fan-out offre parallelismo e ampiezza; non offre uno sconto.
Come posso rendere più economici i workflow senza rinunciare al fan-out?
Assegna il fan-out al tier più economico e mantieni l'orchestrazione su un tier potente. I sottocompiti di un workflow sono solitamente circoscritti e meccanici — leggi questo, riassumi quello, controlla l'altro — proprio il tipo di lavoro adatto a un modello piccolo, mentre l'orchestratore mantiene il piano e deve essere preciso. Mappando allo stesso modo l'esempio di 46 passaggi, il costo è circa $1,13 invece di $2,00; la modifica consiste in una variabile d'ambiente, non in una riscrittura.
I workflow valgono la pena se costano di più?
Spesso sì, ma decidi sulla base corretta. Un workflow non è un'ottimizzazione dei costi, bensì un'ottimizzazione di latenza e ampiezza: diversi subagent che lavorano contemporaneamente finiscono prima e coprono più terreno di un singolo thread che svolge lo stesso lavoro in serie. La domanda è se il parallelismo valga il multiplo, non se il multiplo esista: esiste, e qualsiasi pagina che affermi il contrario non ha fatto i calcoli.
Quale modello dovrebbe usare l'orchestratore?
L’orchestratore prepara il piano e legge i risultati, quindi è il punto in cui un modello debole ti costa di più: un piano sbagliato spreca il lavoro di tutti i subagenti sottostanti. Claude Sonnet 5 a $1,40 / $7,00 per 1M di token è il modello predefinito operativo; Claude Opus 5.5 a $2,80 / $14,00 vale il prezzo per attività realmente ambigue. Il punto di pareggio nel numero di tentativi tra i livelli è riportato nella pagina di confronto dei livelli.
I workflow funzionano tramite un endpoint API personalizzato?
Sì: i workflow sono una funzione di orchestrazione lato client, quindi funzionano ovunque funzioni Claude Code, che legge nativamente ANTHROPIC_BASE_URL. Ogni chiamata dei subagent raggiunge lo stesso endpoint dell'orchestratore; per questo il costo è visibile in un unico punto: il fan-out di un workflow appare come un picco di richieste in un'unica vista di utilizzo, invece di essere distribuito tra più account.
Come posso vedere quanto ha speso realmente un workflow?
Leggilo per richiesta invece di stimarlo dal piano, perché il numero di passaggi dei subagent viene deciso a runtime e raramente coincide con la tua previsione. Con una chiave a consumo per token, ogni chiamata del fan-out è una riga da sommare, inclusi i tentativi ripetuti generati da un subagent che ha fallito: vengono addebitati e non compaiono in nessuna stima anticipata.