Skip to main content
Les workflows dynamiques sont disponibles sur tous les plans payants, avec accès à l’API Anthropic, et sur Amazon Bedrock, Google Cloud’s Agent Platform et Microsoft Foundry. Sur Pro, activez-les à partir de la ligne Dynamic workflows dans /config.
Un workflow dynamique est un script JavaScript qui orchestre de nombreux sous-agents à la fois. Claude écrit le script pour la tâche que vous décrivez, et un runtime l’exécute en arrière-plan tandis que votre session reste réactive. Utilisez un workflow quand une tâche nécessite plus d’agents qu’une seule conversation ne peut en coordonner, ou quand vous voulez que l’orchestration soit codifiée sous forme de script que vous pouvez lire et relancer. Les exemples incluent un balayage de bugs à l’échelle de la base de code, une migration de 500 fichiers, une question de recherche qui nécessite une vérification croisée des sources les unes par rapport aux autres, et un plan difficile qui vaut la peine d’être rédigé sous plusieurs angles indépendants avant de vous engager sur l’un d’eux.

​
Quand utiliser un workflow

Les sous-agents, les skills, les équipes d’agents et les workflows peuvent tous exécuter une tâche multi-étapes. La différence réside dans qui détient le plan : Un workflow déplace le plan dans le code. Avec les sous-agents, les skills et les équipes d’agents, Claude est l’orchestrateur : il décide tour par tour ce qu’il faut générer ou assigner ensuite, et chaque résultat atterrit dans une fenêtre de contexte. Un script de workflow détient la boucle, la ramification et les résultats intermédiaires eux-mêmes, donc le contexte de Claude ne contient que la réponse finale. Déplacer le plan dans le code permet également à un workflow d’appliquer un modèle de qualité répétable, pas seulement d’exécuter plus d’agents : il peut avoir des agents indépendants qui examinent adversarialement les conclusions les uns des autres avant qu’elles ne soient rapportées, ou rédiger un plan sous plusieurs angles et les peser les uns par rapport aux autres, afin que vous obteniez un résultat plus fiable qu’une seule passe.

​
Exécuter un workflow groupé

Le moyen le plus rapide de voir un workflow en action est d’exécuter /deep-research, le workflow intégré que Claude Code inclut pour enquêter sur une question à travers de nombreuses sources. Vous verrez les agents travailler à travers un ensemble de phases en arrière-plan tandis que votre session reste libre, et vous obtiendrez un rapport à la fin au lieu d’une transcription tour par tour.
1

Exécuter le workflow

Exécutez /deep-research avec une question que vous souhaitez enquêter. Il déploie des recherches web selon plusieurs angles, récupère et vérifie les sources qu’il trouve, et synthétise un rapport cité.
2

Autoriser les workflows

Claude Code demande s’il faut autoriser le workflow. Sélectionnez Oui pour continuer. La demande de permission exacte dépend de votre mode de permission. Voir Approuver le plan avant son exécution pour les options par mode.
3

Surveiller la progression

L’exécution démarre en arrière-plan. Exécutez /workflows pour ouvrir sa vue de progression :
Si /workflows affiche plutôt une liste d’exécutions, sélectionnez celle que vous venez de lancer et appuyez sur Entrée. La vue affiche chaque phase avec son nombre d’agents. Explorez n’importe quelle phase pour voir ses agents et ce que chacun a trouvé. Voir Surveiller l’exécution pour l’ensemble complet des contrôles.Vous pouvez également surveiller à partir du panneau des tâches sous la zone de saisie : un résumé de progression d’une ligne apparaît là pendant que l’exécution est en cours. Appuyez sur la flèche vers le bas pour le mettre au point, puis sur Entrée pour le développer.
4

Lire le rapport

Lorsque l’exécution se termine, le rapport arrive dans votre session. Il cite les sources dont provient chaque affirmation, les affirmations qui n’ont pas survécu à la vérification croisée étant déjà filtrées.Lorsque les agents vérificateurs ne peuvent pas vérifier une affirmation, par exemple après une limite de débit ou une erreur API, le rapport liste cette affirmation comme non vérifiée au lieu de la compter comme réfutée.
Pour exécuter un workflow pour votre propre tâche, demandez à Claude d’en écrire un, et une fois qu’une exécution fait ce que vous vouliez, vous pouvez l’enregistrer comme commande de votre choix.

​
Workflows groupés

Claude Code inclut /deep-research comme workflow intégré : /deep-research s’exécute uniquement lorsque vous l’invoquez. Les workflows que vous enregistrez vous-même deviennent des commandes de la même manière et apparaissent dans l’autocomplétion / aux côtés des workflows groupés.

​
Surveiller l’exécution

Les workflows s’exécutent en arrière-plan, de sorte que la session reste réactive pendant que les agents travaillent. Exécutez /workflows à tout moment pour lister les workflows en cours d’exécution et terminés, puis sélectionnez-en un pour ouvrir sa vue de progression. Lorsque la session ne comporte qu’une seule exécution, /workflows ignore la liste et ouvre directement cette exécution. Pour arrêter un workflow en cours d’exécution depuis la liste sans l’ouvrir, sélectionnez-le et appuyez sur x. La vue de progression affiche chaque phase avec ses nombres d’agents. Le pied de page liste la clé pour chaque action : Le détail de l’agent liste l’invite de l’agent, ses appels d’outils récents et son résultat. Chaque appel affiche son état, par exemple toujours en cours d’exécution ou échoué. Lorsque l’agent maintient sa propre liste de tâches, le détail l’affiche également, avec le statut de chaque tâche. Appuyez sur Entrée pour développer le détail. L’invite et le résultat s’affichent alors en intégralité, et chaque appel listé affiche son entrée et le début de son résultat.

​
Faire écrire un workflow par Claude

Vous pouvez faire écrire un workflow par Claude pour votre tâche de deux façons : Vous pouvez également exécuter une commande de workflow qui existe déjà : un workflow groupé comme /deep-research, ou un que vous avez enregistré.

​
Demander un workflow dans votre prompt

Pour exécuter une seule tâche en tant que workflow sans modifier le niveau d’effort de la session, incluez le mot clé ultracode dans votre prompt. Demander avec vos propres mots, par exemple « utiliser un workflow » ou « exécuter un workflow », fonctionne également : Claude traite une demande directe comme le même opt-in.
Claude Code met en évidence le mot clé dans votre saisie et Claude écrit un script de workflow pour la tâche au lieu de la traiter tour par tour. Le mot clé choisit uniquement la façon dont Claude structure le travail : les appels d’outils des agents reçoivent les mêmes vérifications de permission et sandboxing que tout autre appel d’outil de la session. Si l’exécution fait ce que vous vouliez, vous pouvez l’enregistrer comme commande après. Si vous avez déjà un orchestrateur construit d’une autre façon, comme un dossier de prompts de sous-agents ou une compétence qui distribue le travail, vous pouvez pointer Claude vers celui-ci et demander un workflow qui fait la même chose.

​
Ignorer ou désactiver le mot clé

Si vous ne vouliez pas démarrer un workflow, appuyez sur Option+W sur macOS ou Alt+W sur Windows et Linux pour ignorer la mise en évidence pour ce prompt, ou appuyez sur retour arrière tandis que le curseur se trouve juste après le mot clé en évidence. Pour empêcher le mot clé de déclencher quoi que ce soit, désactivez le déclencheur de mot clé Ultracode dans /config.

​
Où le mot clé fonctionne

Le mot clé est un opt-in uniquement dans un prompt que vous tapez vous-même : à l’invite interactive, dans un panneau d’extension IDE, dans un client Remote Control, ou dans une application Agent SDK qui marque l’origin de votre saisie clavier comme { kind: "human" }. Il ne démarre pas un workflow quand il atteint la session d’une autre façon :
  • un prompt passé avec -p
  • un prompt qu’une application Agent SDK envoie sans le marquer comme saisie humaine
  • un prompt de tâche planifiée
  • une charge utile webhook ou un commentaire de pull request relayé dans la conversation
Avant la v2.1.210, le mot clé démarrait un workflow à partir de n’importe lequel de ces itinéraires également, y compris une charge utile webhook ou un commentaire de pull request relayé dans la conversation.

​
Laisser Claude décider avec ultracode

Ultracode est un paramètre Claude Code qui active l’orchestration automatique des workflows pour la session, au niveau d’effort auquel la session s’exécute. Avec lui activé, Claude planifie un workflow pour chaque tâche substantielle au lieu d’attendre que vous le demandiez. Activez-le à l’invite Claude Code :
Pour démarrer une session avec ultracode déjà activé, lancez avec claude --effort ultracode, ce qui définit également le niveau d’effort sur xhigh. Nécessite Claude Code v2.1.203 ou ultérieur. Pour l’activer à partir du curseur /effort, appuyez sur Tab pour basculer le bouton Ultracode, puis Entrée pour l’appliquer. Ajuster le niveau d’effort énumère les itinéraires qui activent ultracode. Avec ultracode activé, Claude décide quand une tâche justifie un workflow. Une seule demande peut se transformer en plusieurs workflows d’affilée : un pour comprendre le code, un pour faire le changement, et un pour le vérifier. Cela s’applique à chaque tâche de la session, donc chaque demande utilise plus de tokens et prend plus de temps que la même demande sans workflow. Sur un plan d’abonnement, ces tokens sont prélevés sur vos limites d’utilisation, donc une session avec ultracode activé atteint une limite de session ou hebdomadaire plus tôt que le même travail avec lui désactivé. L’activation d’ultracode vous inscrit déjà aux exécutions volumineuses, donc ces vérifications ne s’appliquent pas pendant qu’il est activé : /effort ultracode dure pour la session actuelle ; pour que chaque session commence avec lui, définissez le paramètre ultracode. Désactivez-le avec /effort ultracode off quand vous retournez au travail de routine. Le curseur /effort l’offre uniquement quand ultracode est disponible.

​
Approuver le plan avant qu’il s’exécute

Dans le CLI, l’invite par exécution affiche les phases planifiées et ces options :
  • Oui, l’exécuter : démarrer l’exécution
  • Oui, et ne pas demander à nouveau pour <name> dans <path> : démarrer, et ignorer cette invite pour ce workflow dans ce projet à partir de maintenant. Claude Code offre cette option quand vous exécutez un workflow groupé, enregistré, ou plugin par nom, pas pour un script que Claude a écrit pour la tâche actuelle.
  • Afficher le script brut : lire le script avant de décider
  • Non : annuler
Ctrl+G ouvre le script dans votre éditeur. Avec Oui, l’exécuter ou Non sélectionné, appuyez sur Tab pour ajouter un commentaire à votre réponse. Que vous voyiez cette invite dépend de votre mode de permission : Dans claude -p et l’Agent SDK, Claude Code ne montre jamais cette invite. Il exécute l’appel d’outil Workflow à travers la même évaluation de permission que le reste de la session, donc les règles de refus, les règles de demande, et le mode dontAsk s’appliquent au lancement comme ils s’appliquent à chaque appel d’outil. Pour laisser le workflow démarrer dans ces exécutions, utilisez l’un de ceux-ci :
  • Règle de permission : Workflow dans vos règles d’autorisation approuve chaque workflow, et Workflow(<name>) approuve un workflow enregistré par nom.
  • Mode de permission auto : le classificateur examine l’appel et peut l’approuver.
  • Mode de permission contourner les permissions : Claude Code approuve l’appel.
  • Un hook : un hook PreToolUse qui autorise l’appel l’approuve.
  • Votre hôte : un --permission-prompt-tool ou, avec l’Agent SDK, un callback canUseTool l’approuve.
Dans l’application Desktop, une carte d’approbation affiche le nom du workflow, la liste des phases, et une mise en garde sur l’utilisation des tokens, avec les actions Une fois, Toujours, et Refuser. La vue de progression apparaît dans le volet des tâches en arrière-plan. Les sous-agents que le workflow génère utilisent vos règles de permission, et Claude Code choisit leur mode de permission selon les règles sous quel mode de permission un sous-agent s’exécute dans. Pour éviter les invites lors d’une exécution longue, ajoutez les outils dont les agents ont besoin à vos règles d’autorisation avant de commencer.

​
Enregistrer le workflow pour réutilisation

Quand Claude écrit un workflow pour une tâche que vous répéterez, vous pouvez enregistrer le script de cette exécution comme commande. Un processus comme une revue que vous exécutez sur chaque branche exécute ensuite la même orchestration à chaque fois. Exécutez /workflows, sélectionnez l’exécution que vous voulez conserver, et appuyez sur s. Dans la boîte de dialogue d’enregistrement, Tab bascule entre les deux emplacements d’enregistrement :
  • .claude/workflows/ dans votre projet : partagé avec tous ceux qui clonent le repo
  • ~/.claude/workflows/ dans votre répertoire personnel : disponible dans chaque projet, visible uniquement pour vous. Si vous définissez CLAUDE_CONFIG_DIR, cet emplacement est le répertoire workflows/ sous ce chemin.
La boîte de dialogue d’enregistrement affiche le chemin résolu pour l’emplacement personnel. Appuyez sur Entrée pour enregistrer. Le workflow s’exécute comme /<name> dans les futures sessions à partir de l’un ou l’autre emplacement. Claude Code vérifie l’emplacement d’enregistrement pour les liens symboliques avant d’écrire, et affiche une erreur au lieu d’écrire à travers un. Ce qu’il vérifie dépend de l’endroit où vous enregistrez :
  • Emplacement du projet : Claude Code refuse si .claude, .claude/workflows, ou le fichier cible est un lien symbolique.
  • Emplacement personnel : Claude Code refuse uniquement si le fichier cible lui-même est un lien symbolique, donc un répertoire ~/.claude géré par un outil dotfiles fonctionne toujours.
Avant la v2.1.216, Claude Code suivait le lien, ce qui pouvait placer le fichier en dehors de l’emplacement que vous aviez choisi. Dans un monorepo avec plusieurs répertoires .claude/, vous pouvez conserver les workflows aux côtés du package auquel ils s’appliquent. L’enregistrement à l’emplacement du projet écrit dans le répertoire .claude/workflows/ le plus proche qui existe déjà entre votre répertoire de travail et la racine du référentiel, ou à la racine du référentiel s’il n’en existe pas encore. Les workflows de projet se chargent également à partir de chaque .claude/workflows/ le long de ce chemin, et quand plus d’un définit le même nom, Claude Code exécute celui le plus proche du répertoire de travail. Si un workflow de projet et un workflow personnel partagent un nom, celui du projet s’exécute.

​
Distribuer un workflow dans un plugin

Pour partager un workflow entre les équipes ou les référentiels, incluez-le dans un plugin. Placez le script dans un répertoire workflows/ à la racine du plugin, ou pointez vers un emplacement différent avec le champ de manifeste workflows. Les workflows de plugin sont espacés de noms par le nom du plugin. Un plugin appelé acme-tools contenant un script dont meta.name est release-audit s’exécute comme /acme-tools:release-audit.

​
Passer une entrée à un workflow enregistré

Un workflow enregistré peut accepter une entrée via le paramètre args. Le script la lit comme une variable globale nommée args. Utilisez ceci pour fournir une question de recherche, une liste de chemins cibles, ou un objet de configuration au moment de l’invocation au lieu de modifier le script pour chaque exécution. L’invite suivante exécute un workflow enregistré avec une liste de numéros de problème :
Claude passe la liste en tant que données structurées, donc le script peut appeler les méthodes de tableau et d’objet sur args directement sans l’analyser d’abord. Si args est omis, la variable globale est undefined à l’intérieur du script.

​
Exemples de prompts de workflow

Un workflow convient mieux quand la tâche est plus grande qu’un agent ne peut la tenir en contexte, ou quand la même étape doit s’exécuter sur de nombreux éléments. Les prompts ci-dessous montrent des formes courantes. Chacun demande à Claude d’écrire et d’exécuter un workflow pour cette tâche ; vous n’écrivez pas le script vous-même.

​
Auditer de nombreux fichiers pour le même problème

Distribuez un agent par fichier, puis collectez et vérifiez les conclusions.

​
Continuer à corriger jusqu’à ce qu’une vérification réussisse

Exécutez un vérificateur, corrigez ce qui a échoué, et répétez jusqu’à ce qu’il réussisse ou cesse de faire des progrès.

​
Migrer de nombreux fichiers en parallèle

Découvrez les fichiers à migrer, transformez chacun dans une copie isolée afin que les modifications ne se chevauchent pas, et vérifiez chaque résultat.

​
Examiner chaque fichier modifié et écrire un résumé

Exécutez un examinateur par fichier, puis remettez toutes les conclusions à un agent qui les classe et les déduplique.

​
Rechercher un sujet à travers de nombreuses sources

Distribuez les lecteurs sur les journaux des modifications, les problèmes et la documentation, puis synthétisez. Le workflow groupé /deep-research fait cela ; vous pouvez également décrire une version plus étroite.

​
Trouver des problèmes jusqu’à ce que la liste cesse de croître

Continuez à chercher par rounds et arrêtez-vous quand les nouveaux rounds ne trouvent rien de nouveau.

​
À quoi ressemble le script enregistré

Quand vous enregistrez un workflow, le fichier dans .claude/workflows/ contient un bloc meta suivi d’un corps de script qui orchestre les sous-agents. Vous n’avez généralement pas besoin de l’éditer, mais voici la forme d’un petit pour que vous puissiez reconnaître ce que Claude a généré :
Le corps est du JavaScript simple avec await au niveau supérieur. agent() génère un sous-agent, pipeline() en exécute un par élément dans une liste, et parallel() exécute un ensemble de tâches d’agent en même temps et attend que toutes se terminent. Un appel agent() se résout en null si vous l’arrêtez en cours d’exécution ou s’il rencontre une erreur API irrécupérable. pipeline() conserve chaque null dans le tableau des résultats, c’est pourquoi l’exemple se termine par .filter(Boolean) pour supprimer ces entrées, y compris l’emplacement d’un agent qui s’est bloqué à chaque tentative. En mode auto, le prompt que votre script transmet à agent() ne compte pas comme une demande de votre part quand le classificateur examine les actions de ce sous-agent, car Claude Code le marque comme du texte que le script a calculé. Si vous passez un schema sur un appel agent(), ce sous-agent retourne du JSON correspondant à la forme au lieu de prose. Claude Code vérifie le schéma avant de démarrer le sous-agent : quand il peut prouver que le schéma se contredit lui-même, l’appel échoue avec une erreur nommant la contradiction, et le sous-agent ne démarre jamais. Une contradiction qu’il peut prouver est une clé required que additionalProperties: false exclut. Si la sortie du sous-agent échoue toujours la validation après cinq tentatives, l’appel échoue avec une erreur qui inclut l’échec de validation le plus récent. Pour modifier le nombre de tentatives, définissez MAX_STRUCTURED_OUTPUT_RETRIES.

​
Éditer un script enregistré

Pour modifier un workflow que vous avez enregistré, éditez son fichier .js ou demandez à Claude de faire le changement. Avant d’éditer ou de demander, exécutez la compétence groupée /workflow-authoring pour charger la référence de rédaction de script sur laquelle Claude travaille. La compétence nécessite Claude Code v2.1.248 ou ultérieur. Pour exécuter la version éditée dans la session actuelle, exécutez /reload-skills pour relire les répertoires de workflow, puis exécutez /<name> à nouveau. Claude Code applique ces règles à chaque partie du fichier quand il charge et exécute le script :
  • Bloc meta : gardez export const meta comme première instruction, et gardez-le un objet littéral simple avec un name et une description. S’il contient autre chose que des valeurs littérales, comme une variable, un appel de fonction ou une propagation, Claude Code supprime /<name> de l’autocomplétion /.
  • Corps : en plus de agent(), pipeline() et parallel(), vous pouvez appeler phase() pour regrouper les agents qui suivent sous un titre dans la vue de progression, appeler log() pour afficher un message au-dessus des phases, et lire le global args. Si le corps a une erreur de syntaxe, Claude Code la signale quand vous exécutez le workflow.
  • phases : si vous les listez dans meta, donnez à chaque entrée exactement le titre que vous passez à phase(). Un titre phase() sans entrée obtient son propre groupe de progression.
  • Horodatages et aléatoire : Claude Code fait en sorte que Date.now(), Math.random() et un new Date() sans argument lèvent une exception à l’intérieur du script, afin qu’une exécution relancée répète les mêmes appels agent(). Passez plutôt un horodatage via args.
Vous pouvez également éditer le script d’une seule exécution plutôt que la copie enregistrée. Reprendre après une pause couvre les agents qui s’exécutent à nouveau quand vous relancez un script édité. Pour les entrées de l’outil Workflow, consultez son entrée dans la référence Agent SDK.

​
Comment un workflow s’exécute

Le runtime du workflow exécute le script dans un environnement isolé, séparé de votre conversation. Les résultats intermédiaires restent dans les variables du script au lieu d’atterrir dans le contexte de Claude. Chaque exécution écrit son script dans un fichier sous le répertoire de votre session dans ~/.claude/projects/. Claude reçoit le chemin au démarrage de l’exécution, vous pouvez donc le demander. Vous pouvez ouvrir ce fichier pour lire l’orchestration que Claude a écrite, la comparer avec le script d’une exécution précédente, ou l’éditer et demander à Claude de relancer à partir de la version éditée. Claude ne peut démarrer un workflow que à partir d’un fichier de script que la session est déjà autorisée à lire. Pour exécuter un script conservé en dehors de votre répertoire de travail, ajoutez d’abord son répertoire avec /add-dir ou une règle d’autorisation Read. Le runtime suit le résultat de chaque agent au fur et à mesure que l’exécution progresse, ce qui rend une exécution reprendre possible dans la même session.

​
Prompt caching dans un fan-out

Les agents dans la même exécution peuvent lire le prompt cache les uns des autres. Deux agents qui s’exécutent avec le même modèle, le même niveau d’effort, le même type d’agent, les mêmes outils, le même schéma de sortie et le même répertoire de travail construisent le même préfixe d’outils et de système-prompt, donc un agent qui démarre après que la réponse d’un frère correspondant a commencé lit le cache de ce frère à sa première requête. Les requêtes d’un agent de workflow se situent en dehors du bucket TTL du cache de la conversation principale, donc son cache se maintient pendant cinq minutes par défaut, y compris sur un abonnement Claude. Pour le conserver pendant une heure, définissez subagentPromptCacheTtl sur 1h. L’API facture les écritures de cache d’une heure à un taux plus élevé. Lorsqu’un fan-out démarre plusieurs agents correspondants à la fois, Claude Code maintient tous les agents sauf le premier jusqu’à ce que la réponse du premier agent commence, puis libère les agents maintenus ensemble afin que leurs premières requêtes lisent le préfixe partagé au lieu que chacun le traite sans cache. Claude Code plafonne la retenue à CLAUDE_CODE_WORKFLOW_PREFIX_STAGGER_MS millisecondes, 5000 par défaut. Définissez-le sur 0 pour désactiver la retenue.

​
Comportement et limites

Le runtime applique les contraintes suivantes :

​
Gérer les exécutions

Une fois qu’une exécution commence, vous la gérez à partir de la vue /workflows, ou en agrandissant sa ligne de progression dans le panneau des tâches sous la zone de saisie. Quand vous arrêtez une exécution, elle reste dans le panneau des tâches tant que l’un des processus de ses agents est toujours en cours d’exécution. Si vous l’arrêtez à nouveau, Claude Code renvoie à nouveau un signal à ces processus.

​
Reprendre après une pause

Reprenez une exécution en pause à partir de /workflows en la sélectionnant et en appuyant sur p. Pour une exécution que vous avez arrêtée, demandez à Claude de relancer le workflow avec le même script. Si les agents de l’exécution arrêtée n’ont pas encore quitté, Claude Code refuse le relancement jusqu’à ce qu’ils le fassent, afin qu’une deuxième copie de ces agents ne puisse pas s’exécuter à côté d’eux. Claude Code rejoue l’exécution dans l’ordre où les agents ont commencé, et chaque agent retourne soit son résultat sauvegardé, soit s’exécute à nouveau :
  • Terminé : retourne son résultat sauvegardé. Le premier agent dont l’invite diffère de l’exécution précédente, parce que vous avez modifié le script ou qu’un agent antérieur a retourné quelque chose de différent, s’exécute à nouveau, tout comme tous les agents après lui, même ceux qui ont terminé.
  • Toujours en cours d’exécution quand vous avez arrêté : recommence. L’arrêt de l’ensemble de l’exécution ne compte aucun agent comme ayant échoué.
  • Échoué : s’exécute à nouveau, tout comme tous les agents qui ont commencé après lui, même ceux qui ont terminé. L’arrêt d’un seul agent, en le sélectionnant dans /workflows et en appuyant sur x, compte comme un échec.
Ce dernier cas signifie qu’un échec au milieu d’une distribution réexécute le travail qui a déjà terminé. Si un script démarre A, B, C et D dans cet ordre et que B échoue, relancer retourne A du cache et exécute B, C et D à nouveau. Vous pouvez reprendre une exécution dans la même session Claude Code. Ce qui arrive à un workflow en cours d’exécution quand vous quittez la session dépend de la façon dont vous quittez :
  • Si vous mettez la session en arrière-plan, Claude Code rejoue l’exécution de la même manière dans la session en arrière-plan et la continue.
  • Si vous quittez Claude Code pendant qu’un workflow s’exécute et que la vue agent est activée, la boîte de dialogue de sortie propose Move to background and exit, qui transfère l’exécution de la même manière. Si vous choisissez Exit and stop tasks à la place, ou si l’option n’est pas proposée, l’exécution s’arrête avec la session. Claude Code conserve les résultats sauvegardés de l’exécution dans le répertoire de cette session dans ~/.claude/projects/, donc une session que vous reprenez avec claude --resume peut les rejouer quand vous demandez à Claude de relancer le workflow. Dans une session que vous démarrez à nouveau, Claude n’a aucune exécution antérieure à rejouer et démarre le workflow à nouveau en tant que nouvelle exécution.
Dans une session cloud, Claude Code sauvegarde également les résultats de l’exécution avec l’historique de conversation de la session, qui persiste quand la VM de la session est récupérée. Quand vous rouvrez une telle session et demandez à Claude de relancer le workflow, les agents terminés retournent toujours leurs résultats sauvegardés. Dans les sessions locales et cloud, quand Claude relance une exécution antérieure et que Claude Code ne peut pas trouver du tout les résultats sauvegardés de cette exécution, le relancement échoue avec une erreur nothing to resume au lieu de démarrer l’exécution à nouveau de son propre chef. Demandez à Claude de démarrer le workflow à nouveau en tant que nouvelle exécution.

​
Quand une exécution atteint votre limite d’utilisation

Quand un agent atteint votre limite d’utilisation claude.ai, l’exécution se met en pause plutôt que de faire échouer cet agent : les agents qui ont atteint la limite attendent la réinitialisation, et aucun nouvel agent ne démarre. Peu de temps après la réinitialisation de la limite, les agents en attente s’exécutent à nouveau et l’exécution continue d’elle-même. Nécessite Claude Code v2.1.271 ou ultérieur ; sur les versions antérieures, les agents affectés échouent. Pendant que l’exécution attend, sa ligne de progression dans le panneau des tâches et l’en-tête /workflows affichent quand la limite se réinitialise. L’exécution se met en pause uniquement quand tous ces éléments sont vrais ; quand l’un d’eux ne l’est pas, l’agent affecté échoue à la place :

​
Quand un agent se bloque et redémarre

Un agent dont la sortie cesse d’arriver suffisamment longtemps recommence à partir du même prompt. Dans /workflows, son nom reçoit un suffixe (retry 1) et son détail affiche attempt 2 (stalled). Le redémarrage est automatique, vous n’avez donc rien à faire. La nouvelle tentative démarre sans la transcription de la tentative bloquée. Les fichiers que la tentative bloquée a déjà modifiés restent modifiés, et les tokens qu’elle a consommés restent dans le total de l’exécution. La fenêtre de blocage est la durée pendant laquelle Claude Code attend une sortie d’un agent avant de mettre fin à la tentative. Le temps que l’agent passe à attendre ses propres appels d’outils ou une réinitialisation de la limite d’utilisation n’est pas compté dans la fenêtre de blocage. Un agent redémarre au maximum cinq fois, en comptant tout redémarrage que vous demandez avec r. Si la sixième tentative se bloque également, l’appel agent() échoue, et le début de l’erreur en indique la raison :
  • agent stalled on all 6 attempts : chaque tentative a passé toute la fenêtre sans sortie. Si le travail de l’agent le maintient silencieux aussi longtemps, allongez la fenêtre
  • agent lost its reply on all 6 attempts : le flux de réponse de chaque tentative est devenu silencieux et Claude Code a cessé de l’attendre. Allonger la fenêtre de blocage n’aide pas, car un watchdog d’inactivité du streaming a mis fin à la réponse en premier et CLAUDE_STREAM_IDLE_TIMEOUT_MS définit le délai d’expiration de ce watchdog
  • agent abandoned after 6 attempts : les tentatives se sont terminées de différentes manières, que l’erreur liste dans l’ordre
Pour donner à un agent plus de temps pour produire une sortie avant la fin de la fenêtre :
  • Un seul agent : passez stallMs en millisecondes dans son appel agent(), par exemple agent(prompt, { stallMs: 1800000 }) pour 30 minutes
  • Tous les agents : définissez CLAUDE_ASYNC_AGENT_STALL_TIMEOUT_MS, qui s’applique également aux sous-agents en dehors des workflows
La poursuite de l’exécution après l’échec dépend de la façon dont votre script a appelé l’agent :
  • À l’intérieur de parallel() ou pipeline() : l’exécution continue avec null à la place du résultat de l’agent
  • Attendu directement : l’exécution se termine avec l’erreur
Pour réessayer, demandez à Claude de relancer le workflow. Reprendre après une pause explique ce qui s’exécute à nouveau.

​
Coût

Un workflow génère de nombreux agents, donc une seule exécution peut utiliser significativement plus de tokens que de travailler à travers la même tâche en conversation. Les exécutions comptent vers l’utilisation de votre plan et les limites de débit. Pour évaluer les dépenses avant de vous engager dans une tâche importante, exécutez d’abord le workflow sur un petit échantillon : un répertoire au lieu de l’ensemble du dépôt, ou une question étroite au lieu d’une question large. La vue /workflows affiche l’utilisation des tokens de chaque agent au fur et à mesure que l’exécution progresse, et vous pouvez arrêter l’exécution à tout moment, généralement sans perdre le travail terminé. Reprendre après une pause couvre ce qu’une exécution arrêtée conserve. Les limites d’agents du runtime limitent le nombre d’agents qu’une seule exécution peut générer, ce qui limite le coût d’un script qui s’échappe. Pour garder les exécutions à moins d’agents, choisissez la directive de taille small . Claude Code signale également une exécution qui devient anormalement grande. Quand un workflow planifie plus de 25 agents, ou que son total de tokens projeté dépasse 1,5 million, sa ligne de progression dans le panneau des tâches sous la zone de saisie affiche un avertissement Large workflow. L’avertissement vous dirige vers /workflows, où vous pouvez arrêter l’exécution. L’avertissement est consultatif : il ne met pas en pause ou ne limite pas l’exécution. Deux paramètres changent quand vous le voyez :
  • Si vous choisissez une directive de taille vous-même, le nombre d’agents de la directive remplace le seuil de 25 agents. La directive par défaut intégrée laisse le seuil à 25.
  • Les sessions avec ultracode activé n’affichent pas l’avertissement, car l’activation d’ultracode vous inscrit déjà aux exécutions importantes.
Claude Code choisit le modèle de chaque agent de workflow dans le même ordre qu’il utilise pour les sous-agents. Un modèle que le script nomme pour une étape compte comme le modèle par invocation dans cet ordre. Quand rien d’autre n’en assigne un, l’agent s’exécute sur le modèle de votre session. Pour contrôler le coût du modèle :
  • Vérifiez /model avant une exécution importante si vous basculez généralement vers un modèle plus petit pour le travail de routine
  • Demandez à Claude d’utiliser un modèle plus petit pour les étapes qui n’ont pas besoin du plus fort quand vous décrivez la tâche
Quand la liste d’autorisation availableModels de votre organisation bloque un modèle que le script demande pour un agent, cet agent s’exécute sur un modèle substitué à la place, en suivant les mêmes règles de substitution que les sous-agents.

​
Définir une directive de taille

Une directive de taille indique à Claude combien d’agents viser quand il écrit un workflow dynamique. Claude Code envoie la directive à Claude comme conseil, pas comme une limite, donc une invite qui appelle une échelle différente la remplace toujours. Nécessite Claude Code v2.1.202 ou ultérieur. Chaque valeur correspond à un nombre d’agents : La valeur par défaut est medium, ou small quand vous êtes connecté sur un plan Pro avec Claude Code v2.1.271 ou ultérieur. Jusqu’à ce que vous choisissiez une valeur, la ligne /config affiche la valeur comme par défaut, et la ligne Running in background du workflow affiche la taille en vigueur. Nécessite Claude Code v2.1.219 ou ultérieur ; les versions antérieures utilisent par défaut unrestricted. Pour modifier la directive, choisissez une valeur pour le paramètre Dynamic workflow size dans /config, ou exécutez /config workflowSizeGuideline=small. Sur v2.1.219 et ultérieur, vous pouvez également définir la clé workflowSizeGuideline dans n’importe quel fichier de paramètres ; cette valeur a la priorité sur /config, et Claude Code masque la ligne /config tandis qu’un fichier de paramètres en fournit une. Les modifications prennent effet à l’invite suivante. Les limites d’agents du runtime s’appliquent toujours indépendamment du paramètre.

​
Désactiver les workflows

Les workflows sont disponibles dans le CLI, l’application Desktop, les extensions IDE, le mode non-interactif avec claude -p, et l’Agent SDK. Les mêmes paramètres de désactivation s’appliquent sur chaque surface. Pour désactiver les workflows pour vous-même :
  • Basculez Dynamic workflows off dans /config. Persiste entre les sessions.
  • Définissez "disableWorkflows": true dans ~/.claude/settings.json. Persiste entre les sessions.
  • Définissez CLAUDE_CODE_DISABLE_WORKFLOWS=1. Lire au démarrage, donc cela s’applique partout où vous le définissez.
Pour désactiver les workflows pour toute votre organisation, définissez "disableWorkflows": true dans les paramètres gérés, ou utilisez le bouton bascule sur la page des paramètres d’administration Claude Code. Quand les workflows sont désactivés :
  • /workflows, les commandes de workflow et le skill /workflow-authoring ne sont pas disponibles
  • Le mot-clé ultracode ne déclenche plus d’exécution, et le bouton bascule Ultracode est supprimé de /effort
Une exécution qui était déjà en cours continue. Désactiver les workflows rend également ultracode indisponible. Aucun paramètre géré n’exclut ultracode seul : partout où il est disponible, les utilisateurs peuvent l’activer avec /effort ultracode. Une limite d’effort abaisse le niveau d’effort qu’une session avec ultracode activé exécute, mais ne désactive pas ultracode.