Deep Agents v0.7 réduit les tokens par tour de 65 %

Deep Agents v0.7 réduit de 65% les tokens d’entrée de base par tour. Cela signifie moins de surcharge fixe liée aux prompts à chaque appel, une facture API plus basse et davantage d’espace de contexte pour les éléments réellement importants de la tâche.

En résumé, cette mise à jour apporte les changements suivants :

• Le prompt système de base par défaut a disparu
• Les descriptions des outils intégrés sont plus courtes
• Les tâches ne sont plus jointes par défaut
• Le middleware est choisi volontairement au lieu d’être inclus en bloc
• Les économies viennent du harness, pas du modèle

En termes simples, si un agent effectue 10 appels, la même enveloppe fixe était auparavant envoyée 10 fois. Dans v0.7, cette enveloppe est nettement plus petite par défaut. Chaque tour produit donc une requête plus légère, surtout pour des tâches simples comme la lecture ou l’écriture de fichiers.

Plusieurs points ressortent :

• Le coût évolue selon llm_calls × input_tokens_per_call
• L’ancienne configuration envoyait du texte de planification, de système de fichiers et de sous-agent même lorsque la tâche n’en avait pas besoin
• La nouvelle configuration transfère le contrôle au développeur, qui choisit le prompt, les outils et le middleware adaptés
• Les réductions les plus importantes viennent de la suppression du prompt de base et du raccourcissement des textes d’outils
• Les workflows longs et multi-agents en profitent le plus, car la surcharge fixe se répète à chaque étape

Voici une comparaison simple :

Mon constat : v0.7 concerne moins les changements de modèle que la discipline appliquée aux prompts. En gardant le harness léger, je conserve la totalité du gain de 65%. Si j’ajoute de nouveau de nombreux middlewares et outils, je perds une partie de ce bénéfice.

C’est le cœur de la mise à jour, et il prépare la suite de l’article.

Ce qui change dans le harness configurable

La réduction de 65% des tokens provient d’une modification de ce que le harness injecte à chaque tour, et non de l’utilisation d’un modèle plus intelligent. En clair, v0.7 retire une grande quantité de texte par défaut qui accompagnait auparavant chaque requête.

Suppression du prompt système de base et raccourcissement des descriptions d’outils

Avant v0.7, le harness intégrait à chaque requête un prompt système par défaut, de longues descriptions d’outils, un middleware de planification et une logique de sous-agents, même lorsqu’ils n’étaient pas nécessaires. v0.7 rend le harness configurable afin que les développeurs décident ce qui est injecté à chaque tour.

Les principales sources de surcharge étaient le prompt système de base par défaut et les longues descriptions des outils intégrés. Le prompt de base contenait des instructions pour les outils de planification, les outils de système de fichiers et les sous-agents, et il était envoyé à chaque tour. Dans v0.7, ce prompt a été supprimé. Les développeurs peuvent désormais fournir un texte adapté à la tâche.

Les descriptions intégrées d’utilitaires comme ls, read_file et write_file ont également été raccourcies. Le comportement des outils reste identique. Il y a simplement moins de texte fixe autour de chaque requête. Aucun de ces changements n’affecte le modèle sous-jacent ; ils réduisent uniquement la charge de tokens auparavant transportée à chaque tour.

Tâches optionnelles et middleware désormais sélectionnable explicitement

Avant v0.7, todoListMiddleware était attaché par défaut, si bien que le texte de planification partait à chaque tour. Dans v0.7, les tâches sont optionnelles. Vous ne les ajoutez que lorsqu’une planification en plusieurs étapes améliore réellement le travail.

Le même principe s’applique au reste de la pile de middlewares. FilesystemMiddleware et SubAgentMiddleware ne sont plus regroupés par défaut. Les développeurs peuvent désormais composer uniquement les middlewares dont ils ont besoin. Une tâche de lecture de fichier peut ignorer la logique de sous-agent. Un workflow de vérification peut ajouter un middleware de liste de contrôle uniquement lorsqu’il apporte une valeur.

Une orchestration plus explicite

Le changement pratique est simple : la configuration passe de valeurs implicites à une composition explicite. Au lieu de laisser le harness décider quels outils sont visibles, quel middleware s’exécute et ce que contient le prompt système, les développeurs prennent eux-mêmes ces décisions. Ils contrôlent désormais l’assemblage du prompt, la visibilité des outils et le middleware pour chaque tâche.

Ces changements apparaissent dans la pile d’agent par défaut ci-dessous. ^[2]

Utilisation des tokens avant et après

Ces changements du harness se reflètent immédiatement dans la charge utile envoyée à chaque tour. Les économies viennent de la réduction de l’enveloppe fixe de la requête, et non d’un changement du prompt utilisateur ou du modèle.

Tour de l’agent par défaut avant v0.7

Avant v0.7, chaque tour incluait la planification, le système de fichiers et l’infrastructure des sous-agents, même si rien de tout cela n’était utilisé. Le texte des tâches et les prompts des middlewares étaient également inclus par défaut. Une importante charge utile fixe était donc répétée à chaque tour.

Tour de l’agent par défaut après v0.7

Après v0.7, une simple tâche de lecture de fichier envoie uniquement les outils et middlewares dont elle a besoin. La surcharge inutile cesse donc de se répéter au fil des tours. Le prompt système de base est supprimé, les descriptions des outils sont plus courtes et une tâche de lecture ne transporte plus de texte de planification ou de sous-agent inutilisé.

Comme le souligne Aaron Jewitt, le coût d’un agent évolue selon llm_calls × input_tokens_per_call.^[1]

Origine des économies de tokens

Voici d’où vient la réduction de 65%.

Les économies les plus importantes viennent de la suppression du prompt de base et du raccourcissement des descriptions d’outils. C’est pourquoi la sélection du middleware et une visibilité plus limitée des outils font une différence si nette dans les workflows quotidiens.

La section suivante montre comment les développeurs conservent ces gains en choisissant uniquement les éléments du harness nécessaires à chaque tâche.

Modèles de configuration du harness pour les développeurs

Une fois les économies de tokens acquises, l’étape suivante consiste à choisir un profil de harness léger pour chaque tâche. Ces gains proviennent de prompts plus petits et de paramètres par défaut plus stricts. Dans Deep Agents v0.7, le harness — et non le modèle — représente l’essentiel de la surcharge en tokens par tour. L’optimisation dans Deep Agents v0.7 dépend donc moins du choix du modèle que de la manière de composer le harness.

Choisir uniquement le middleware nécessaire à la tâche

Utilisez un middleware uniquement lorsque la tâche nécessite un contrôle d’accès, une planification ou une gestion d’état. Pour les tâches courtes, ces couches supplémentaires ne font qu’ajouter de la surcharge.

La règle est simple : commencez par la plus petite pile de middlewares nécessaire à la tâche. Il en va de même pour les outils. N’exposez que ceux dont la tâche actuelle a réellement besoin.

Limiter la visibilité des outils et raccourcir leurs descriptions

Afficher tous les outils à chaque tour est l’un des moyens les plus rapides de gonfler l’entrée. Une visibilité limitée aide à garder un prompt compact.

Des descriptions plus courtes réduisent encore la taille du prompt. Des formulations précises et concises permettent également au modèle de choisir plus facilement le bon outil sans recevoir une grande quantité de contexte superflu.

Utiliser des tâches optionnelles et des paramètres par défaut fondés sur des profils

La gestion des tâches aide dans les travaux de longue durée où l’agent doit suivre sa progression sur de nombreuses étapes. Pour une tâche courte et unique, elle ajoute de la surcharge sans bénéfice.

Rendez les tâches optionnelles pour les travaux longs et définissez des profils légers ou complets selon la classe d’agent. Des paramètres légers préservent le gain de 65% pour les agents simples, tandis que les profils plus riches restent réservés aux workflows exigeant beaucoup de planification.

Ces choix déterminent si la réduction de 65% se traduit par un coût inférieur et des itérations plus rapides au quotidien.

Conséquences de v0.7 sur le coût, la vitesse et le passage à l’échelle

Coûts d’inférence plus faibles et boucles d’itération plus rapides

La réduction de l’enveloppe de requête s’accumule à chaque tour d’un workflow long. Les coûts en tokens augmentent au fil des échanges ; un harness léger ne permet donc pas seulement d’économiser sur le premier tour. Il maintient un point de départ plus bas à chaque tour suivant, et l’écart s’amplifie à mesure que la conversation s’allonge.

Dans la pratique, cette réduction se manifeste ici :

Les charges utiles plus petites accélèrent également les boucles d’itération. Si vous testez une modification de prompt ou une nouvelle configuration d’outils, les requêtes légères reviennent plus rapidement. Cela supprime une grande partie des lenteurs du travail de développement quotidien.

Meilleure évolutivité des workflows longs et multi-agents

Ces mêmes économies deviennent encore plus importantes lorsque plusieurs agents partagent le budget d’un workflow. La surcharge fixe consomme silencieusement les ressources des systèmes multi-agents. Si chaque agent transporte un harness surdimensionné, cette charge se multiplie à chaque tour coordonné.

Un harness plus léger réduit l’empreinte de chaque agent. Il améliore le débit et diminue le risque d’atteindre une limite de contexte ou de requêtes au milieu du workflow.

Lorsque les fenêtres de contexte se remplissent, les performances peuvent baisser. Un harness allégé laisse à chaque agent davantage d’espace utilisable pour les données réelles de la tâche. En clair, les workflows longs peuvent rester précis plus longtemps, sans que des mécanismes de compactage ou de résumé interviennent trop tôt.

La réduction de la surcharge par appel est particulièrement importante dans les workflows comportant de nombreux tours, de nombreux agents, ou les deux. La baisse de 65% des tokens réduit le coût de chaque appel. Mais le principal avantage à grande échelle vient du modèle d’orchestration explicite de v0.7. Avec des critères d’arrêt clairs plutôt que des boucles ouvertes, les agents effectuent moins d’appels au total pour terminer une tâche.

Principaux enseignements de la version Deep Agents v0.7

Deep Agents v0.7 améliore le coût et la qualité en rendant le harness configurable. La sélection du middleware, la visibilité des outils et les paramètres fondés sur des profils déterminent si un workflow conserve l’ensemble des économies ou en perd une grande partie à cause d’une surcharge supplémentaire.

La configuration est le principal levier d’optimisation. Elle compte surtout dans les workflows comportant de nombreux tours, de nombreux agents, ou les deux.

FAQ

Comment conserver l’intégralité des 65% d’économies de tokens dans les workflows réels ?

Considérez la configuration du harness comme un système vivant, et non comme un réglage à effectuer une seule fois. Commencez par mesurer l’utilisation des tokens et le nombre d’appels au LLM. Utilisez ensuite le harness pour imposer des règles de comportement strictes.

Utilisez PreCompletionChecklistMiddleware pour interrompre les boucles de raisonnement redondantes. Utilisez LocalContextMiddleware afin de ne transmettre que le contexte et les outils nécessaires au modèle. Ajoutez une mise en cache des prompts pour maintenir les instructions système stables entre les exécutions.

Lorsque l’utilisation des tokens augmente brutalement, surveillez les dérives et resserrez les règles du harness.

Quelles tâches doivent encore utiliser des listes ou du middleware supplémentaire ?

Utilisez todoListMiddleware lorsque l’agent travaille sur un problème complexe composé de plusieurs parties. Il l’aide à suivre ce qui est terminé et ce qui nécessite encore son attention à mesure que le travail progresse.

Lorsque vous demandez l’utilisation de l’outil write_todos, l’agent peut mettre à jour sa progression à mesure que de nouvelles informations arrivent. Les workflows longs et difficiles deviennent ainsi plus faciles à suivre, et l’agent conserve le bon cap.

Un harness plus petit affecte-t-il la qualité ou la fiabilité de l’agent ?

Pas par défaut. Un harness réduit et bien réglé peut préserver, voire améliorer, la fiabilité en diminuant les tokens par tour grâce à une meilleure gestion du contexte, à la délégation vers des outils et à un emballage structuré des prompts.

La qualité reste stable lorsque ces économies sont associées à des garde-fous déterministes, comme des boucles de vérification et des listes de contrôle avant la fin. L’agent peut ainsi rester concentré sur les données pertinentes de la tâche et vérifier son travail avant de répondre.