On June 13, 2026, Zhipu AI (which now brands its products as Z.ai) pushed GLM 5.2 to every tier of its GLM Coding Plan. The headline number is a 1,000,000-token context window, five times what GLM 5.1 offered, paired with MIT-licensed open weights that Zhipu promised would land within the week alongside the standalone API and chatbot. For a model aimed squarely at long-horizon agentic coding, the size of that context jump is the whole story.
Ce qui manquait dans l’annonce du lancement était tout aussi remarquable : aucun score de benchmark n’était fourni. Aucun résultat sur SWE-bench, aucun sur Terminal-Bench, aucun sur Code Arena. Cela est inhabituel pour une sortie de pointe, et durant les premiers jours, tout ce qui était écrit sur les « performances » de GLM 5.2 provenait soit du marketing du fournisseur, soit d’évaluations informelles réalisées par des particuliers pendant leur week-end. Tout changea lorsque les poids ouverts furent publiés le 16 juin : Zhipu publia une suite complète de benchmarks, suivie rapidement par des évaluateurs indépendants. Cet article décrit précisément ce qu’est réellement GLM 5.2, les caractéristiques confirmées par Zhipu, les résultats actuellement disponibles (et le degré de confiance qu’on peut leur accorder), comment y accéder ou l’héberger soi-même à cette échelle, sa comparaison avec GLM 5.1 et d’autres modèles ouverts de programmation, ainsi que les profils d’utilisateurs pour lesquels il vaut la peine de s’y intéresser.
Points clés
- Lancé le 13 juin 2026 dans le cadre du « GLM Coding Plan » ; l’API, le chatbot et les poids ouverts sous licence MIT sont arrivés le 16 juin.
- modèle MoE (Mixture-of-Experts) d’environ 753 milliards de paramètres (selon la fiche technique officielle de Zhipu), avec environ 40 milliards de paramètres actifs par token, exposé dans Claude Code sous l’identifiant de modèle
glm-5.2[1m](identifiant de baseglm-5.2). - fenêtre de contexte de 1 000 000 tokens (contre environ 200 000 tokens pour GLM 5.1), avec une sortie limitée à 131 072 tokens et deux modes de raisonnement : High et Max.
- Point de terminaison compatible avec Anthropic ce qui signifie que Claude Code, Cline, OpenCode, OpenClaw et d'autres y accèdent simplement en modifiant une URL de base.
- Des benchmarks existent désormais. Ils étaient absents lors du lancement progressif du 13 juin, mais ont été publiés conjointement avec les poids : résultats déclarés par le fournisseur (SWE-bench Pro 62,1 et Terminal-Bench 2.1 de 81,0), ainsi qu’un score indépendant de l’« Artificial Analysis Intelligence Index » de 51, plaçant GLM 5.2 au sommet des modèles à poids ouverts. Les chiffres fournis par le fournisseur doivent être considérés comme tels ; les résultats indépendants corroborent globalement cette analyse. Analyse artificielle Avec un score de 51 à l'indice d'intelligence, ce modèle s'impose comme le meilleur de la catégorie « poids libre ». Il convient de considérer les chiffres fournis par les fabricants comme tels ; ceux des organismes indépendants viennent corroborer cette tendance générale.
- L’hébergement local relève d’une infrastructure de centre de données : environ 8 cartes H200 en FP8, ou moins de GPU avec une quantification INT4 agressive, avant même de prendre en compte le cache KV de 1 million de tokens.
- Ce qu’est réellement GLM 5.2
- Les caractéristiques techniques et les benchmarks publiés tardivement
- Comment accéder à GLM 5.2 dans le cloud
- La réalité matérielle de l’exécution locale d’un modèle d’environ 753 milliards de paramètres
- GLM 5.2 comparé à GLM 5.1 et aux autres modèles à poids ouverts
- FAQ
- Conclusion
- Articles connexes
Ce qu’est réellement GLM 5.2
GLM 5.2 est la troisième version de la série GLM-5 de Zhipu, après GLM 5 et GLM 5.1, et a été conçu pour une seule tâche : écrire et maintenir des logiciels au cours de sessions longues et multi-étapes. Il s’agit d’un modèle MoE (Mixture-of-Experts) creux comportant environ 753 milliards de paramètres au total, mais seulement environ 40 milliards de paramètres actifs pour chaque token traité. (La fiche technique du modèle publiée par Zhipu sur Hugging Face indique 753 milliards ; certains outils tiers arrondissent ce chiffre à environ 744 milliards, identique à celui de GLM 5.1.) Cette structure creuse permet à un modèle aussi volumineux de fonctionner à une vitesse et à un coût utilisables, car la charge de calcul dépend uniquement des ~40 milliards de paramètres actifs, et non des 753 milliards au total, à chaque passage avant.
Deux éléments distinguent la génération GLM 5.2 de son prédécesseur. Premièrement, le contexte : le modèle accepte jusqu’à 1 000 000 tokens en entrée. L’API autonome expose un identifiant de modèle par défaut de glm-5.2 (avec une fenêtre de contexte réduite), tandis que la fenêtre complète de 1 million de tokens est désignée par glm-5.2[1m] — la variante à intégrer dans Claude Code. Un million de tokens suffit pour contenir un dépôt de taille moyenne, ses tests et un long historique de travail dans une seule fenêtre. Deuxièmement, la sortie : le modèle peut générer jusqu’à 131 072 tokens en une seule réponse, ce qui revêt une importance particulière lorsqu’un agent produit un module entier ou une modification étendue plutôt qu’un simple extrait de code.
Zhipu a remplacé les anciens réglages d’effort par deux niveaux de « charge cognitive » : High et Max, recommandant explicitement le mode Max pour les travaux complexes et multi-étapes de programmation. Aucun réglage Low ou Auto n’est disponible. Si vous souhaitez comprendre les modèles antérieurs de Zhipu et la trajectoire de l’entreprise, notre introduction à la gamme de modèles GLM de Zhipu vous présente l’arbre généalogique complet.
Les caractéristiques techniques et les benchmarks publiés tardivement
Voici la partie qu’il vaut mieux lire lentement, car la situation a évolué très rapidement. Zhipu a livré GLM 5.2 au Coding Plan le 13 juin avec aucune évaluation publiée de quelque nature que ce soit. Les médias ayant couvert ce lancement discret — notamment MarkTechPost — ont tous relevé le même point : l’annonce mentionnait la disponibilité, la longueur de contexte et la feuille de route open source, mais ne disait rien des performances du modèle.
Cela a changé le 16 juin, lorsque les poids ouverts ont été rendus publics sur Hugging Face et que Zhipu a publié une table de références (benchmarks) en parallèle. Le « vide en matière de benchmarks » était donc bien réel, mais il s’agissait d’un décalage temporel lié au lancement, non d’une absence durable. Deux conclusions s’ensuivent.
Premièrement, les chiffres communiqués par le fournisseur. Sur la fiche technique officielle de Zhipu, GLM 5.2 obtient un score de 62,1 sur SWE-bench Pro (versus 58.4 for GLM 5.1 and 58.6 for GPT-5.5, but behind Claude Opus 4.8 at 69.2) and 81,0 sur Terminal-Bench 2.1 (contre environ 63,5 pour GLM 5.1, juste derrière Opus 4.8 à 85,0 et GPT-5.5 à 84,0). Sur la suite FrontierSWE, conçue pour les tâches à long horizon, Zhipu indique que GLM 5.2 accuse un retard d’environ un point par rapport à Opus 4.8. Ces chiffres proviennent de tests réalisés par le fournisseur lui-même et doivent être interprétés comme tels — des choix favorables d’environnement de test sont courants dans les tableaux fournis en première partie.
Deuxièmement, et plus utile encore, des évaluateurs indépendants se sont désormais exprimés et confirment globalement cette image. Analyse artificielle attribue à GLM 5.2 un score de 51 sur son Intelligence Index v4.1, ce qui en fait le modèle open weights le plus performant, devançant MiniMax-M3 (44), DeepSeek V4 Pro (44) and Kimi K2.6 (43). On the community-voted Code Arena, GLM 5.2 (Max) ranks #2 in the Frontend/WebDev leaderboard, behind only Claude Fable 5 et nettement devant les autres modèles open source. Une réserve réelle mise en lumière par les données indépendantes : GLM 5.2 consomme beaucoup plus de jetons en sortie par tâche que ses concurrents (Artificial Analysis a mesuré environ 43 000 jetons par tâche sur l’Intelligence Index, contre environ 26 000 pour GLM 5.1), ce qui réduit son avantage coût sur les tâches longues.
Ainsi, la formulation honnête aujourd’hui n’est pas « aucun chiffre, ne faites confiance à rien ». Elle est plutôt la suivante : GLM 5.2 est un modèle open weights vérifié et performant sur les classements indépendants d’intelligence générale et de codage frontend, tandis que ses scores fournis en première partie sur les tâches agentic de codage (SWE-bench Pro, Terminal-Bench) doivent être confrontés à une évaluation neutre — comme LiveBench ou vos propres tests — avant de considérer comme définitif tout titre du type « bat GPT-5.5 ». Certains de ces titres sont techniquement fondés sur des benchmarks spécifiques — GLM 5.2 dépasse effectivement GPT-5.5 sur SWE-bench Pro dans le tableau de Zhipu —, mais il perd face à Claude Opus 4.8 sur la majeure partie de la même suite ; la formulation compte donc beaucoup.
| Attribut | GLM 5.2 (confirmé) |
|---|---|
| Lancement du Coding Plan | 13 juin 2026 |
| API et poids ouverts | 16 juin 2026 |
| Nombre total de paramètres | ~753 milliards (MoE ; certains trackers indiquent ~744 milliards) |
| Actifs par jeton | ~40 milliards |
| Fenêtre de contexte | 1 000 000 jetons (glm-5.2[1m]) |
| Sortie maximale | 131 072 jetons |
| Modes de raisonnement | High, Max |
| Licence | Licence MIT (poids ouverts) |
| Benchmark indépendant | Intelligence Index v51 d’Artificial Analysis (meilleur modèle open weights) |
Comment accéder à GLM 5.2 dans le cloud
La voie la plus rapide est le GLM Coding Plan, un abonnement qui achemine les agents de codage via les points de terminaison hébergés de Zhipu. Les offres promotionnelles de lancement sont approximativement de 10 $/mois pour la version Lite (~400 requêtes/semaine), ~30 $/mois pour la version Pro (~2 000 requêtes/semaine) et ~80 $/mois pour la version Max (~8 000 requêtes/semaine), avec un tarif par poste pour les équipes. Les prix affichés (hors promotion) sont plus élevés — certains revendeurs citent des fourchettes proches de 18 $ / 72 $ / 160 $ — et les quotas évoluent ; veuillez donc vérifier les tarifs actuels sur Z.ai avant de souscrire.
Si vous préférez payer au jeton, l’API autonome est facturée environ 1,40 $ par million de jetons d’entrée et 4,40 $ par million de jetons de sortie sur le point de terminaison propre à Zhipu, avec une mise en cache des prompts qui ramène le coût des entrées mises en cache à environ 0,26 $ par million et permet de réduire substantiellement le coût effectif lors de la réutilisation de contextes identiques. Des passerelles tierces telles qu’OpenRouter annoncent des tarifs comparables (Simon Willison l’a testé là-bas aux mêmes taux de 1,40 $ / 4,40 $) ; comparez donc les offres des revendeurs si le coût est le critère décisif.
L’atout qui rend GLM 5.2 intéressant pour les workflows existants est son point de terminaison compatible avec Anthropic. Les outils déjà compatibles avec l’API Messages d’Anthropic peuvent être redirigés vers Zhipu simplement en définissant une variable d’environnement, sans modification de code :
| Paramètre | Valeur |
|---|---|
ANTHROPIC_BASE_URL | https://api.z.ai/api/anthropic |
| Modèle (Claude Code, 1M) | glm-5.2[1m] |
| Point de terminaison de codage (Cline, etc.) | https://api.z.ai/api/coding/paas/v4 |
| Délai d’attente pour les appels longs | Augmenter API_TIMEOUT_MS (par ex. 3 000 000) pour les exécutions en mode Plan |
Ce simple remplacement explique pourquoi GLM 5.2 a bénéficié dès le jour un d’un support natif pour Claude Code, Cline, OpenCode, Roo Code, Goose, Crush, OpenClaw et Kilo Code. Si vous travaillez principalement depuis un terminal avec un agent natif, notre guide pratique sur OpenCode et sa gestion des backends de modèles détaille davantage cette configuration.
La réalité matérielle de l’exécution locale d’un modèle d’environ 753 milliards de paramètres
La licence MIT constitue la fonctionnalité phare, et elle est authentique : désormais que les poids sont publics sur Hugging Face, vous pouvez télécharger, affiner et héberger vous-même GLM 5.2 sans restriction d’usage ni de zone géographique. L’astuce est que « open » ne signifie pas « fonctionne sur votre ordinateur portable ». Un modèle de ~753 milliards de paramètres relève d’une charge de calcul pour centre de données.
En précision FP8 (environ un octet par paramètre), les poids seuls nécessitent environ 750 Go de VRAM, ce qui implique concrètement environ 8× H200 (141 Go chacun) ou 8× B200. En passant à INT4, l’empreinte tombe à environ 370 Go, ce qui tient sur environ 4× H200 — ou peut être réparti sur davantage de cartes moins gourmandes en mémoire, comme 8× H100, moyennant une légère perte de qualité. Et ces chiffres ne tiennent pas encore compte du contexte : un cache KV de 1 million de jetons ajoute environ 80 Go supplémentaires, voire plus ; ainsi, la configuration à 1 million de jetons requiert réellement des nœuds de la classe H200/B200. Selon les guides de déploiement publiés, un serveur unique équipé de 8× H200 coûterait environ 10 000 $/mois en tarification spot, atteignant 25 000 $ ou plus sur les clouds GPU à la demande.
Pour la grande majorité des équipes, ce calcul signifie : utilisez l’API. L’hébergement local de GLM 5.2 ne se justifie que si la résidence des données, l’isolement physique (air-gapping) ou un volume très élevé et soutenu justifient la charge opérationnelle — notons également que l’API hébergée pratique, quant à elle, repose sur une infrastructure chinoise, ce qui constitue une considération spécifique pour certains acheteurs. Si votre objectif réel est un modèle exécutable sur du matériel que vous possédez réellement, un MoE de ~753 milliards de paramètres n’est pas l’outil adapté, et notre guide sur les meilleurs modèles de langage locaux pour la programmation modèles adaptés à une station de travail unique ou à un serveur GPU modeste
Points forts
- Un contexte de 1 million de jetons est véritablement très large et particulièrement adapté aux travaux agentic sur l’ensemble d’un dépôt.
- Licence MIT permissive avec poids entièrement ouverts, sans étiquette « recherche uniquement » ou « usage non commercial ».
- Meilleur modèle open weights selon l’Intelligence Index d’Artificial Analysis, et #2 sur le classement frontend de Code Arena.
- Point de terminaison compatible avec Anthropic intégré « sans modification » : migration quasi nulle depuis les clients Claude, et tarifs du Coding Plan inférieurs à ceux des API frontières fermées pour les utilisateurs intensifs.
Mises en garde
- Les scores fournis par le fournisseur sur les benchmarks agentic de codage (SWE-bench Pro, Terminal-Bench) sont issus de tests internes et restent inférieurs à ceux de Claude Opus 4.8 ; veuillez les valider auprès d’évaluateurs neutres ou via vos propres tâches.
- Utilise nettement plus de jetons de sortie par tâche que ses concurrents, ce qui érode son avantage coût sur les travaux longs.
- L’auto-hébergement exige du matériel de centre de données multi-GPU, et non des cartes graphiques grand public ou professionnelles ; l’API hébergée fonctionne sur une infrastructure chinoise.
- Seuls les niveaux d’effort Élevé et Maximum sont proposés ; aucune option économique et rapide pour les tâches triviales. Les tarifs et les quotas sont encore en cours de stabilisation.
GLM 5.2 comparé à GLM 5.1 et aux autres modèles à poids ouverts
Par rapport à son propre prédécesseur, GLM 5.2 est approximativement de la même taille : Zhipu le décrit comme appartenant à la même classe de paramètres que GLM 5.1 (~753 milliards contre ~754 milliards), avec la même architecture MoE (mixture of experts) et environ 40 milliards de paramètres actifs. Le progrès réside presque entièrement dans l’élargissement de la fenêtre contextuelle et du plafond de sortie, ainsi que dans une amélioration mesurable des scores aux benchmarks.
| Modèle | Paramètres totaux | Contexte | Sortie maximale | Licence | SWE-bench Pro (éditeur) |
|---|---|---|---|---|---|
| GLM 5.2 | ~753 milliards de paramètres MoE | 1,000,000 | 131,072 | MIT | 62.1 |
| GLM 5.1 | ~754 milliards de paramètres MoE | ~200,000 | ~131 000 | MIT | 58.4 |
In the broader open-weights coding race, GLM 5.2 now enters as the front-runner on several independent boards rather than an unproven newcomer. Moonshot’s Kimi K2 generation and the latest DeepSeek and Qwen coders all publish SWE-bench and agentic-coding results, and Qwen’s flagship also offers a 1M-token context — but on the Artificial Analysis Intelligence Index, GLM 5.2 (51) sits ahead of DeepSeek V4 Pro (44) and Kimi K2.6 (43). That said, leaderboard position is not the same as fit for your codebase, and on first-party agentic suites GLM 5.2 still trails the closed frontier (Claude Opus 4.8). For a sense of how the other Chinese labs trade blows, see our breakdown of DeepSeek V4 contre Qwen 3, et pour le modèle le plus fréquemment comparé à GLM 5.2, notre étude détaillée de Kimi K2.7 pour la programmation. Nous avons également confronté les deux modèles directement dans GLM 5.2 contre Kimi K2.7 pour la programmation.
FAQ
GLM 5.2 est-il réellement open source ?
Les poids sont publiés sous licence MIT, l’une des licences les plus permissives disponibles, autorisant l’usage commercial, la modification et la redistribution. Les poids ont été rendus publics sur Hugging Face (sous les références zai-org/GLM-5.2 et une version en FP8) le 16 juin 2026. Notez toutefois que « poids ouverts sous licence MIT » ne signifie pas un projet open source complet avec données d’entraînement publiques : vous obtenez le modèle, pas sa recette.
Quel est le coût d’utilisation de GLM 5.2 ?
Via l’API, comptez environ 1,40 $ par million de jetons d’entrée et 4,40 $ par million de jetons de sortie sur le point de terminaison de Zhipu, le cache permettant de réduire le coût des jetons d’entrée mis en cache à environ 0,26 $ par million. L’abonnement « GLM Coding Plan » s’avère souvent moins coûteux pour une utilisation régulière, avec des offres promotionnelles démarrant autour de 10 $/mois pour la version Lite et allant jusqu’à environ 80 $/mois pour la version Max (les tarifs affichés sont supérieurs). Des fournisseurs tiers comme OpenRouter proposent des tarifs comparables au jeton.
Puis-je exécuter GLM 5.2 sur ma propre carte graphique ?
Uniquement si « ma propre carte graphique » désigne un serveur multi-GPU. Les poids (~753 milliards) nécessitent environ 8× H200 en FP8, ou environ 4× H200 (ou davantage de cartes à mémoire plus faible) avec une quantification INT4, et la fenêtre contextuelle de 1 million de jetons ajoute une exigence importante en mémoire KV-cache. Une seule carte graphique grand public ne peut pas exécuter ce modèle ; pour cela, il vous faut un modèle local plus petit, conçu spécifiquement pour cet usage.
GLM 5.2 fonctionne-t-il avec Claude Code ?
Oui. Zhipu fournit un point de terminaison compatible Anthropic, vous pouvez donc configurer Claude Code pour qu’il cible https://api.z.ai/api/anthropiczai-org/GLM-5.2 glm-5.2[1m], définir le modèle sur « zai-org/GLM-5.2 », et fournir une clé API Z.ai. Il est recommandé d’augmenter le délai d’attente des requêtes pour les exécutions planifiées longues. La même approche fonctionne également avec Cline, OpenCode, OpenClaw, Goose, Roo Code, Crush et Kilo Code.
Comment la fenêtre contextuelle de GLM 5.2 se compare-t-elle à celle de GLM 5.1 ?
Elle est cinq fois plus grande : 1 000 000 de jetons contre environ 200 000 pour GLM 5.1. Le nombre maximal de jetons de sortie reste également élevé, à 131 072 jetons, ce qui rend GLM 5.2 mieux adapté à l’hébergement intégral d’une base de code complète ainsi que d’un long transcript d’agent au sein d’une seule session.
Zhipu a-t-il publié des benchmarks pour GLM 5.2 ?
Pas lors du lancement du « Coding Plan » le 13 juin — cette sortie mettait l’accent sur la disponibilité et la feuille de route des poids ouverts. Toutefois, Zhipu a publié un tableau complet de benchmarks le 16 juin, date de mise à disposition des poids, et des laboratoires indépendants ont suivi : Artificial Analysis le classe premier modèle open-weight sur son Intelligence Index (51), et Code Arena le place deuxième sur le classement du développement frontend. Les scores agentic fournis par l’éditeur (SWE-bench Pro 62,1, Terminal-Bench 2,1 sur 81,0) doivent néanmoins être vérifiés avec des évaluations neutres.
GLM 5.2 est-il meilleur que Kimi K2 ou DeepSeek pour la programmation ?
Sur l’intelligence globale évaluée de façon indépendante, il les devance actuellement : Artificial Analysis attribue à GLM 5.2 un score de 51, contre des scores dans la basse quarantaine pour DeepSeek V4 Pro et Kimi K2.6, et il les dépasse tous deux sur le classement frontend de Code Arena. Toutefois, l’écart peut se réduire ou s’inverser sur une tâche agentic spécifique de programmation, et les trois modèles publient des résultats détaillés sur SWE-bench. Ainsi, pour une décision critique, effectuez un test tête-à-tête sur votre propre dépôt plutôt que de vous fier à un seul classement.
Conclusion
GLM 5.2 constitue une sortie réelle et remarquable : un modèle de programmation de ~753 milliards de paramètres, sous licence MIT, doté d’une fenêtre contextuelle de 1 million de jetons et d’une API compatible Anthropic prête à l’emploi, permettant de le remplacer en quelques secondes dans Claude Code ou Cline. Pour les utilisateurs intensifs de programmation agentic souhaitant une longue fenêtre contextuelle et une licence permissive, sa proposition de valeur est solide, et ses tarifs via le « Coding Plan » sont très compétitifs.
L’écart de performance observé durant les 72 premières heures s’est refermé : les évaluateurs indépendants classent désormais GLM 5.2 comme le meilleur modèle open-weight sur l’intelligence globale et parmi les meilleurs sur le développement frontend — une reconnaissance authentique. Deux réserves méritent toutefois d’être gardées à l’esprit. Les revendications les plus spectaculaires du type « bat GPT-5.5 » reposent sur des benchmarks agentic fournis par l’éditeur, où GLM 5.2 reste toutefois derrière Claude Opus 4.8, et le modèle consomme beaucoup de jetons de sortie, donc vérifiez bien la rentabilité sur votre propre charge de travail. La réalité matérielle va dans le même sens : pour presque tous les utilisateurs, il s’agit d’une API cloud à tester, et non de poids à auto-héberger. Un essai sérieux s’impose clairement ; quant à savoir s’il justifie une migration complète, cela dépendra de ses performances sur votre propre code, et non des classements.

