GLM 5.2 Reasoning Effort : le réglage qui divise les coûts par 20

GLM 5.2 est désormais disponible sur Synthorai à un prix par token environ six fois inférieur à celui des modèles frontier. La promesse d’un modèle open weight aux performances de premier plan est bien réelle. Mais le prix par token n’est pas le bon indicateur. Sur GLM 5.2, le coût réel d’une tâche de code peut varier de plus d’un ordre de grandeur selon un seul paramètre : le reasoning effort. Et le réglage par défaut est le pire choix. Bien configuré, GLM 5.2 fournit des réponses correctes et revient moins cher que les modèles frontier, aussi bien sur les tâches simples que difficiles. Avec le réglage par défaut, la même réponse coûte vingt fois plus cher et prend plusieurs minutes. Nous l’avons mesuré.

TL;DR

• GLM 5.2 est facturé sur Synthorai à $1.40/M en entrée et $4.40/M en sortie, soit environ six fois moins que le tarif de sortie de claude-opus-4-8.
• Sur une tâche de code simple, GLM 5.2 sans thinking a coûté $0.0008 et répondu en 5 secondes. Le réglage par défaut sans limite a produit la même réponse pour $0.0285 en 137 secondes.
• Sur une tâche difficile, reasoning_effort: high a donné la bonne réponse pour $0.0031 en 13 secondes, soit environ 20 fois moins cher et 30 fois plus rapide que le réglage par défaut sans limite ($0.062, 405 secondes).
• Sur les deux tâches, le niveau low de GLM a produit davantage de tokens de reasoning que high : le nom des niveaux ne correspond pas au nombre de tokens.

Présentation de GLM 5.2

GLM 5.2 est le modèle frontier open weight de Zhipu, publié le 2026-06-13. Il repose sur une architecture mixture-of-experts d’environ 744B de paramètres au total, dont environ 40B actifs, offre un contexte exploitable de 1M de tokens et utilise une licence MIT permettant l’auto-hébergement. Il cible le code et les workflows agentiques, avec de solides benchmarks publiés (SWE-bench Pro 62.1, Terminal-Bench 2.1 81.0, AIME 2026 99.2, GPQA Diamond 91.2). Sur Synthorai, il est disponible sous l’identifiant glm-5.2, au prix de $1.40 par million de tokens en entrée et $4.40 par million en sortie.

Le point qui détermine tout le reste : c’est un modèle de reasoning, et c’est vous qui choisissez jusqu’où il raisonne.

Positionnement tarifaire

Au tarif affiché par token, GLM 5.2 se situe nettement sous les modèles frontier occidentaux et parmi les modèles chinois les moins chers. Voici les tarifs Synthorai pour une sélection représentative :

Son tarif de sortie de $4.40 représente environ un septième de celui de gpt-5.5 et un sixième de celui de claude-opus-4-8, même si deepseek-v4-pro et kimi-k2.5 restent moins chers. GLM 5.2 offre donc des capacités de niveau frontier aux tarifs habituels des modèles chinois, sans être pour autant le moins cher du marché. L’écriture en cache n’est pas facturée séparément : elle l’est au tarif d’entrée, tandis que seule la lecture bénéficie du tarif réduit indiqué ci-dessus. La remise dépend du fournisseur. Pour GLM 5.2, une lecture en cache coûte environ un cinquième du tarif d’entrée. Les modèles frontier (gpt-5.5, claude-opus-4-8, gemini-3.1-pro) réduisent ce coût à environ un dixième.

Il marque aussi une nette montée en gamme par rapport à ses prédécesseurs. La génération GLM précédente était extrêmement bon marché. Les prix ont augmenté avec la gamme GLM 5, et GLM 5.2 atteint environ trois fois le tarif d’entrée de GLM-4.6, selon les tarifs officiels de Zhipu :

Cette hausse finance le contexte de 1M de tokens et les performances de niveau frontier. Mais le tarif par token ne raconte qu’une partie de l’histoire. Le coût réel de chaque tâche dépend du reasoning effort.

Le réglage du reasoning effort

Sur GLM 5.2, le reasoning ne se résume pas à un interrupteur. C’est un réglage progressif. Vous pouvez le désactiver (enable_thinking: false), définir reasoning_effort sur low, medium ou high, ou conserver le réglage par défaut, qui laisse le reasoning sans limite. Ce paramètre influe bien davantage sur les coûts et la latence que le tarif lui-même. Nous avons testé une tâche de code simple et une autre difficile avec chaque réglage, puis vérifié toutes les réponses par rapport à une implémentation de référence sur des centaines de cas aléatoires.

Une tâche simple : le reasoning ne fait qu’augmenter le coût

Planification d’intervalles pondérés, un problème de difficulté moyenne en programmation dynamique :

Deux constats ressortent. Sans thinking, la réponse est correcte et son coût est le plus faible du tableau, environ huit fois inférieur à celui des modèles frontier. Chaque niveau supplémentaire ne fait qu’augmenter le coût pour obtenir la même réponse. La facture dépend du reasoning, pas de la réponse : le code renvoyé par GLM compte environ 150 tokens à chaque fois, tandis que le reasoning préalable passe de zéro à environ 6,300 tokens, tous facturés au même tarif de sortie de $4.40/M. Le réglage par défaut sans limite consomme tous ces tokens pour arriver à la même réponse que le mode sans thinking. Ils représentent à eux seuls toute la différence de coût. Les modèles frontier répondent ici avec peu ou pas de reasoning déclaré : gpt-5.5 utilise 59 tokens de reasoning, tandis que les métriques de claude-opus-4-8 n’en indiquent aucun.

Une tâche difficile : le reasoning est utile, pas le réglage par défaut

Correspondance de chaînes avec jokers (? et *), un problème classique où les erreurs subtiles sont fréquentes. Sans thinking, GLM a échoué. Il a renvoyé une récursion avec mémoïsation :

def is_match(s, p):
    memo = {}
    def match(i, j):
        if (i, j) in memo:
            return memo[(i, j)]
        if j == len(p):
            result = i == len(s)
        elif i < len(s) and p[j] in (s[i], '?'):
            result = match(i + 1, j + 1)
        elif p[j] == '*':
            result = match(i + 1, j) or match(i, j + 1)
        else:
            result = False
        memo[(i, j)] = result
        return result
    return match(0, 0)

À première vue, le code semble correct, et l’utilisation d’un cache laisse penser que le cas a été traité avec soin. Mais dans la branche *, l’appel récursif match(i + 1, j) ne fixe aucune borne à i. Une fois la chaîne consommée, si le pattern contient encore un *, i continue d’augmenter indéfiniment jusqu’au dépassement de pile. Rapide, bon marché, mais faux.

En augmentant le niveau, GLM renvoie le bon algorithme itératif à deux pointeurs. Au lieu d’utiliser la récursion, il revient au dernier * rencontré :

def is_match(s, p):
    s_idx, p_idx, star_idx, match_idx = 0, 0, -1, 0
    while s_idx < len(s):
        if p_idx < len(p) and (p[p_idx] == '?' or p[p_idx] == s[s_idx]):
            s_idx += 1
            p_idx += 1
        elif p_idx < len(p) and p[p_idx] == '*':
            star_idx = p_idx
            match_idx = s_idx
            p_idx += 1
        elif star_idx != -1:
            p_idx = star_idx + 1
            match_idx += 1
            s_idx = match_idx
        else:
            return False
    while p_idx < len(p) and p[p_idx] == '*':
        p_idx += 1
    return p_idx == len(p)

Voici les résultats pour tous les réglages sur cette tâche :

Tous les niveaux explicites ont résolu le problème. Avec reasoning_effort: high, la réponse correcte a coûté $0.0031 et pris 13 secondes. C’est environ vingt fois moins cher et trente fois plus rapide que le réglage par défaut sans limite, pour la même réponse. Le coût est également inférieur à celui des modèles frontier, avec seulement quelques secondes de plus. Particularité à connaître : sur les deux tâches, le niveau low de GLM a systématiquement produit davantage de reasoning que high. Le nom des niveaux ne reflète donc pas le nombre de tokens. Les niveaux medium et high ont été les plus rapides et les moins chers.

Il faut éviter le réglage par défaut sans limite. Il cumule les inconvénients : il consomme du reasoning dont la tâche n’a peut-être pas besoin et prend plusieurs minutes pour aboutir à la même réponse que reasoning_effort: high, mais vingt fois plus cher.

Règle de décision

Le paramètre clé est le reasoning effort, et son niveau doit dépendre de la tâche, pas du modèle :

• Tâches simples ou à gros volume, lorsque la correction est facile à vérifier : désactivez le thinking (enable_thinking: false). La réponse reste correcte pour un coût environ huit fois inférieur aux modèles frontier.
• Problèmes plus difficiles, lorsque le mode sans thinking échoue : utilisez reasoning_effort: medium ou high. La réponse est correcte, coûte environ $0.003 par tâche, reste moins chère que les modèles frontier et ne prend que quelques secondes de plus.
• N’utilisez jamais le réglage par défaut sans limite. Laisser le reasoning actif sans plafond transforme une réponse à $0.003 en un appel de sept minutes à $0.06.

Si vous ne savez pas à l’avance si une tâche nécessite du reasoning, reasoning_effort: high constitue un réglage par défaut sûr : il a été peu coûteux, a résolu les deux tâches et n’a jamais dérivé.

Le cache réduit le coût de l’entrée, pas celui du reasoning

GLM 5.2 prend en charge le cache sur la gateway, avec les gains attendus. Nous avons envoyé un préfixe partagé de 1,494 tokens, un module de code à relire, puis posé plusieurs questions différentes :

Un préfixe volumineux est mis en cache après sa première utilisation. Les tokens d’entrée lus depuis le cache sont facturés à environ un cinquième du tarif d’entrée normal. Pour une requête par ailleurs identique, le coût passe ainsi de $0.0026 à $0.0009, soit une baisse d’environ 64 %. Une répétition exacte est servie directement depuis le cache sémantique : la réponse et le coût restent identiques à ceux de l’appel avec cache, mais le résultat revient en environ une seconde au lieu de cinq.

La limite est la même que pour le réglage du reasoning : la remise du cache porte sur l’entrée. Dès que le reasoning est actif, l’essentiel du coût et de la latence vient de sa sortie, qui n’est pas mise en cache. Le cache est donc particulièrement avantageux pour les tâches à contexte long sans thinking, par exemple lorsqu’un même system prompt ou codebase est envoyé à chaque appel. Son effet devient limité dès que le reasoning est actif.

Utilisation sur Synthorai

glm-5.2 est disponible sur la gateway. Nos tests font ressortir trois recommandations pratiques :

• Définissez explicitement le reasoning effort. Utilisez enable_thinking: false pour les tâches simples et reasoning_effort: medium ou high pour les problèmes plus difficiles. Évitez surtout de laisser le reasoning actif sans plafond, c’est-à-dire le réglage par défaut sans limite, qui mène à l’appel de sept minutes à $0.06.
• Utilisez le streaming lorsque le reasoning est actif. Une réponse avec reasoning peut prendre plusieurs minutes. Sans streaming, la connexion reste silencieuse assez longtemps pour que votre client expire probablement avant l’arrivée de la réponse. Avec stream: true, vous recevez la sortie au fil de l’eau, puis le résultat complet.
• Réutilisez votre contexte. Si vous envoyez le même system prompt volumineux ou la même codebase à chaque appel, le prefix caching réduit le coût d’entrée. Associé au mode sans thinking, il rend l’ensemble de la requête peu coûteux.

Le tarif est de $1.40 / $4.40 par million de tokens. La gateway renvoie un champ cost à chaque appel pour indiquer précisément le coût de la requête.

Conclusion

GLM 5.2 est un modèle de code réellement performant et peu coûteux. Bien configuré, il revient moins cher que les modèles frontier sur les tâches simples comme difficiles. Tout dépend du réglage. Son reasoning est ajustable, mais le comportement par défaut ne fixe aucune limite. C’est ainsi qu’une tâche censée coûter $0.003 devient un appel de sept minutes à $0.06. Utilisez enable_thinking: false pour les tâches simples, puis reasoning_effort: medium ou high pour le reste : GLM 5.2 restera à la fois économique et correct. Avec le réglage par défaut du reasoning, vous obtenez au contraire l’option la plus lente et la plus chère.

Sources

• VentureBeat : le modèle open weight GLM-5.2 de Z.ai bat GPT-5.5 sur les tâches de code longues pour un sixième du coût
• eigent.ai : caractéristiques et présentation de GLM-5.2
• CloudPrice : tarifs et caractéristiques de GLM-5.2
• Z.ai : tarifs officiels de l’API GLM (générations GLM-4.5 / 4.6 / 5)

Autres guides de cette série fondés sur des coûts mesurés : coût de la transcription audio sur sept modèles de reconnaissance vocale et coût de la génération d’images.

(Les tarifs Synthorai indiqués ci-dessus sont ceux de la plateforme au 2026-06-24 ; les tarifs des différentes générations de GLM proviennent de la grille officielle de Zhipu.)

Coûts mesurés sur Synthorai le 2026-06-24 (glm-5.2 à $1.40 / $4.40 par M de tokens) ; vérifiez les tarifs en vigueur avant de vous y fier.

← Retour au blog