Qwen Code Hebdo : Basculement automatique en cas de surcharge modèle, dérivation imbriquée de sous-agents, intégration WeCom

Cette semaine, Qwen Code sort 3 versions stables (v0.19.6 à v0.19.8) avec plus de 150 PR fusionnés, couvrant quatre axes :

La surcharge modèle ne bloque plus. Avant, un 429/503/529 interrompait la conversation et vous deviez changer de modèle manuellement. Maintenant, la chaîne de fallback bascule automatiquement vers un modèle de secours une fois le budget de tentatives du modèle principal épuisé. Avec /model --project, chaque projet peut être lié à un modèle différent, sans manipulation à chaque fois.

Les sous-agents peuvent engendrer des sous-agents. Jusqu’ici, un sous-agent était un « nœud feuille » — il recevait une tâche et devait la terminer seul, sans pouvoir déléguer. Désormais, avec une profondeur d’imbrication par défaut de 5 niveaux, un sous-agent peut répartir des sous-tâches au niveau inférieur. Le TUI et le Web Shell affichent une vue arborescente où la filiation est immédiatement visible.

La gestion des sessions Web Shell devient systématique. Archivage, suppression, groupes nommés, étiquettes de couleur, page de gestion des tâches planifiées, vue d’ensemble en écran partagé — la barre latérale ne se contentait plus de basculer entre les sessions, elle permet maintenant d’organiser, classer, surveiller et opérer en parallèle. Sept PR transforment les sessions d’une « liste à plat » en ressources gérables.

WeCom et contrôle d’accès complétés. Intégration du canal bot intelligent WeCom — deux paramètres suffisent (Bot ID + Secret), pas besoin de droits administrateur d’entreprise ni de callback. Le hook PreToolUse avec « ask » affiche désormais une vraie boîte de confirmation ; auparavant, cette option équivalait à un refus silencieux. Les règles de permission supportent la syntaxe Tool(param:value) pour un contrôle granulaire par valeur de paramètre.

✨ Nouvelles fonctionnalités

Basculement automatique en cas de surcharge modèle + configuration modèle par projet

Quand un modèle renvoie un 429/503/529, votre conversation se bloque. Cette version introduit une chaîne de fallback opt-in — une fois le budget de tentatives du modèle principal épuisé, le système bascule automatiquement vers le modèle suivant dans la liste de fallback. Seuls les problèmes de capacité et de limitation de débit empruntent le chemin de fallback. Les erreurs d’authentification, de quota, de configuration ou côté client échouent directement, car il ne s’agit pas de « surcharge modèle » mais de « problème de configuration ».

Le fallback progresse avant que du contenu visible ne soit affiché à l’utilisateur. Si un modèle de fallback a déjà produit du contenu puis plante, les fallbacks restants ne tentent pas de continuer — vous voyez une réponse tronquée. Mais le prochain tour utilisateur repart du modèle principal, sans rester coincé sur le modèle de fallback.

Avec /model --project, vous pouvez lier différents modèles à différents projets. --project écrit dans le .qwen/settings.json du projet, --global écrit dans le ~/.qwen/settings.json utilisateur. Sans indicateur, le comportement actuel est conservé. Les indicateurs de portée s’appliquent aussi à --fast, --voice et --vision.

Ce que cela vous permet de faire :

• Configurer une liste de modèles de fallback avec basculement automatique en cas de surcharge, sans changement manuel
• Les erreurs d’authentification et de quota ne sont pas masquées par le fallback, les problèmes sont détectés plus tôt
• /model --project permet à chaque projet d’utiliser un modèle différent, la configuration suit le projet
• /model --global définit un défaut global, hérité par les nouveaux projets

Voir les PR #6273  et #6060 

Dérivation imbriquée de sous-agents + vue arborescente

Les sous-agents peuvent désormais engendrer d’autres sous-agents. La profondeur maximale par défaut est de 5 niveaux, configurable via model.maxSubagentDepth. La valeur 1 rétablit l’ancien comportement — les sous-agents ne peuvent pas dériver de sous-agents.

Deux mécanismes de protection : lors de la préparation du schéma, le sous-agent au niveau le plus profond ne voit pas l’outil agent (il ignore même son existence) ; lors de l’exécution, les demandes de dérivation dépassant la limite de profondeur sont rejetées.

Le TUI et le Web Shell affichent une structure arborescente imbriquée. Les sous-agents apparaissent sous leur parent, avec le marqueur ↳ et une indentation. Quand le parent se retire, le sous-agent est promu en racine avec la mention « from <parent> ». La vue de détail affiche « Level N · from <parent type> ». Les étiquettes de blocage et la confirmation d’arrêt deviennent aussi conscientes de la chaîne — la confirmation n’apparaît que si l’annulation entraîne la fin du tour.

Cette capacité est activée par défaut — après la mise à jour, tous les environnements existants bénéficient de la dérivation imbriquée. Les fork de sous-processus, les teammates et les agents de workflow restent exclus. Les sessions Arena peuvent désormais s’imbriquer. Les agents en arrière-plan restaurés retrouvent leur profondeur d’origine et le plafond au démarrage.

Ce que cela vous permet de faire :

• Laisser un sous-agent gérer des tâches complexes en dérivant lui-même des sous-agents pour les sous-tâches
• Voir la structure arborescente complète des agents dans le TUI et le Web Shell
• Ajuster la profondeur d’imbrication maximale via model.maxSubagentDepth

Voir les PR #6189  et #6239 

Gestion des sessions Web Shell : archivage, regroupement, tâches planifiées, écran partagé

Sept PR transforment la barre latérale des sessions du Web Shell d’une « liste à plat » en un panneau de gestion permettant d’organiser, classer, surveiller et opérer en parallèle.

Archivage et suppression. Chaque ligne de session dispose désormais d’actions rapides et d’un menu de débordement « … » (renommer / archiver / supprimer). Les sessions archivées sont regroupées dans une section « Archived » repliable, et peuvent être restaurées ou définitivement supprimées. La session en cours d’utilisation ne peut pas être archivée ni supprimée ; une session archivée ne peut pas être ouverte (409 session_archived) ; la suppression est définitive avec confirmation secondaire. En arrière-plan, cela passe par l’état archiveState du daemon et les endpoints /sessions/archive et /sessions/unarchive.

Groupes nommés et étiquettes de couleur. Vous pouvez créer, renommer et supprimer des groupes, y glisser des sessions, et leur attribuer des étiquettes de couleur ainsi qu’un état épinglé ou archivé. Les données de groupe traversent toutes les couches depuis le daemon — un fichier sidecar au niveau du projet stocke les métadonnées de groupe, les routes REST/ACP fournissent les opérations CRUD, et l’exposition est contrôlée par capacité selon le support client.

Vue d’ensemble et écran partagé. Sur grand écran, un panneau de vue d’ensemble des sessions apparaît dans la barre latérale. Toutes les sessions s’affichent sous forme de cartes en temps réel, triées par priorité : les approbations en attente d’abord, puis les sessions en cours, enfin les sessions inactives. Chaque carte indique le modèle actuel et le nombre de clients. Après une sélection multiple, vous pouvez afficher en écran partagé — dans l’onglet actuel ou dans un nouvel onglet du navigateur (paramètre d’URL ?split=a,b). N panneaux de discussion indépendants côte à côte, chacun avec son propre contexte de session, le focus clavier ne s’appliquant qu’au panneau cliqué.

Ce que cela vous permet de faire :

• Archiver et organiser les sessions accumulées, les regrouper par projet avec des étiquettes de couleur
• Créer et gérer des tâches planifiées visuellement, sans écrire d’expressions cron à la main
• Chaque tâche planifiée dispose de sa propre session, avec historique et transcripts consultables à tout moment
• En grand écran, afficher en parallèle l’état en temps réel de plusieurs sessions

Voir les PR #6293 , #6350 , #6305 , #6348 , #6389 , #6453  et #6400 

Intégration du canal WeCom

Intégration du bot intelligent WeCom via @wecom/aibot-node-sdk. La configuration ne nécessite que le Bot ID et le Secret — pas de Corp ID, Agent ID, Token de callback, EncodingAESKey, ni d’adresse de callback publique.

Réception des messages via connexion WebSocket persistante, avec prise en charge du texte, de la transcription vocale, du contenu mixte texte-image, des images, fichiers, vidéos et citations. Les réponses de l’Assistant sont envoyées au format markdown WeCom. En sortie, seules les images locales sont prises en charge (dans le répertoire temporaire du canal) ; les marqueurs de fichier, vidéo et audio sont ignorés.

Configuration :

{
  "type": "wecom",
  "botId": "your-bot-id",
  "secret": "your-secret",
  "cwd": "/path/to/project"
}

Commande de démarrage : qwen channel start my-wecom

Ce que cela vous permet de faire :

• Intégrer WeCom avec seulement Bot ID + Secret, sans droits administrateur d’entreprise
• Recevoir du texte, de la voix, des images, des fichiers, des vidéos et des messages cités
• Faire répondre Qwen Code en messages markdown dans les groupes WeCom

Voir le PR #6436 

Boîte de confirmation native pour le hook PreToolUse

Auparavant, le hook PreToolUse retournant permissionDecision: "ask" équivalait à « deny » — la boîte de confirmation n’apparaissait jamais. Les développeurs de hooks pensaient que l’utilisateur verrait un choix, mais la demande était silencieusement refusée.

Maintenant, « ask » affiche une boîte de confirmation native dans le TUI. Les options sont « Yes, allow once » et « No, suggest changes » — pas d’« always allow », car le hook réévalue à chaque appel. Une fois approuvé, l’outil s’exécute à nouveau ; en cas de refus, il est annulé.

Dans les scénarios CLI non interactifs et agents en arrière-plan, « ask » retombe sur deny — aucune attente n’est engagée. Le mécanisme existant awaiting_approval est réutilisé, sans nouveau chemin. Les comportements « denied » et « stop » restent inchangés, le hook PermissionRequest n’est pas affecté.

Ce que cela vous permet de faire :

• Utiliser « ask » dans le hook PreToolUse pour laisser l’utilisateur décider d’exécuter ou non un outil
• Pas de risque de blocage dans les scénarios non interactifs
• Chaque appel de hook est réévalué, aucun passage permanent n’est accordé

Voir le PR #5629 

Aperçu et examen des Skills auto-générés

Quand un agent génère automatiquement un skill, on ne voyait auparavant que le nom du fichier ; il fallait confirmer avant de savoir ce qu’il contenait. Désormais, la boîte de dialogue d’examen affiche un aperçu inline du contenu complet — frontmatter inclus.

Le contenu généré par le modèle est assaini : les séquences de contrôle ANSI/VT deviennent des échappements inoffensifs, les CRLF deviennent des sauts de ligne simples. La limite de lecture est de 64 Kio, celle d’affichage de 12 lignes (avec retour à la ligne automatique), le surplus est signalé par « lines hidden » ou « truncated ».

Appuyer sur o ouvre le fichier skill dans l’éditeur configuré, sans passer outre l’examen en cours. Après sauvegarde du fichier, l’aperçu se rafraîchit automatiquement — avec un éditeur GUI (comportement par défaut sur macOS), vous pouvez modifier puis revoir.

L’option « Turn off auto-generated skills » se trouve en fin de liste ; sa sélection prend effet immédiatement (pas de redémarrage), persistée au niveau du workspace. Le lot courant est mis en suspens (non supprimé) et revient lors de la réouverture via /memory.

Ce que cela vous permet de faire :

• Voir le contenu complet d’un skill avant de confirmer, sans avoir à accepter puis chercher le fichier
• Appuyer sur o pour modifier le skill directement dans l’éditeur, l’aperçu se rafraîchit après sauvegarde
• Désactiver les skills auto-générés en un clic, le lot courant n’est pas supprimé et peut être restauré via /memory

Voir le PR #6393 

Avant (qwen global 0.19.6) — nom + description uniquement	Après — examen d’un skill avec aperçu inline et option de désactivation

Après — dernier élément du lot, options en masse masquées	Après — « Turn off auto-generated skills » sélectionné

📊 Autres nouvelles fonctionnalités

🔧 Corrections importantes

👥 Contributeurs

Pour toute question ou suggestion, n’hésitez pas à ouvrir un ticket sur GitHub Issues  !