Vous utilisez déjà GLM-5.1 en production. Vos boucles d'agents fonctionnent, votre assistant de codage expédie des diffs, et les factures sont prévisibles. Puis Z.ai lance GLM-5.2, et la question arrive sur votre bureau : devez-vous changer une ligne dans votre configuration et échanger l'identifiant du modèle, ou restez-vous sur votre version actuelle ?
Il s'agit d'une décision GLM-5.2 vs GLM-5.1, pas d'un tutoriel. Cet article ne contient donc pas d'explication de A à Z (si vous en avez besoin, l'aperçu de GLM-5.1 et le guide de l'API GLM-5.1 sont les bons points de départ) et va droit au fait : ce qui a réellement changé, ce qu'il vous en coûte de passer à la nouvelle version, et un verdict clair "mettre à jour si / rester si" à la fin.
En bref : la mise à niveau de GLM-5.2 concerne principalement le codage agentique et à long terme, le niveau de prix semble inchangé, et le passage est un simple changement d'identifiant de modèle sur une ligne. Pour la plupart des charges de travail axées sur le codage et l'utilisation d'outils, cette combinaison en fait un oui facile. La nuance réside dans les détails ci-dessous.
La version en 30 secondes
| GLM-5.1 | GLM-5.2 | |
|---|---|---|
| ID du modèle API | glm-5.1 |
glm-5.2 |
| Fenêtre de contexte | jusqu'à 1M de tokens | 1M de tokens (1 048 576) |
| Terminal-Bench 2.1 | 62.0 | 81.0 |
| SWE-bench Pro | 58.4 | 62.1 |
| MCP-Atlas | (génération précédente) | 77.0 |
| Attention | dense/standard | attention creuse IndexShare |
| Effort de réflexion | réflexion activée/désactivée | ajoute les niveaux Élevé et Max |
| Niveau de prix API | (même niveau) | 1,40 $ en entrée / 4,40 $ en sortie par 1M (vérifier en direct) |
Le fait marquant de tout le passage de GLM-5.1 à GLM-5.2 est Terminal-Bench. Tout le reste est incrémental ; Terminal-Bench ne l'est pas.
Ce qui a réellement changé dans GLM-5.2
Le codage agentique et terminal a fait un réel bond en avant
Les résultats publiés par Z.ai placent GLM-5.2 à 81.0 sur Terminal-Bench 2.1, contre 62.0 pour GLM-5.1. C'est le genre d'écart que l'on ne voit généralement pas au sein d'une même version mineure. Terminal-Bench mesure si un modèle peut piloter un véritable shell jusqu'à son achèvement : lire la sortie, récupérer des erreurs, enchaîner les commandes, terminer la tâche. Si votre cas d'utilisation est un agent qui vit dans un terminal ou exécute des chaînes d'outils multi-étapes, c'est l'amélioration de GLM-5.2 qui compte le plus.
Les autres chiffres de codage progressent également, mais de manière moins spectaculaire :
- SWE-bench Pro : 58.4 à 62.1 (Z.ai rapporte également GLM-5.2 devant GPT-5.5 à 58.6 ici)
- MCP-Atlas : 77.0, dans la même bande que GPT-5.5 (75.3) et Claude Opus 4.8 (77.8)
- Humanity’s Last Exam avec outils : 54.7 (GPT-5.5 52.2, selon Z.ai)
- AIME 2026 : 99.2, GPQA-Diamond : 91.2
Z.ai liste également GLM-5.2 comme le modèle open-source le plus performant sur FrontierSWE, PostTrainBench et SWE-Marathon. Traitez les benchmarks de lancement comme les résultats publiés de Z.ai jusqu'à ce que des tiers les reproduisent, mais la direction est claire : les gains les plus importants se situent dans le travail agentique, à long terme et utilisant des outils, plutôt que dans les questions-réponses ponctuelles. Pour une comparaison plus large, la comparaison GLM-5.1 vs Claude/GPT/Gemini/DeepSeek est une base utile pour situer la position de la version 5.1.
IndexShare : la nouvelle attention creuse
Le changement architectural dans GLM-5.2 est un schéma d'attention creuse que Z.ai appelle IndexShare. Au lieu de recalculer un index d'attention à chaque couche, il réutilise un seul indexeur pour chaque groupe de quatre couches d'attention creuse. L'effet pratique est une réduction du coût de l'attention sur un contexte long, ce qui est la partie coûteuse lorsque vous alimentez un modèle avec des centaines de milliers de tokens.
Le modèle lui-même reste une architecture à mélange d'experts (environ 753 milliards de paramètres, BF16) avec la même fenêtre de contexte de 1 million de tokens (1 048 576 tokens). IndexShare ne change pas le nombre de contexte principal ; il change la manière dont le modèle peut traiter ce contexte à moindre coût. Si vos invites sont courtes, vous le remarquerez à peine. Si vous intégrez des dépôts entiers ou de longues transcriptions dans le contexte, c'est la raison sous-jacente pour laquelle la mise à niveau peut sembler plus rapide sans coûter plus cher.
Niveaux d'effort de réflexion : Élevé et Max
GLM-5.1 vous permettait d'activer ou de désactiver la réflexion. GLM-5.2 ajoute des niveaux d'effort de réflexion gradués : Élevé et Max. Z.ai recommande Max pour le codage. Vous pouvez toujours désactiver complètement la réflexion pour les appels sensibles à la latence et à faible complexité.
Dans l'API, cela se traduit par deux paramètres que vous définissez ensemble :
{
"model": "glm-5.2",
"thinking": { "type": "enabled" },
"reasoning_effort": "max",
"temperature": 0.6,
"stream": true,
"messages": [
{ "role": "user", "content": "Refactoriser ce module et expliquer la différence." }
]
}
C'est le changement qui affecte le plus le comportement au quotidien. La même invite avec `reasoning_effort: "max"` réfléchira plus longtemps et renverra généralement un code plus robuste, au prix d'un plus grand nombre de tokens de sortie et d'une latence plus élevée. Ainsi, une partie de la mise à niveau de GLM-5.2 ne signifie pas que le modèle devient plus intelligent gratuitement ; c'est vous qui obtenez un moyen de consacrer de la réflexion là où cela rapporte et de l'éviter là où ce n'est pas nécessaire.
Ce qui n'a pas changé
C'est la partie qui rend la décision facile, elle mérite donc sa propre section.
- La surface de l'API est inchangée. Toujours compatible OpenAI, même forme de point de terminaison à `https://api.z.ai/api/paas/v4/chat/completions` (URL de base `https://api.z.ai/api/paas/v4/`), même authentification par clé Bearer, même appel de fonction/outil et streaming. Le guide de l'API GLM-5.1 pour lequel vous avez déjà écrit est toujours applicable.
- La fenêtre de contexte est la même : 1 million de tokens. Pas besoin de ré-architecturer votre stratégie de découpage.
- La licence et l'accès sont les mêmes. Poids ouverts, licence MIT, pas de restrictions régionales, disponible sur Hugging Face, OpenRouter (`z-ai/glm-5.2`), et Ollama (`glm-5.2`).
- C'est toujours du texte en entrée, du texte en sortie. Il n'y a pas de variante visuelle confirmée. Ne prévoyez pas de "GLM-5.2V" ; il n'a pas été annoncé.
- Le niveau de prix semble inchangé. C'est le point majeur pour l'économie de la mise à niveau, abordé ensuite.
L'économie de la mise à niveau
Voici pourquoi la question "devrais-je passer à GLM-5.2" reçoit une réponse plus favorable que la plupart des mises à jour de version : la pénalité de coût semble être quasiment nulle.
OpenRouter liste GLM-5.2 à 1,40 $ par million de tokens en entrée et 4,40 $ par million de tokens en sortie. VentureBeat rapporte que l'entrée en cache coûte environ 0,26 $ par million (attribuez ce chiffre à VentureBeat). Ces tarifs d'entrée/sortie se situent dans la même tranche de prix que les utilisateurs de GLM-5.1 payaient, donc la mise à niveau ne signifie pas un passage à une tranche de prix supérieure. Confirmez les chiffres en direct à la source avant d'engager un budget ; les pages de tarification changent. Le détail complet des prix se trouve dans l'article sur la tarification de GLM-5.2.
Le point de vue de VentureBeat est celui à citer à un décideur financier : ils décrivent GLM-5.2 comme surpassant GPT-5.5 sur les benchmarks de codage à long terme pour environ un sixième du coût. C'est leur caractérisation, pas une mesure d'Apidog, mais cela capture la proposition de valeur : un codage agentique de pointe à des prix open-source.
Quelques mises en garde sur les coûts pour que vous soyez lucide :
- La réflexion Max dépense des tokens de sortie. Si vous basculez chaque appel sur `reasoning_effort: "max"`, votre facture de tokens de sortie augmentera même si le taux par token est stable. Réservez Max pour les appels qui en bénéficient (refactoring lourds, modifications multi-fichiers) et laissez les appels routiniers sur Élevé ou la réflexion désactivée.
- Les niveaux du plan de codage GLM sont distincts de la tarification API par token, et les prix des niveaux publiés (Lite, Pro, Max, Team) proviennent de sources secondaires qui ne sont pas entièrement concordantes. Vérifiez les prix actuels du plan sur z.ai avant d'établir un budget. En juin 2026, ne supposez pas qu'une voie OpenRouter gratuite existe pour `glm-5.2` ; il n'y a pas de niveau gratuit confirmé.
Pour une vue plus large des coûts et de la vitesse chez différents fournisseurs, la comparaison de la vitesse et du coût de GLM-5 vs DeepSeek vs GPT-5 fournit un contexte utile.
Comment effectuer le changement concrètement
Pour les appels API directs, le changement est l'ID du modèle. C'est tout.
- "model": "glm-5.1",
+ "model": "glm-5.2",
Si vous souhaitez une gradation du raisonnement, ajoutez les deux paramètres de réflexion présentés précédemment. Tout le reste (authentification, point de terminaison, format de message) reste inchangé.
Pour Claude Code et d'autres clients de codage compatibles Anthropic, GLM-5.2 passe par le point de terminaison de codage de Z.ai. En juin 2026, l'URL de base de codage est `https://api.z.ai/api/coding/paas/v4` (certaines sources indiquent un chemin `open.z.ai` ; vérifiez l'URL en direct avant de la configurer). Un bloc d'environnement Claude Code typique :
export ANTHROPIC_BASE_URL="https://api.z.ai/api/coding/paas/v4"
export ANTHROPIC_API_KEY="votre-clé-de-plan-de-codage-glm"
export ANTHROPIC_DEFAULT_SONNET_MODEL="glm-5.2[1m]"
export ANTHROPIC_DEFAULT_OPUS_MODEL="glm-5.2[1m]"
export CLAUDE_CODE_AUTO_COMPACT_WINDOW=1000000
export API_TIMEOUT_MS=3000000
Deux choses à savoir ici. Le suffixe `[1m]` sélectionne la variante de contexte de 1M. Et `API_TIMEOUT_MS` est plus important qu'il n'y paraît : les appels longs avec un grand contexte seront interrompus par le délai d'attente par défaut, donc augmentez-le. Le guide approfondi de bout en bout pour les éditeurs et clients CLI se trouve dans le guide GLM-5.2 avec Claude Code, Cline et Cursor, et l'équivalent GLM-5.1 est la configuration GLM-5.1 + Claude Code si vous comparez les deux configurations côte à côte.
Testez le changement avant de lui faire confiance
Un changement d'ID de modèle est une ligne, mais le changement de comportement est réel, alors vérifiez-le comme un changement d'API plutôt que comme un ajustement de configuration. Envoyez le même ensemble d'invites à `glm-5.1` et `glm-5.2`, comparez les réponses, et vérifiez la latence et l'utilisation des tokens. Un client API comme Apidog rend cela concret : enregistrez une collection de requêtes, échangez le champ du modèle, exécutez les deux, et comparez le statut, la sortie et le timing en un seul endroit. Parce que l'API de Z.ai est compatible OpenAI, vous pointez Apidog vers le même point de terminaison, changez un champ, et ré-exécutez. Si vous ne l'avez pas déjà, vous pouvez télécharger Apidog et configurer un environnement de test côte à côte en quelques minutes. Ce contrôle de cinq minutes fait la différence entre "les benchmarks disent que c'est mieux" et "c'est mieux sur mes invites réelles".
Alors, la mise à niveau GLM-5.2 en vaut-elle la peine ?
Voici le verdict, formulé comme une décision plutôt qu'une évaluation.
Passez à GLM-5.2 si :
- Votre charge de travail est agentique, pilotée par terminal ou utilise des outils en plusieurs étapes. Le bond de Terminal-Bench de 62.0 à 81.0 est la raison la plus forte de passer à la nouvelle version, et il arrive précisément là où la 5.1 était la plus faible.
- Vous effectuez un réel travail de codage (refactorisations, modifications multi-fichiers, tâches de type SWE-bench). Les gains de SWE-bench Pro et MCP-Atlas se cumulent sur une journée de travail.
- Vous exécutez des invites à contexte long. IndexShare rend le traitement des appels à grand contexte moins cher, et le niveau de prix semble inchangé, il y a donc peu d'inconvénients.
- Vous voulez un contrôle sur le raisonnement. Les niveaux Élevé et Max vous permettent de consacrer de la réflexion là où cela rapporte et de l'éviter là où ce n'est pas nécessaire.
Restez sur GLM-5.1 si :
- Vous exécutez des invites courtes, simples, sensibles à la latence, où les nouvelles forces ne s'appliquent pas et où la version 5.1 répond déjà à vos exigences. Dans ce cas, la mise à niveau est réelle mais invisible ; conservez la configuration GLM-5.1 à laquelle vous faites confiance.
- Vous êtes en cours de publication et votre version est gelée. Un changement d'ID de modèle sur une ligne présente un faible risque, mais aucun changement ne bat un changement à faible risque pendant un gel. Planifiez-le pour la prochaine fenêtre.
- Vous hébergez vous-même et ne pouvez pas encore extraire ou servir les poids de 753 milliards de paramètres avec la précision et le débit dont vous avez besoin. Les benchmarks ne sont d'aucune aide si vous ne pouvez pas exécuter le modèle.
Pour la plupart des équipes qui lisent une comparaison GLM-5.2 vs GLM-5.1 parce qu'elles utilisent déjà la 5.1, la réponse honnête est : mettez à niveau, mais testez d'abord. Le changement est peu coûteux, les gains agentiques sont substantiels, et le niveau de prix ne vous pénalise pas pour le passage. Le seul coût réel est l'heure que vous passerez à le valider sur vos propres invites, et cette heure vaut la peine d'être dépensée.