Qwen3.6-Max-Preview : le modèle de nouvelle génération renforcé pour le codage agentique et la connaissance du monde

• Successeur de Qwen3.6-Plus, avec des améliorations par rapport à la version précédente en codage agentique, ainsi qu’en connaissance du monde et en suivi des instructions
• Le modèle obtient les meilleurs scores sur 6 benchmarks majeurs de codage, confirmant une forte progression des performances des agents de codage
• Prend en charge la fonctionnalité preserve_thinking, qui permet de conserver dans les messages le processus de réflexion des tours précédents lors des tâches agentiques
• Sur les benchmarks de connaissance du monde, amélioration de SuperGPQA de +2.3 et de QwenChineseBench de +5.3 ; pour le suivi des instructions, score de +2.8 sur ToolcallFormatIFBench
• Des tests interactifs sont possibles dans Qwen Studio, et l’appel via l’API Alibaba Cloud Model Studio sera effectué avec qwen3.6-max-preview

---

Principales améliorations

• Capacités de codage agentique fortement améliorées par rapport à Qwen3.6-Plus : SkillsBench +9.9, SciCode +6.3, NL2Repo +5.0, Terminal-Bench 2.0 +3.8
• Renforcement de la connaissance du monde (world knowledge) : SuperGPQA +2.3, QwenChineseBench +5.3
• Amélioration du suivi des instructions (instruction following) : ToolcallFormatIFBench +2.8
• Meilleurs scores atteints sur 6 benchmarks majeurs de codage : SWE-bench Pro, Terminal-Bench 2.0, SkillsBench, QwenClawBench, QwenWebBench, SciCode

Caractéristiques du modèle et approche

• Modèle propriétaire hébergé fourni via Alibaba Cloud Model Studio
• Amélioration des performances des agents réels (real-world agent) et de la fiabilité des connaissances (knowledge reliability)
• Test interactif immédiat possible dans Qwen Studio
• Le nom du modèle dans l’API est qwen3.6-max-preview, et il sera bientôt disponible dans l’API Alibaba Cloud Model Studio

Utilisation de l’API et fonctionnalités

• Prise en charge des protocoles standard de l’industrie comme les API OpenAI-compatibles chat completions et responses, ainsi que les interfaces compatibles Anthropic
• La fonctionnalité preserve_thinking permet de conserver le processus de raisonnement (reasoning content) des tours précédents, recommandé pour les tâches agentiques
• Avec le paramètre enable_thinking: True, il est possible de recevoir séparément, en streaming, le contenu de raisonnement et la réponse
• URL de base de l’API disponibles par région : Pékin, Singapour, États-Unis (Virginie)

État du développement

• Actuellement au stade de preview release, avec des améliorations itératives en cours et d’autres optimisations prévues dans les versions suivantes

[GN⁺]

Avis Hacker News

• Je trouve un peu drôle que les gens soient obsédés uniquement par les comparaisons SOTA. J’ai vu des cas où glm 5.1 réussissait des choses qu’Opus n’arrivait pas à faire, et je l’ai aussi vu mieux coder. Je n’ai pas encore essayé qwen max, mais j’ai aussi vu un modèle local 122b mieux lire des documents et les traiter plus précisément. Au final, les benchmarks ne montrent qu’une partie de l’histoire, et en pratique chaque modèle a des points forts différents, donc je ne pense pas qu’on puisse en parler comme si on comparait simplement un marteau et une clé en disant lequel est objectivement supérieur

  • J’utilise GLM-5.1 sur pi.dev d’Ollama Cloud pour un projet perso, et j’en suis plutôt content. Au travail, on utilise ensemble pi.dev, Claude Sonnet et Opus 4.6. Claude Code est bien aussi, mais depuis la dernière mise à jour il faut faire des compact trop souvent, ce qui était pénible. Avec pi.dev, même sans MCP tool calling, l’intégration API fonctionnait bien, donc ça ne m’a pas manqué. J’ai même eu l’impression que pour créer des sites web, GLM-5.1 faisait mieux que Claude Opus, et il s’en sort très bien aussi sur la plateforme de développement full stack que je construis en ce moment
  • GLM 5.1 a été le premier modèle qui m’a vraiment donné l’impression que les modèles chinois avaient rattrapé leur retard. Du coup, j’ai aussi annulé mon abonnement Claude Max et, honnêtement, ça ne me manque pas du tout. Quand on voit à quel point les avis divergent selon les personnes, on dirait qu’on est arrivé à un stade où les différences de domaine et de schémas d’usage comptent plus que la hiérarchie absolue du SOTA
  • La seule vraie raison pour laquelle je continue presque à utiliser Claude et ChatGPT, c’est le tool calling. Il y a aussi des fonctionnalités utiles comme les skills. J’ai essayé qwen et deepseek aussi, mais il m’est arrivé de voir des cas où ils n’arrivaient même pas à bien produire un document. Je me demande comment les autres gèrent les documents ou Excel avec ce genre d’outils, et si possible j’aimerais bien moi aussi migrer
  • Il y a quelques mois, Qwen3-Coder me produisait un code Rust bien meilleur que Claude Opus ou Google Gemini. J’ai été particulièrement impressionné par le fait qu’il générait même du code exploitant les extensions vectorielles x86-64 de Rust. Je l’utilisais via des harness comme Zed editor ou trae CLI, et j’ai vraiment été très surpris
  • Les modèles ont globalement des scores de benchmark proches, avec de faibles écarts, donc dans une situation comme ça il me semble rationnel de choisir sur d’autres critères. Dans mon cas, dès qu’un plugin JetBrains correct sort, je suis prêt à passer chez n’importe quel fournisseur

• J’utilise Claude Code de manière continue au travail depuis plusieurs mois, et je l’ai aussi bien exploité récemment sur un petit projet de site web perso. Le week-end dernier, j’ai essayé pour la première fois l’auto-hébergement. Je me demande s’il y a des gens qui, après avoir suffisamment utilisé CC ou Codex, ont trouvé une configuration self-hosted assez satisfaisante. J’ai testé toutes sortes de combinaisons avec 32GB DDR5, AMD 7800X3D, RTX 4090, Windows et WSL, avec ollama, docker desktop model runner, pi-coding-agent, opencode, ainsi que Gemma 4, Qwen et GLM-5.1. Comme l’usage de RAM de base était déjà élevé, je ne pouvais pas faire tourner de bons modèles comme Gemma4-31B. En environnement Windows seul, la gestion des chemins de fichiers se cassait souvent la figure, tandis qu’en faisant tourner pi ou opencode sur WSL et les modèles via docker desktop, j’ai eu un certain succès. Mais au ressenti, les performances réelles étaient bien trop lentes par rapport à CC, et du point de vue de la finition des outils, le harness CC m’a semblé largement meilleur. J’ai passé tellement de temps sur le setup que je n’ai pas pu l’utiliser longtemps en pratique, mais c’était quand même une expérience intéressante

  • Tu devrais essayer des modèles MoE et déporter l’inférence sur le CPU. Gemma 4 26b-a4b ou qwen3.6 35b-a3b en sont de bons exemples. Avec seulement 32GB de RAM, ça devient un peu juste si d’autres applis tournent aussi, mais tant que la RAM système est suffisante, ça marche plutôt bien. On peut aussi mettre une partie des couches sur le GPU, mais j’ai eu des problèmes avec la combinaison modèles MoE + llama.cpp. En revanche, en mettant le KV cache sur le GPU, j’ai obtenu de très bonnes vitesses tout en gardant une fenêtre de contexte correcte. J’ai vu des résultats vraiment impressionnants en local. Je recommande aussi vivement de cloner directement llama.cpp sous WSL2, puis de confier l’installation et le tuning à un modèle frontier comme Claude Code. Les applis construites au-dessus de llama.cpp n’exposent pas toutes les options et tous les flags, donc un seul mauvais flag peut ruiner les performances, par exemple en désactivant le cache de contexte. En compilant directement depuis les sources, on peut vérifier le vrai code dès qu’un problème apparaît. Avec cette machine, tu devrais au moins obtenir autour de 20 à 40tok/s sur Gemma 4, donc ça devrait être tout à fait exploitable, et qwen3.6 pourrait même être plus rapide puisque ses paramètres actifs sont de 3b
  • Le problème que tu rencontres vient probablement du fait que tu ne peux pas charger le modèle entier d’un coup à cause du manque de VRAM. llmfit peut valoir le coup d’être essayé

• Je m’inquiète un peu de voir que ce secteur semble suivre une logique où l’on diffuse d’abord du gratuit pour se faire un nom, avant de tout basculer ensuite en proprietary. J’espère quand même qu’on continuera à avoir des open weights. Le jour où plus personne n’en publiera, ce sera vraiment amer. Dans un tel monde, j’ai l’impression qu’il deviendra plus difficile pour le commun des mortels de posséder directement sa propre compute

  • Je trouve que c’est une généralisation un peu excessive. Beaucoup de modèles américains étaient fermés dès le départ, alors qu’à l’inverse les modèles hors des États-Unis, surtout les modèles chinois, étaient plus ouverts dès le début. Il y a même eu des cas, côté chinois, où un modèle d’abord proprietary a ensuite été ouvert, et c’est aussi arrivé à certains grands modèles Qwen
  • J’ai l’impression que c’est un mouvement de stratégie nationale. En publiant en continu des modèles gratuits compétitifs, on dirait qu’ils cherchent à affaiblir le moat que les entreprises occidentales tentent de bâtir avec des modèles proprietary. Tant que ce récit reste favorable à la Chine, je pense qu’il est peu probable qu’ils reviennent à du totalement proprietary
  • Du point de vue des fabricants de puces, il est probablement aussi dans leur intérêt que l’environnement permettant de faire tourner des modèles en local continue d’exister
  • Oui. Pour les labos chinois, l’open source ressemble à une sorte de stratégie commerciale. Ils n’ont pas beaucoup d’autres moyens marketing efficaces pour faire connaître leurs modèles et leurs services d’inférence, donc cela joue probablement aussi. Cet article connexe vaut aussi le détour
  • J’ai l’impression que la structure était déjà plus ou moins la même depuis le début. Au fond, ça reste très proche du SaaS, et la différence aujourd’hui est surtout que l’abonnement d’entrée de gamme des frontier labs ressemble pratiquement à un essai gratuit

• Comme Kimi K2.6 est aussi sorti aujourd’hui, il me semble assez naturel de comparer les deux. Rien qu’au niveau du prix, Qwen affiche 1,3 dollar en entrée et 7,8 dollars en sortie, alors que Kimi est à 0,95 dollar en entrée et 4 dollars en sortie, donc Qwen paraît plus cher. Et dans l’annonce, il n’y a que deux benchmarks en commun, mais sur SWE-Bench Pro comme sur Terminal-Bench 2.0, Kimi était légèrement au-dessus de Qwen. Bien sûr, chaque modèle a ses points forts et les benchmarks ne font pas tout, mais si on se base uniquement sur les chiffres, Kimi paraît plus attractif

  • J’ai l’impression que l’attrait des modèles chinois a un peu diminué avec la hausse des prix. Et depuis la sortie de Gemma-4, je ne pense pas qu’il reste tant de modèles que ça sur la frontière de Pareto. Mon ressenti va dans le même sens, et les statistiques du leaderboard arena peuvent aussi être utiles

• L’ironie de cette annonce, à mon sens, est dans son nom même. Max-Preview est proprietary et cloud-only. Pour moi, le vrai Qwen important, c’est la série open weights que les gens font tourner sur leur propre matériel. Je fais tourner les 32B et 72B en local sur un dual A4000. Il y a encore un écart avec le Max hébergé, mais on voit cet écart se réduire à chaque sortie. Du coup, la vraie question intéressante n’est pas tant de savoir comment Max se compare à Opus, mais plutôt à partir de quand le palier open-weight rendra le palier cloud insignifiant pour la plupart des workloads

• Pendant que tout le monde court après le SOTA, moi je fais tourner plusieurs sessions parallèles de MiniMax M2.5 et j’abats tout mon travail de code pour 10 dollars par mois, sans presque jamais me heurter aux limites

  • S’il s’agit d’un vrai travail sérieux, je ne pense pas que la différence entre 10 et 100 dollars par mois soit un sujet majeur pour la plupart des développeurs professionnels. Il peut bien sûr y avoir des exceptions, comme les étudiants ou les utilisateurs dans des pays à faibles revenus, mais je suis toujours étonné de voir des développeurs très bien payés économiser autant sur le coût de leurs outils. Même les modèles SOTA actuels me paraissent encore trop peu fiables pour autre chose que des tâches ponctuelles, donc surveiller en plus des modèles moins performants pour économiser 10 à 100 dollars par mois ne me paraît pas du tout séduisant. Je m’amuse bien à expérimenter avec des modèles auto-hébergés pour de petites tâches jetables, mais sur du travail réellement important, je n’ai pas envie de gaspiller mon temps
  • Je suis curieux de savoir à qui vont ces 10 dollars par mois. J’ai envie de demander si c’est OpenRouter
  • Je suis curieux de savoir comment tu l’utilises concrètement. Est-ce que tu passes par opencode, ou par un autre frontend ?

• J’ai aussi consulté la documentation de Qwen sur le context caching et j’ai testé ensemble Opus, Codex et Qwen ; j’ai bien l’impression que Qwen est solide sur beaucoup de tâches de code. Mais ce qui m’importe le plus, c’est le comportement sur les sessions longues. Qwen met en avant une grande fenêtre de contexte, mais l’efficacité réelle sur les longs contextes semble fortement dépendre de sa manière de gérer le context caching. D’après la documentation officielle, il prend en charge à la fois le caching implicite et explicite, mais avec un TTL de seulement quelques minutes et des contraintes comme l’appariement basé sur les préfixes et un minimum de tokens. À cause de ces contraintes, dans des workflows de type agent de code où le contexte continue de grossir, la réutilisation du cache peut ne pas fonctionner aussi bien qu’on l’espère. Donc même si le prix par token paraît bas, sur les longues sessions le cache hit rate peut baisser, la recomputation augmenter, et le coût ressenti devenir plus élevé. Cela dit, sur des tâches liées à la sécurité, j’ai personnellement vu Qwen faire mieux qu’Opus dans certains cas. D’après mon expérience, Qwen est bien meilleur qu’Opus sur des tâches courtes au niveau d’une méthode ou d’une fonction isolée, mais dans l’expérience globale de code, il m’a davantage semblé être un générateur au niveau des fonctions qu’un assistant de code autonome end-to-end comme Claude

  • Cela dit, je pense quand même qu’il reste une best practice de couper les longues sessions et d’en relancer de nouvelles plus courtes. Dans les Claude Code Best Practices d’Anthropic, ils disent aussi qu’« une nouvelle session propre avec un meilleur prompt est presque toujours meilleure qu’une longue session où s’accumulent les correctifs »
  • La dernière fois que j’ai vérifié, le context caching ne changeait pas les tokens effectivement produits ; il ne servait qu’à réduire le coût et la latence

• Quand je vois Qwen se comparer à Opus 4.5, j’ai un peu de mal à prendre ça de bonne foi. Je peux comprendre qu’Opus 4.7, tout récent, n’y figure pas, mais Opus 4.6 existe depuis un bon moment déjà

  • Pour moi, Opus 4.5 a été le premier moment où j’ai eu l’impression qu’un modèle était suffisamment bon sur un large éventail de problèmes. Avant ça, utiliser l’IA pour le développement me faisait surtout perdre du temps à cause des hallucinations, donc ce n’était pas productif. Mais si les progrès s’étaient arrêtés à Opus 4.5, je pense quand même qu’on aurait déjà pu traiter énormément de tâches réelles très vite. Je ne crois plus que le développement logiciel reviendra à un mode entièrement centré sur le code écrit à la main. Donc si quelqu’un propose un niveau proche ou légèrement supérieur à Opus 4.5 pour un dixième du prix, cela peut déjà être très attractif pour beaucoup de monde. Bien sûr, du point de vue des développeurs occidentaux, payer plus de 100 dollars par mois pour Opus 4.7 reste très valable. Le temps perdu avec des modèles de niveau inférieur coûte bien plus cher. Pour l’instant, je compte continuer à payer une prime pour des modèles qui me font perdre moins de temps et qui produisent de meilleurs résultats avec moins de retouches de prompt. En même temps, la vitesse des changements est vraiment stupéfiante, et aujourd’hui j’ai l’impression que les modèles ouverts sont eux aussi arrivés à un niveau capable de rivaliser avec les modèles frontier d’il y a deux ans. Qwen 3.6 MoE 35B A3B ou les gros modèles Gemma 4 peuvent tourner sur du matériel assez ordinaire comme un Macbook performant, Strix Halo, ou des GPU récents de 24GB ou 32GB, sans être énormément plus chers qu’un laptop de développeur d’avant l’ère IA. Ils écrivent du code, rédigent plutôt bien, utilisent des outils, et leur longueur de contexte suffit pour un usage réel. Ce n’est pas encore Opus 4.5, mais c’est tout de même impressionnant. J’utilise déjà plusieurs modèles en parallèle pour la sécurité et la revue de code, et même si, pour l’essentiel du développement logiciel, je trouve encore Claude Code et Opus meilleurs, je suis tout à fait prêt à essayer Qwen. Les petits modèles s’en sortent déjà très bien vu leur taille, donc j’ai de bonnes attentes pour les gros
  • Si l’argent n’était vraiment pas un sujet, il suffirait au final de regarder uniquement les meilleures performances comme Codex 5.4 ou Opus 4.7. Mais pour beaucoup de gens, le ratio qualité/prix est une variable très importante. Même parmi les abonnés Claude, beaucoup ne peuvent pas utiliser Opus 4.7 en permanence à cause de la pression sur les coûts et les quotas, et se rabattent sur Sonnet ou d’anciens Opus. Donc si on regarde la courbe de valeur par rapport à la qualité, ce type de comparaison a tout à fait du sens
  • Ces derniers mois, les performances d’Opus 4.6 ont été trop irrégulières à mon goût, donc je n’avais pas envie de gaspiller des tokens
  • Quand Sonnet 4.6 est sorti, j’ai basculé mon modèle par défaut d’Opus vers Sonnet. À l’usage, Sonnet 4.6 me semblait proche d’un niveau Opus 4.5. Les 4.6 et 4.7 sont meilleures, mais sur la plupart des tâches le saut n’est plus si énorme, donc la réduction de coût est devenue un choix tout à fait rationnel. Si des modèles moins chers atteignent ce niveau, c’est encore plus marquant, et GLM 5.1 paraît déjà assez proche, donc je l’utilise beaucoup. Dans cette optique, comparer à Opus 4.5 me paraît aussi défendable
  • À mon avis, il faut comparer les choses avec les cibles les plus proches. Et quand les benchmarks sont publiés directement par le fournisseur, il est évidemment possible qu’il choisisse surtout les frameworks où son modèle brille et mette de côté ce qui lui est défavorable. Au final, ce sont donc surtout les benchmarks indépendants qui me paraissent dignes de confiance

• En regardant les fournisseurs chinois récemment, j’ai l’impression de voir un schéma. D’abord, ils évoluent vers des modèles closed source ; ensuite, ils augmentent assez fortement leurs prix. Dans certains cas, cela approche même les 100 %

  • Présenter cela comme si c’était une caractéristique propre aux entreprises chinoises me paraît un peu étrange. J’ai l’impression que les entreprises d’autres pays ne font pas du tout autrement
  • Qwen max a toujours été cloud only, et comme c’est un modèle de plus de 1T, il me paraît inévitable qu’il coûte cher
  • J’aurais envie de demander en quoi ces fortes hausses de prix sont différentes de ce que font les entreprises américaines
  • Je serais curieux de savoir si cela s’applique aussi à des modèles comme GLM 5.1, DeepSeek V3.2 ou le tout nouveau Kimi K2.6. En pratique, ça ne semblait pas vraiment coller à ces exemples
  • Cette méthode semble être quelque chose que les entreprises américaines aiment elles aussi énormément, non ?

• Ce qui est amusant, c’est qu’on peut très bien connaître toute la famille des modèles Qwen exécutables en local tout en ne connaissant absolument pas leur côté cloud. Moi, je connaissais surtout les séries 3.5 et peut-être un 3.6, et je n’avais encore jamais entendu parler du nom Plus avant aujourd’hui

  • Si je me souviens bien, la série Plus existe depuis le lancement de Qwen chat. J’ai même le souvenir d’avoir utilisé directement un modèle Plus au moins au début de l’année dernière