Prix de l’API Qwen 3.8 Max : 16 tokens battent le mode sans réflexion

Qwen 3.8 Max facture $2 par million de tokens en entrée et $6 par million en sortie. Pourtant, sa configuration fiable la moins chère n’est pas celle que l’API semble proposer. Sur notre exercice d’arithmétique en deux étapes, désactiver la réflexion avec reasoning_effort: "none" a fait chuter le score de 4/4 à 1/6. Un budget ferme de seulement 16 tokens de réflexion a rétabli un score de 6/6, avec en moyenne un cinquième de tokens de sortie en moins par rapport au réglage par défaut. La semaine du lancement a multiplié les affirmations sur les capacités du modèle sans fournir grand-chose pour les vérifier : aucune model card, aucun tableau public de benchmarks et uniquement des évaluations internes, ce que Hacker News n’a pas tardé à relever. La facturation, elle, peut être mesurée par n’importe qui disposant d’une clé API. Dès le premier jour, nous avons testé qwen3.8-max via la gateway Synthorai : tous les réglages de réflexion acceptés par l’API, leur coût en tokens de raisonnement, le seuil et le délai de création du cache implicite, la fenêtre de contexte annoncée à 1M et les éléments repris de Qwen 3.7.

TL;DR

• Les sept valeurs de reasoning_effort de qwen3.8-max se ramènent à quatre comportements mesurés : désactivé, plafond de 4,096 tokens, plafond de 16,384 tokens et absence de plafond.
• thinking_budget est exact : avec 16 tokens demandés, le compteur en indique 16 ; le maximum est de 262,144.
• Sans réflexion, notre exercice d’arithmétique en deux étapes est tombé à 1/6 ; un budget de 16 tokens a obtenu 6/6 pour un coût inférieur.
• Le cache implicite se crée en moins de 0.3 seconde et les lectures coûtent $0.25/1M, mais aucun prompt inférieur à environ 4,300 tokens n’est mis en cache.
• Les limites d’entrée sont exactes et les dépassements échouent explicitement : 991,808 sans réflexion, 983,616 avec réflexion.

Que font réellement les réglages de réflexion de Qwen 3.8 Max ?

Trois paramètres fonctionnent, mais ce ne sont pas les trois indiqués dans la documentation. Les documentations tierces donnent trois valeurs pour reasoning_effort : low, medium et xhigh, cette dernière étant la valeur par défaut. L’API que nous avons testée en accepte sept : none, minimal, low, medium, high, xhigh et max. Une autre valeur est rejetée avec cette liste exacte de valeurs autorisées. S’ajoutent les paramètres natifs thinking_budget, un entier positif limité à 262,144, et enable_thinking, un booléen. Ils sont transmis au fournisseur, qui les valide lui-même : un budget de 0 ou de 262,145 renvoie une erreur 400 indiquant la limite.

Sur des tâches ordinaires, impossible de distinguer les niveaux d’effort. Entre les questions-réponses triviales, l’arithmétique en deux étapes et un problème de combinatoire de difficulté moyenne, low, medium, high, xhigh et le réglage par défaut consomment tous des tokens de raisonnement dans la même plage, avec la même variabilité. Aucun niveau ne se détache. Les différences n’apparaissent que sur une tâche nécessitant plusieurs dizaines de milliers de tokens de réflexion. Sur un problème de comptage de nombres premiers qui a consommé 45,129 tokens de raisonnement sans contrainte, les plafonds ont fini par s’appliquer :

Le modèle explicatif qui correspond à toutes nos observations est simple : chaque niveau d’effort applique un plafond prédéfini au budget de réflexion, et les sept noms se ramènent à quatre comportements. Le premier désactive la réflexion : none et enable_thinking: false ont un comportement identique. Minimal et low partagent le même plafond de 4,096 tokens. Medium le quadruple à 16,384. High, xhigh, max et le réglage par défaut forment le quatrième niveau : aucun n’a atteint son plafond sur cette tâche. Selon les exécutions, ils ont consommé entre 35K et 45K tokens, une variance normale à cette profondeur. S’il existe une différence entre les trois niveaux supérieurs, elle se situe au-delà de 45K tokens de réflexion, une profondeur rarement atteinte par le trafic de production. L’affirmation de la documentation selon laquelle xhigh est le réglage par défaut reste compatible avec toutes nos mesures. Le résultat est net : toutes les exécutions plafonnées ont donné une mauvaise réponse, et toutes les exécutions non plafonnées ont répondu correctement. Tant que le plafond n’est pas atteint, les niveaux se comportent de la même façon, ce qui donne l’impression que le réglage ne sert à rien sur le trafic courant. Une fois dépassé, le plafond interrompt la réflexion en pleine tâche. Pour définir une limite précise, mieux vaut ignorer les préréglages et configurer directement thinking_budget. La section suivante détaille son fonctionnement.

Comment fonctionne réellement thinking_budget ?

La limite est appliquée au token près. Il s’agit d’un plafond, pas d’un quota, et une limite intermédiaire peut coûter plus cher que l’absence totale de limite. thinking_budget est le paramètre entier natif de DashScope. Sa plage va de 1 à 262,144, avec une valeur par défaut documentée de 131,072. Il est hérité de la famille open weight Qwen3 et fixe le nombre maximal de tokens de raisonnement pour un appel. Les valeurs 0 et 262,145 sont rejetées avec une erreur 400 indiquant la plage autorisée. En dessous du plafond, rien ne change : sur une tâche qui consomme naturellement quelques centaines de tokens de réflexion, un budget de 8,192 en a consommé 331 puis 485, comme sans budget. Lorsque le plafond est atteint, la limite est exacte au token près : avec des budgets de 16, 64 et 256, le raisonnement s’est arrêté précisément à 16, 64 et 256 lors de chaque exécution.

Le comportement au moment de la coupure est le point intéressant. Le modèle n’abandonne pas la tâche : il arrête de raisonner et termine le travail dans la réponse visible. Sur un problème de combinatoire de difficulté moyenne, le comptage des pavages d’une grille 2x12 avec des dominos, chaque budget a produit la bonne réponse. En revanche, le total de tokens ne suit pas la courbe attendue :

La courbe n’est pas monotone. Avec un budget de 256 tokens, le coût était 2.5x supérieur à celui d’une exécution sans budget. Le modèle a utilisé son budget pour commencer un raisonnement, a été interrompu en plein milieu, puis a recalculé la réponse étape par étape dans le canal visible. Le budget le plus faible a fait mieux que les valeurs intermédiaires : 16 tokens ne suffisent pas pour entamer un vrai raisonnement, donc le modèle passe directement à un calcul visible et compact. Trois règles se dégagent. Premièrement, les budgets minuscules constituent un vrai levier pour les tâches simples à moyennes : avec 16 tokens, notre lot d’exercices d’arithmétique en deux étapes a obtenu 6/6 pour 98-161 tokens au total, contre 126-207 avec le réglage par défaut. Deuxièmement, n’appliquez pas de plafonds intermédiaires à du trafic dont vous ignorez la complexité. Ils tombent dans une zone défavorable où le raisonnement est interrompu alors qu’il est déjà engagé, ce qui fait payer le travail deux fois. Les lignes à 4,096 et 16,384 de la tâche complexe illustrent le même échec à plus grande échelle, avec en plus une mauvaise réponse. Troisièmement, un budget atteint modifie la forme de la sortie : les exécutions plafonnées montrent leur calcul dans la réponse, ce qui peut poser problème si un parseur attend uniquement le résultat.

Que reste-t-il de la documentation du premier jour après vérification ?

Environ la moitié. Il est utile de publier ce bilan, puisque le reste des annonces de ce lancement ne peut pas encore être vérifié indépendamment. Tous les résultats ci-dessous viennent de nos propres compteurs et tests :

La partie facturation est la plus fiable : tout ce qui détermine le montant payé est précis et strictement appliqué. La documentation des paramètres, elle, ne reflète pas encore le comportement réel de l’API.

Désactiver la réflexion permet-il d’économiser ?

Oui pour les tokens, mais au prix de la précision. Un meilleur compromis ne demande que deux lignes de configuration supplémentaires. Dans notre lot reproductible d’exercices d’arithmétique en deux étapes, 1850 caisses contenant 24 pièces chacune, 75% expédiées et 3,120 reçues, la configuration par défaut a obtenu 4/4 avec 126-207 tokens de complétion par appel. Avec reasoning_effort: "none", les réponses ne comptaient que 4-5 tokens, mais le score est tombé à 1/6. Le même prompt avec thinking_budget: 16 a obtenu 6/6 pour 98-161 tokens de complétion. Sur ce type de tâche, ce réglage est à la fois moins cher que la valeur par défaut et aussi précis. L’arithmétique en une seule étape est restée à 3/3 même avec none. La désactivation est donc adaptée aux recherches et transformations en une étape ; ce sont les tâches en plusieurs étapes qui s’effondrent. Ce n’est pas une régression de la version 3.8 : avec la réflexion désactivée, qwen3.7-max a obtenu 3/6 sur le même lot.

Sur les tâches difficiles, la zone défavorable décrite dans la section consacrée au budget se traduit directement en dollars. Lors de l’exercice complexe de comptage de nombres premiers, le préréglage low a consommé ses 4,096 tokens de réflexion, puis 13,882 tokens supplémentaires pour vérifier visiblement les candidats, avant de donner une mauvaise réponse : $0.11 pour une réponse incorrecte, contre $0.27 pour la bonne réponse obtenue avec le réglage par défaut. Sur les tâches difficiles, la désactivation produit le même phénomène. Sans réflexion, les versions 3.8 et 3.7 ont toutes deux généré une énumération visible de 13-15K tokens. Sur une seule exécution chacune, l’une a trouvé le bon total et l’autre s’est trompée d’un seul nombre premier. Un budget qui interrompt le raisonnement peut donc augmenter le coût total tout en réduisant la qualité. Plafonnez la réflexion sur les tâches dont vous savez qu’elles sont simples ; laissez les tâches complexes raisonner.

La fenêtre de contexte de 1M tokens est-elle réelle ?

En pratique, oui, avec des limites exactes et transparentes. L’API accepte jusqu’à 991,808 tokens en entrée sans réflexion et 983,616 avec réflexion. Les deux limites échouent explicitement : une requête trop grande est rejetée avec une erreur 400 indiquant la limite exacte, au lieu de tronquer silencieusement le document. Le rappel d’une information cible a fonctionné à toutes les tailles testées, 161K, 677K et 919K tokens. Le modèle a renvoyé à l’identique le code de remplacement inséré, avec une latence comprise entre 11 et 63 secondes. Au tarif public, une requête de 919K tokens coûte environ $1.84. La fenêtre est donc bien réelle, mais son utilisation complète doit relever d’un choix d’architecture, pas d’un réglage par défaut.

Que fournit le cache implicite, et à partir de quel seuil ?

C’est la création de cache la plus rapide que nous ayons mesurée, mais son seuil est inhabituellement élevé. En répétant un prompt salé de 6,103 tokens, nous avons obtenu un hit dès la requête suivante, 0.3 seconde plus tard. Contrairement au délai de création de plusieurs dizaines de secondes de Gemini, aucune phase de warm-up n’est à prendre en compte dans l’architecture. Les hits ont continué à +5 et +15 minutes sans nouvelle initialisation. À +45 minutes, l’entrée avait disparu. La durée de vie opérationnelle se situe donc entre 15 et 45 minutes d’inactivité. Les lectures sont facturées $0.25 par million, soit 0.125x le tarif d’entrée, sans surcoût d’écriture. La remise est appliquée automatiquement dans le champ cached_tokens et dans le coût mesuré.

Le seuil est le principal inconvénient. Un prompt de 4,221 tokens n’a jamais produit de hit ; un prompt de 4,360 tokens en a produit un. Chaque premier hit portait exactement sur 4,096 tokens. En dessous d’environ 4.3K tokens de prompt, ce cache n’est donc pas utilisable. La différence est nette avec le minimum de 1,024 tokens de Claude et la mise en cache automatique par petits blocs de Kimi K3. Au-dessus du seuil, les hits sont quantifiés par blocs de 128 tokens. Nous avons observé 4,096, 8,320, 12,544 et 16,768. La proportion du préfixe initial effectivement couverte variait toutefois de 51% à 96%. Pour vos estimations, prévoyez donc une remise sur l’essentiel d’un long préfixe, pas sur sa totalité.

Les sorties structurées et les appels d’outils paient-ils le coût du raisonnement ?

Par défaut, oui. Ce sont aussi les cas les moins risqués pour le supprimer. La sortie stricte en json_schema fonctionne et applique réellement le schéma : la même extraction sans schéma est revenue entourée de blocs Markdown. Avec la configuration par défaut, l’extraction des quatre champs d’une facture a consommé 252 tokens de raisonnement avant de produire 57 tokens de JSON. Avec reasoning_effort: "none", elle a renvoyé un JSON valide et correct en 54 tokens au total, soit 5.7x moins. thinking_budget: 16 se situait entre les deux. Même constat pour le choix d’un outil : sans réflexion, le modèle a appelé la bonne fonction en utilisant trois fois moins de tokens que le réglage par défaut. Les extractions et le routage en une seule étape sont précisément les cas où la désactivation est sûre. À $6/1M en sortie, ces économies finissent par peser.

Autre point de facturation pour les développeurs d’agents : l’API renvoie l’intégralité de la chaîne de pensée dans reasoning_content, et la documentation demande aux clients multi-tours de la retransmettre sans modification. Cette règle n’est pas appliquée. Nous avons rejoué les tours en incluant le raisonnement, en l’omettant et en le modifiant volontairement. Les trois variantes ont été acceptées et la précision sur les chaînes courtes n’a pas changé. Le raisonnement retransmis est facturé comme des tokens d’entrée ordinaires. L’omettre réduit donc réellement le coût du trafic multi-tours, tant que vos tests ne montrent pas de baisse de qualité.

Qu’est-ce qui vient de Qwen 3.7, et qu’est-ce qui a changé ?

Le tokenizer n’a pas changé, ce qui permet de réutiliser directement vos budgets de tokens. Des corpus identiques en anglais, chinois, japonais et code ont produit exactement les mêmes nombres de tokens sur qwen3.8-max, qwen3.7-max, qwen3.7-plus, qwen3.6-flash et qwen3.5-flash. Les estimations de coût par langue de notre étude des tokenizers par langue restent donc valables sans modification.

Deux éléments ont changé. D’abord, 3.8-max ajoute un coût fixe au prompt que les autres modèles de la famille n’ont pas. Le même message d’un caractère comptait 49 tokens de prompt sur 3.8-max, contre 11 sur tous les autres modèles Qwen testés, soit un supplément constant de 38 tokens par appel. C’est négligeable sur les prompts longs, mais mesurable en pourcentage sur les requêtes courtes et fréquentes. Ensuite, la réflexion est toujours disponible au lieu de dépendre d’un changement de mode. Elle se règle avec les sept niveaux et le budget exact décrits plus haut ; les contrôles de la version 3.7 étaient moins précis. Une dernière précision tarifaire s’impose, car deux formules ont circulé pendant la preview : les abonnements Token Plan, de $6 à $68 par mois avec de fortes remises en heures creuses, concernent les applications d’Alibaba, pas l’API. Via l’API, le tarif public reste de $2/$6. Lors de cette étude, notre compteur de gateway correspondait à ce tarif jusqu’à la quatrième décimale sur chaque appel.

FAQ

Peut-on désactiver la réflexion sur Qwen 3.8 Max ?

Oui, complètement : reasoning_effort: "none" ou enable_thinking: false supprime tous les tokens de raisonnement. Réservez ce réglage aux tâches en une étape. Sur notre lot d’exercices d’arithmétique en deux étapes, il a obtenu 1/6, contre 6/6 avec un thinking_budget de 16 tokens pour un nombre de tokens comparable ou inférieur. Pour le trafic en plusieurs étapes, le réglage minimal devrait donc être un petit budget, pas une désactivation complète.

Quelle est la taille minimale d’un prompt pour le cache de Qwen 3.8 Max ?

Environ 4,300 tokens d’après nos tests : un prompt de 4,221 tokens n’a jamais produit de hit, tandis qu’un prompt de 4,360 tokens en a produit un. Les premiers hits portent toujours sur exactement 4,096 tokens. Sous ce seuil, aucune remise ne s’applique. Au-dessus, les lectures coûtent $0.25/1M sans surcoût d’écriture, et l’entrée peut être lue 0.3 seconde après son initialisation.

Qwen 3.8 Max prend-il en charge reasoning_effort ?

Sept valeurs sont acceptées : none, minimal, low, medium, high, xhigh et max. Ces niveaux se comportent toutefois comme des plafonds de budget de réflexion. Ils ne se différencient que lorsqu’une tâche dépasse l’un de ces plafonds. Pour un contrôle déterministe, configurez directement thinking_budget : la limite est appliquée au token près, la valeur 0 est rejetée et le maximum est de 262,144. Les outils clients ne s’accordent pas encore sur les niveaux disponibles ; cette liste correspond aux valeurs acceptées par l’API le jour du lancement.

Faut-il renvoyer reasoning_content dans les conversations multi-tours ?

La documentation l’exige, mais l’API ne le vérifie pas. Lors de nos tests, un historique de raisonnement omis ou même modifié a été accepté sans erreur ni perte de précision sur les chaînes courtes. Le raisonnement retransmis est facturé comme une entrée normale. Ne pas le renvoyer constitue donc un levier de réduction des coûts tant que vos propres évaluations ne montrent pas de baisse de qualité sur les chaînes longues.

Mesures effectuées le 2026-08-03 via la gateway Synthorai avec qwen3.8-max et des comparaisons sur qwen3.7-max, qwen3.7-plus, qwen3.6-flash et qwen3.5-flash : tests d’acceptation des niveaux, de valeurs invalides et des limites de max_tokens ; tâche complexe consommant naturellement 45K tokens pour déclencher les plafonds d’effort ; lot fixe et reproductible pour mesurer la chute de précision (n=4-6 par variante, avec salage) ; paires de cache salées espacées de 2-3s et séries de délais ; tests de rappel et de dépassement entre 161K et 919K tokens ; comptage identique sur quatre corpus pour les tokenizers. Les montants en dollars proviennent des coûts facturés par le compteur de la gateway aux tarifs publics ($2/$6 par 1M). Les remises, tarifs et comportements de la période de preview peuvent évoluer ; vérifiez-les dans vos propres relevés d’utilisation.

← Retour au blog