Le coût d’un workflow est son fan-out, et aucun des guides sur les workflows ne le mentionne. La documentation d’Anthropic est la source de référence pour apprendre ce que sont les workflows dynamiques et comment en écrire un. Cette page répond à la question qui vient immédiatement après : combien coûte l’exécution d’un workflow, et quel réglage modifie ce coût ?
En bref : un workflow qui se divise en cinq sous-agents consomme environ les tokens de cinq agents, pas ceux d’un seul. C’est son objectif, et c’est aussi ce qui est facturé.
Le calcul
# 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.Lisez ces trois configurations comme le même travail effectué de trois façons. Le fan-out est plus coûteux que le thread unique dans tous les cas ; ce qui change, c’est l’ampleur de l’écart, presque entièrement déterminée par le niveau sur lequel s’exécutent les sous-agents.
La seule ligne qui change le coût
Le travail d’un sous-agent dans un workflow est généralement limité et mécanique : lire un fichier, résumer un diff, vérifier une condition, faire un rapport. C’est précisément le rôle d’un petit modèle. L’orchestrateur est l’inverse : il conserve le plan, et un mauvais plan fait perdre du temps à tous les sous-agents qu’il dirige. C’est donc à cet endroit qu’un niveau puissant justifie son prix.
# 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 achemine automatiquement ses appels de sous-tâches vers le modèle associé au niveau Haiku ; ce mappage agit donc à chaque exécution, même sans workflows explicites. La ligne Opus est nécessaire parce que le modèle par défaut intégré à Claude Code et son alias opus pointent tous deux vers le dernier Opus ; si Kunavo ne propose pas encore ce modèle, tout ce qui y revient renvoie 404. La ligne fixe les deux sur Opus 5.5 (claude-opus-5-5), qui nécessite Claude Code v2.1.280 ou une version ultérieure (exécutez claude update avec une ancienne version). La ligne Sonnet est particulièrement importante pour les workflows : l’alias sonnet demande Sonnet 5.5, que Kunavo ne propose pas ; sans cette ligne, chaque sous-agent configuré avec model: sonnet, la phase d’exécution de opusplan et /model sonnet renvoie 404. Le seuil de rentabilité du niveau de l’orchestrateur — la dégradation qu’un modèle moins cher peut subir avant de ne plus être moins cher — est expliqué dans Opus vs Sonnet vs Haiku.
Deux éléments que l’estimation ne prendra pas en compte
Nouvelles tentatives. Un sous-agent qui échoue puis redémarre est facturé deux fois, et le fan-out augmente la probabilité qu’au moins un appel échoue. Ce coût est invisible dans toute estimation au moment de la planification et n’apparaît que dans l’historique d’utilisation.
Contexte mis en cache. Dans l’autre sens, les sous-agents lancés par un même orchestrateur partagent souvent un préfixe stable, et un accès au cache est facturé à une fraction du tarif d’entrée. Sur un workflow long, c’est la réduction individuelle la plus importante disponible — plus importante que le changement de niveau ci-dessus. Le mécanisme et les trois façons dont un routage via une passerelle peut le casser sont décrits dans la mise en cache des prompts Claude.
Décider s’il faut utiliser un fan-out
Les workflows ne sont pas une optimisation des coûts, et il est utile d’être clair sur ce point, car cette formulation détermine la réponse. Ils achètent de la latence et de l’étendue : plusieurs sous-agents travaillant simultanément terminent plus vite et couvrent davantage de terrain qu’un thread parcourant la même liste. La question est de savoir si cela justifie le multiple ; le calcul ci-dessus vous donne ce multiple pour votre propre configuration.
Pour la fonction elle-même — définir un workflow, orchestrer les sous-agents et utiliser la syntaxe — la documentation d’Anthropic fait autorité et cette page ne tente pas de la reproduire. Ce qui exécute les modèles sous-jacents est une base URL et une clé ; l’aspect abonnement contre facturation au token de la même décision est traité dans les limites de Claude Pro et Max.
Questions fréquentes
Combien coûte un workflow Claude Code ?
Davantage que le même travail dans un seul fil, car le coût d’un workflow dépend de sa dispersion. Modélisez-le comme la somme des étapes de l’orchestrateur et des sous-agents multipliés par leur nombre d’étapes, le tout multiplié par le coût d’une étape. Aux tarifs Kunavo, une étape de 25 000 tokens d’entrée et 1 200 tokens de sortie coûte $0.043 sur Claude Sonnet 5 : un fil unique de 20 étapes coûte environ $0.868, tandis que cinq sous-agents de huit étapes chacun, plus six étapes d’orchestrateur, représentent 46 étapes et environ $2.00. La dispersion apporte du parallélisme et de l’ampleur ; elle n’apporte pas de remise.
Comment rendre les workflows moins chers sans renoncer au fan-out ?
Placez le fan-out sur le niveau le moins cher et gardez l’orchestration sur un niveau puissant. Les sous-tâches d’un workflow sont généralement limitées et mécaniques — lire ceci, résumer cela, vérifier autre chose — ce qui correspond au rôle d’un petit modèle, tandis que l’orchestrateur conserve le plan et doit être fiable. En appliquant ce mappage au même exemple de 46 étapes, le coût est d’environ $1.13 au lieu de $2.00, et le changement consiste en une variable d’environnement plutôt qu’en une réécriture.
Les workflows valent-ils leur coût supérieur ?
Souvent oui, mais il faut les évaluer sur le bon axe. Un workflow n’est pas une optimisation des coûts, mais une optimisation de la latence et de l’étendue : plusieurs sous-agents travaillant simultanément terminent plus vite et couvrent davantage de terrain qu’un seul thread effectuant le même travail en série. La question est de savoir si le parallélisme justifie le multiple, non de savoir si ce multiple existe — il existe, et toute page qui affirme le contraire n’a pas fait le calcul.
Quel modèle l’orchestrateur doit-il utiliser ?
L’orchestrateur établit le plan et lit les résultats ; c’est donc l’endroit où un modèle faible vous coûte le plus cher — un mauvais plan fait perdre du temps à tous les sous-agents qui en dépendent. Claude Sonnet 5 à $1.40 / $7.00 par 1M de tokens est le choix par défaut ; Claude Opus 5.5 à $2.80 / $14.00 justifie son prix pour les tâches réellement ambiguës. Le seuil de rentabilité en nombre de tentatives entre les formules figure sur la page de comparaison des niveaux.
Les workflows fonctionnent-ils via un endpoint API personnalisé ?
Oui : les workflows sont une fonction d’orchestration côté client ; ils s’exécutent donc partout où Claude Code s’exécute, et Claude Code lit nativement ANTHROPIC_BASE_URL. Chaque appel de sous-agent est envoyé au même endpoint que celui de l’orchestrateur. C’est aussi ce qui rend le coût visible au même endroit : le fan-out d’un workflow apparaît comme une série de requêtes dans une seule vue d’utilisation, plutôt que d’être réparti entre plusieurs comptes.
Comment voir ce qu’un workflow a réellement dépensé ?
Lisez le coût requête par requête au lieu de l’estimer à partir du plan, car le nombre d’étapes de sous-agents est décidé à l’exécution et correspond rarement à votre estimation. Avec une clé facturée au token, chaque appel du fan-out constitue une ligne que vous pouvez additionner, y compris les nouvelles tentatives produites par un sous-agent défaillant — elles sont facturées et invisibles dans toute estimation préalable.