GLM 5.2 contre Opus
(techstackups.com)- Avec le même prompt en one-shot pour créer un jeu de plateforme 3D WebGL brut, Opus a produit un résultat plus rapide et plus abouti, tandis que GLM-5.2 se distingue par son coût inférieur et ses poids open weight
- GLM-5.2 est un modèle open weight sous licence MIT de Z.ai, avec un contexte de 1M de tokens et des niveaux de raisonnement High/Max, mais son caractère text-only limite l’auto-vérification fondée sur les images
- En test réel, GLM-5.2 a coûté 5,39 $, contre environ 21,92 $ pour Opus, avec des temps de build respectifs de 1 h 10 min 40 s et 33 min 30 s, illustrant un arbitrage entre vitesse et coût
- Le résultat de GLM-5.2 présentait des problèmes de base comme des textures manquantes, des pics non fonctionnels, l’absence de condition de victoire et un overlay de debug resté à l’écran ; Opus était plus propre, mais gardait une collision approximative sur de fines plateformes aériennes et un déclencheur de victoire trop lointain
- Dans les benchmarks comme dans les évaluations externes, GLM-5.2 apparaît comme un solide modèle open weight, mais Opus reste devant sur de nombreuses tâches de code et d’agent ; le choix dépend donc du coût, de l’ouverture et du jugement visuel
Des écarts révélés sur une même tâche
- GLM-5.2 est un exemple récent du potentiel des modèles ouverts, mais sur une même tâche réelle, Claude Opus 4.8 a livré un résultat plus rapide et plus précis
- Le test consistait à donner aux deux modèles le même prompt en one-shot et à leur demander de créer de zéro un jeu de plateforme 3D pour navigateur en WebGL brut, sans moteur de jeu ni bibliothèque de rendu 3D comme Three.js
- Les deux résultats et le code source sont publics
- Les deux jeux utilisent le kit d’assets gratuit CC0 Kenney Platformer Kit
Nature et approche de GLM-5.2
- GLM-5.2 est le dernier modèle flagship de Z.ai, proposé en open weight sous licence MIT
- Il peut être téléchargé et exécuté localement, ou appelé via l’API de Z.ai
- Les poids sont disponibles sur Hugging Face et ModelScope, sans restriction régionale
- Il peut être servi localement avec des frameworks comme vLLM, SGLang et Transformers
- Le modèle vise les tâches long-horizon, comme les travaux d’agent de code multi-étapes sur une longue durée
- Il offre une fenêtre de contexte de 1M de tokens
- Il propose des niveaux de raisonnement High et Max ; le test a été mené avec High
- Sa limite décisive est son caractère text-only
- GLM-5.2 ne peut pas lire les images
- Les workflows qui nécessitent l’examen direct de captures d’écran ou de diagrammes demandent un modèle multimodal comme Claude Opus
Prix et coût d’exécution
- D’après la documentation des fournisseurs, le prix par 1M de tokens est inférieur pour GLM-5.2 par rapport à Opus
- Claude Opus 4.8 : entrée 5 $, lecture de cache 0,50 $, sortie 25 $
- GLM-5.2 : entrée 1,4 $, lecture de cache 0,26 $, sortie 4,4 $
- En sortie token, GLM-5.2 coûte moins d’un cinquième du prix d’Opus
- Dans le test réel de création du jeu, le compromis temps/coût allait toutefois dans l’autre sens
| Indicateur | GLM-5.2 (Pi/OpenRouter) | Opus (Claude Code) |
|---|---|---|
| Temps de build mesuré | 1 h 10 min 40 s | 33 min 30 s |
| Tokens de sortie | 131,000 | 216,809 |
| Utilisation maximale du contexte | 16 % de 1M | 19 % de 1M |
| Appels d’outils | 128 | 153 |
| Coût | 5,39 $ facturés | env. 21,92 $ estimés |
- Opus a terminé en environ la moitié du temps, tandis que GLM-5.2 a accompli la tâche à un coût bien inférieur
Tâche de test : jeu de plateforme 3D WebGL brut
- La tâche était plus structurée et complexe que la simple génération d’une landing page
- Parseur de modèles GLB
- Mathématiques de matrices et de vecteurs
- Shaders GLSL
- Animation squelettique skinnée
- Boucle à pas de temps fixe
- Gestion des collisions
- Caméra suiveuse
- Les deux modèles ont reçu le même prompt, les mêmes assets et une seule tentative sans indice
- Les conditions de réussite étaient les suivantes
- Moteur 3D et renderer basés sur WebGL brut
- Loader pour le personnage 3D et le modèle du monde fournis
- Déplacement et saut du personnage avec gravité et collisions
- Caméra suiveuse et contrôles clavier
- Jeu complet exécutable dans le navigateur via une seule commande
- Les deux modèles ont largement implémenté eux-mêmes un parseur binaire GLB, les mathématiques de matrices et quaternions, un renderer WebGL2, des shaders GLSL de skinning et des collisions AABB avec substeps
- Les journaux de build sont eux aussi publics
Résultat en jeu et bugs restants
- Les deux jeux prennent la forme d’un jeu de plateforme 3D à la troisième personne
- Déplacement avec WASD ou les flèches
- Saut avec Space
- Course avec Shift
- Rotation de la caméra par glisser-déposer à la souris
- Zoom avec la molette
- Objectif : ramasser des pièces, éviter les pics et atteindre le drapeau
- En cas de chute hors de la carte, retour au point de départ
-
Résultat de GLM-5.2
- Le jeu de GLM-5.2 donne une impression générale de finition brute
- Certains matériaux du personnage manquaient, et le personnage marchait en tournant le dos à sa direction de déplacement
- Les pièges à pics ne tuaient pas le personnage et ne le réinitialisaient pas, et atteindre le drapeau ne déclenchait pas la condition de victoire
- La tête disparaissait quand la caméra bougeait, et un overlay de debug restait affiché
- En revanche, la section où le personnage rebondit vers la plateforme suivante en marchant sur un ressort fonctionnait bien
- Les modèles Kenney référencent une palette de couleurs partagée dans un fichier séparé, mais le renderer de GLM-5.2 ne chargeait pas ce fichier, ce qui les remplaçait par des couleurs unies
-
Résultat d’Opus
- Le jeu d’Opus est plus propre et fonctionne mieux
- La caméra et le contrôleur fonctionnaient, et la logique de mort sur les pics aussi
- Les textures étaient correctement appliquées, les animations fluides, et atteindre le drapeau permettait de gagner
- Les bugs restants relevaient davantage d’edge cases que des fonctions de base
- Le personnage pouvait brièvement rester debout dans le vide à côté d’une plateforme, car la fenêtre de coyote time autorisant le saut juste après avoir quitté un bord était réglée trop généreusement
- La condition de victoire se déclenchait même alors qu’on était encore assez loin du drapeau
Une différence multimodale décisive dans l’auto-vérification
- Les deux modèles avaient reçu pour consigne de vérifier leur résultat avant de terminer
- Opus, en tant que modèle multimodal, a rendu le jeu puis inspecté directement les captures d’écran
- Il a repéré l’affichage de debug encore présent à l’écran, l’a supprimé, puis a finalisé le projet
- Il a vérifié dans la scène finale les blocs, escaliers, pièces, gemmes, pics, drapeau, personnage, HUD du score, éclairage et géométrie
- GLM-5.2 ne pouvant pas lire les images, il n’a pas pu voir directement les captures d’écran
- Il a à la place utilisé une méthode de contournement consistant à lire les données brutes des pixels et à vérifier si les couleurs correspondaient grossièrement aux attentes
- Il a contrôlé dans l’image enregistrée des conditions comme grass green, dirt brown, coin gold, flag red, character bluish, half-Lambert lit, no black
- Cette méthode a manqué des problèmes visibles à l’écran
- Le personnage apparaissait gris et les textures étaient absentes
- L’overlay de debug était toujours présent à l’écran
- Pour les tâches où le rendu visuel compte, une validation multimodale capable de comprendre les images se traduit par une vraie différence de qualité
Positionnement dans les benchmarks
- Dans les benchmarks de la model card de Z.ai, GLM-5.2 se classe souvent juste derrière les meilleurs modèles fermés, et passe même devant sur certains benchmarks de raisonnement
- Chiffres principaux
- HLE : GLM-5.2 40.5, Opus 4.8 49.8
- HLE with tools : GLM-5.2 54.7, Opus 4.8 57.9
- AIME 2026 : GLM-5.2 99.2, Opus 4.8 95.7
- IMOAnswerBench : GLM-5.2 91.0, Opus 4.8 83.5
- SWE-bench Pro : GLM-5.2 62.1, Opus 4.8 69.2
- NL2Repo : GLM-5.2 48.9, Opus 4.8 69.7
- ProgramBench : GLM-5.2 63.7, Opus 4.8 71.9
- SWE-Marathon : GLM-5.2 13.0, Opus 4.8 26.0
- MCP-Atlas public : GLM-5.2 76.8, Opus 4.8 77.8
- Tool-Decathlon : GLM-5.2 48.2, Opus 4.8 59.9
- Les résultats d’exécution indépendants d’ArtificialAnalysis évaluent aussi GLM-5.2 comme un solide modèle open weight
- Score de 51 sur l’Intelligence Index v4.1
- Au-dessus de MiniMax-M3 44, DeepSeek V4 Pro 44 et Kimi K2.6 43
- TerminalBench v2.1 est à 78 %, avec un harness différent des 81 ou 82.7 de la model card
- Les tokens de sortie par tâche tournent autour de 43k, contre 26k pour GLM-5.1
- La tendance des benchmarks rejoint le test pratique
- GLM-5.2 fait partie des leaders parmi les modèles open weight et reste compétitif sur certains volets de raisonnement
- Opus est devant sur de nombreux benchmarks de code et d’agent
Réactions externes
- Simon Willison a qualifié GLM-5.2 de « probablement le LLM open weight text-only le plus puissant »
- Dans son test SVG, GLM-5.2 a généré un pélican à vélo sous forme entièrement animée, sans partie cassée
- Le test de l’opossum sur un scooter était moins bon que sur le précédent GLM-5.1, signe d’une performance pas totalement homogène
- Artificial Analysis classe GLM-5.2 comme le meilleur modèle open weight dans son propre Intelligence Index
- Il le considère comme le modèle le moins cher à ce niveau, situé à la frontière coût/intelligence
- Il le signale toutefois comme un modèle gourmand en tokens, avec environ 43k tokens de sortie par tâche
- Nathan Lambert estime, sur la base du leaderboard LMArena, que GLM-5.2 pourrait même être vu comme un meilleur agent que Gemini, et parle d’un « serious accomplishment » pour un modèle ouvert sous licence MIT
- Il souligne que les meilleurs modèles américains gardent globalement l’avantage, mais que des laboratoires chinois atteignent des scores élevés avec moins de calcul
Quel modèle choisir
- GLM-5.2 est un modèle open weight performant pour une fraction du prix d’Opus
- Il convient quand le coût et l’ouverture sont importants, et que la tâche porte surtout sur le texte et la logique
- Des poids téléchargeables ne peuvent pas être retirés ou restreints soudainement comme un modèle fermé
- Opus a donné dans ce test un résultat plus rapide, plus propre et plus précis
- Il peut voir et vérifier directement les rendus visuels
- Il convient mieux aux tâches où l’exactitude, la policy, le jugement visuel priment, et où le coût est acceptable
- GLM-5.2 ressemble moins à un modèle principal destiné à remplacer Opus qu’à un puissant modèle d’appoint, moins cher et toujours accessible
1 commentaires
Avis de Hacker News
Je ne comprends vraiment pas pourquoi le one-shot prompting provoque un tel tapage.
Par définition, un seul prompt ne peut pas contenir toute la complexité d’un projet logiciel. Au final, le modèle ne fait que produire un résultat en multipliant les hypothèses à partir du code existant dans son corpus d’entraînement.
Je préférerais voir un agent de codage qui suit précisément les étapes d’un fichier de plan, tout en respectant les garde-fous d’une spécification validée par un humain et les conventions de code. Il faudrait aussi vérifier que la boucle agentique, face à un objectif fixé par un humain, ne sort pas des garde-fous et reste stable jusqu’à l’achèvement de l’objectif.
Par ailleurs, la capacité à comprendre le contexte du cas d’usage visé, à repérer dans le code existant des bugs ou des possibilités d’amélioration des performances, et à proposer du refactoring, me semble un indicateur bien plus précieux.
Ce n’est pas tant un benchmark de conformité sortie/entrée qu’un test de cohérence interne du résultat. Pour un jeu, cela revient par exemple à vérifier s’il se termine quand on atteint l’objectif, si l’on meurt en touchant des piques, ou si des cas limites bizarres apparaissent dans les déplacements.
Cela dit, j’estime qu’il aurait aussi fallu répéter l’expérience plusieurs fois dans le même environnement d’exécution afin d’observer la dispersion des résultats.
Avant, je me moquais des ingénieurs qui testaient un framework sur un projet vide en suivant le README, puis affirmaient que « ce framework est idéal pour notre application de production vieille de 10 ans ». La pensée greenfield est la solution à tous les problèmes et le problème de toutes les solutions.
Les capacités en one-shot sont aussi un indicateur utile à mesurer, mais il faudrait le faire sur de grandes codebases déjà établies.
Si Claude Code et Opus ont autant retenu l’attention, c’est parce que l’environnement d’exécution s’est amélioré au point de leur permettre de corriger eux-mêmes beaucoup d’erreurs sans intervention de l’utilisateur. À long terme, j’ai l’impression que les plus grands progrès viendront de l’autonomie sur plusieurs heures et de la capacité d’auto-correction.
Générer des millions de tokens à partir de quelques tokens d’entrée ne me semble pas transmettre grand-chose d’utile.
Pour évaluer un meilleur modèle, il suffit d’ajouter davantage d’exigences à la tâche. Même si ce n’est pas un cas d’usage réaliste, je trouve la méthode utile.
Bien sûr, lorsqu’un ingénieur logiciel le pilote, le modèle peut produire de bien meilleurs résultats. Selon l’ingénieur, cela peut aussi être pire.
Un run one-shot unique du type « même prompt one-shot, confrontation directe entre Claude Opus 4.8 : créer de zéro un jeu de plateforme 3D en WebGL brut » n’est ni un benchmark ni une représentation réaliste de l’usage.
La plupart des usages d’agents sont collaboratifs : il faut donc tester la fiabilité, par exemple savoir s’ils terminent une tâche sans inventer des résultats de tests, ainsi que leur pilotabilité, c’est-à-dire voir s’ils suivent mes instructions ou s’ils n’en font qu’à leur tête.
Ce test montre ce que les deux modèles peuvent faire lorsqu’on leur donne une tâche one-shot longue et techniquement difficile.
Un format qui évalue la collaboration, la délégation de tâches, l’achèvement, le test-driven development et la pilotabilité me paraît être un très bon test à essayer à l’avenir.
Quand j’y pense, la plupart des tâches agentiques que je fais sont des sous-agents exécutés avec leurs propres prompts dans une session principale. On peut aussi les voir comme des versions courtes de travail entièrement autonome.
L’article parlait aussi de tout cela, et ce n’était pas censé être en soi un benchmark formel. Des benchmarks formels, il y en a déjà largement assez.
Anthropic me renvoyait sans arrêt des 529 Overloaded, donc hier je me suis inscrit à GLM 5.2 pour l’essayer.
Ça me plaît bien, mais sur le mode xhigh de GLM 5.2, seulement deux prompts dans une seule session ont déjà consommé 22 % de mon quota du forfait Light sur une fenêtre de réinitialisation de 5 heures.
Le résultat était satisfaisant et la qualité correcte. Comme j’ai envie d’utiliser les deux, j’aimerais qu’il existe une offre d’abonnement unifiée permettant d’utiliser à la fois Anthropic et GLM.
Après avoir utilisé GLM 5.2 sur quelques projets, mon impression est qu’il met quand même pas mal de temps avant de commencer à écrire du code, et que ce n’est clairement pas un modèle rapide.
Il part souvent dans des directions inutiles pendant la phase d’exploration et de planification, puis se corrige ensuite, mais il n’est pas facile à piloter, car il hallucine parfois des éléments qu’il ne suivra même pas plus tard. Malgré cela, la qualité de sortie est très bonne.
Par exemple, j’ai optimisé le rendu dans une codebase Swift+Zig, mais je bloquais à 5 000 éléments de données. GLM 5.2 a passé 20 minutes à créer des benchmarks et à extraire des données ; agacé, j’ai coupé son accès aux outils autres que l’édition et je suis parti. En revenant environ 30 minutes plus tard, il avait déjà optimisé trois goulots d’étranglement à partir du benchmark qu’il avait créé et de quelques « conclusions », tout en précisant qu’il lui fallait plus de données puisqu’il ne pouvait pas vérifier ses soupçons.
L’implémentation fonctionnait bien, était idiomatique et non intrusive. Je pourrais même dire qu’elle était plus idiomatique que le résultat produit par GPT 5.5 sur le même dépôt. J’aimerais l’utiliser davantage, mais GPT termine généralement la même demande 5 fois plus vite.
GLM 5.2 m’a poussé à préparer une configuration avec plusieurs exécutions en parallèle dans des conteneurs isolés et des workspaces JJ.
Il s’agissait d’intercepter le clic gauche dans la barre de menus de macOS, puis de faire en sorte que Ctrl+clic ou clic droit ouvrent le menu comme le ferait normalement un clic gauche, mais seulement sous certaines conditions.
Au milieu de la session de résolution, j’ai basculé le modèle sur GLM-5.2 ; je ne l’ai même pas reprompté, je l’ai remplacé en plein raisonnement, et quelques minutes plus tard le problème était corrigé. Je l’utilisais via l’allocation par abonnement d’OpenCode Go, et ce genre de problème aurait pu consommer tout mon quota Opus sur la fenêtre actuelle de 5 heures, voire même le quota hebdomadaire.
Quand on voit que le modèle déraille ou qu’on remarque quelque chose qu’on ne lui avait pas dit, on peut l’arrêter et corriger. On peut aussi comprendre pourquoi il a fait certains choix, ce qui évite ensuite de rester avec des doutes.
Cela correspond aussi à mon expérience. Je l’utilise sur Pi : c’est intelligent et la sortie est bonne, mais le processus pour y arriver n’est pas efficace
Il est écrit que « GLM-5.2 ne peut pas lire les images, c’est là que le problème est apparu. Il n’est pas multimodal. J’ai donc utilisé une astuce en écrivant un script qui lit les données brutes de pixels et vérifie si les couleurs sortent à peu près comme prévu au lieu de regarder la capture d’écran », mais une meilleure méthode serait d’utiliser https://github.com/openbmb/MiniCPM-V
Et si on veut vraiment, on peut aussi lui faire appeler Opus pour les images, tout en économisant probablement sur les coûts
Je me suis inscrit à Ollama pour expérimenter avec des modèles open source
Ces trois derniers mois, j’en étais surtout au stade des essais et de l’expérimentation, mais GLM est le premier modèle que j’utilise tous les jours avec Claude pour de vraies tâches de code. Il est suffisamment bon pour que j’atteigne la limite d’utilisation quotidienne d’Ollama tous les jours
GLM facture aussi moins de tokens et fait moins d’appels d’outils, mais il lui faut plus du double de temps pour terminer
Si ce temps n’est pas dû au comportement du modèle lui-même, je me demande où il part
Est-ce que chaque appel d’outil est plus complexe et prend plus de temps, ou bien le modèle fait-il plus de calculs par token, ce qui réduit le nombre de tokens par seconde ?
En plus, certains modèles à poids ouverts comme GLM 5.2 ou DeepSeek v4 Pro génèrent les tokens beaucoup plus lentement, ce qui affecte la latence perçue. Cela dit, il serait difficile de qualifier GLM 5.2 de lent ; par exemple, c’est actuellement l’un des modèles les plus rapides dans Notion
Une autre possibilité est qu’Opus utilise quelque chose comme un mélange d’experts (Mixture of Experts), donc la partie du modèle chargée en mémoire à un instant donné pourrait être plus petite que pour GLM
GLM 5.2 a un gros problème qui limite fortement ses chances de réussite : la valeur de son abonnement coding
Si on ne regarde que le prix de l’API, GLM 5.2 bat ses concurrents. Mais utiliser une facturation API pour du travail de code, c’est surtout le fait des grandes entreprises, et chez elles les offres par abonnement fortement subventionnées disparaissent peu à peu
En même temps, ces entreprises ne laisseront pas leurs employés utiliser des API chinoises
Pour les particuliers et les petites équipes, l’abonnement coding de Z.ai est inférieur à ceux d’Anthropic et d’OpenAI. On aura peut-être une consommation comparable à Claude, mais Codex offre clairement bien plus d’usage pour le prix payé
On peut débattre du niveau auquel Z.ai a rattrapé GPT5.5 et Opus 4.8, mais dans un monde où tout coûte le même prix et où l’on peut choisir librement, je ne choisirais pas GLM
La vraie question est donc de savoir à quel point l’offre de Z.ai s’améliorera avec GLM 5.3 ou 6, et à quel point OpenAI et Anthropic vont restreindre leurs offres actuelles dans un avenir proche
Pour ces entreprises, bâtir leur infrastructure autour d’une IA qu’on ne pourra pas leur retirer du jour au lendemain a une valeur immédiate. Dans d’autres pays hors d’Europe, on est plus sensible aux prix et on n’a pas les mêmes craintes à l’idée de nouer des relations avec des entreprises chinoises
Et en même temps, si « ces entreprises ne laisseront pas leurs employés utiliser des API chinoises », alors je me demande à qui s’adresse Amazon Bedrock qui propose GLM
Les particuliers choisiront probablement plutôt un fournisseur américain moins cher comme DeepInfra. L’entrée en cache de GLM coûte 0,18 $ par million de tokens, contre 0,50 $ pour Opus. Fireworks AI est aussi une option
Les employés et les étudiants qui se seront habitués à coder en consommant pour des milliers de dollars de tokens avec des forfaits à 20 ou 100 dollars pousseront ensuite à la dépense côté entreprise
L’arrivée de modèles chinois compétitifs ne remplacera sans doute pas cette dépense en entreprise, mais des modèles ouverts hébergés aux États-Unis ou dans l’UE, eux, le pourraient
L’existence de GLM 5.2 impose un plafond au prix qu’OpenAI et Anthropic peuvent facturer pour l’accès API
Je suppose que la plupart des tâches se font déjà via des forfaits coding
Cela dit, c’est agaçant que ces forfaits soient trop contraignants au-delà des simples limites d’usage. Je comprends pourquoi, mais c’est pénible. En pratique, seuls Anthropic et peut-être Google sont vraiment stricts
Anthropic a fait peur avec une politique disant que si l’usage est jugé non conforme aux conditions d’utilisation, la facturation peut ensuite être recalculée au tarif API. C’est peut-être une inquiétude infondée, mais j’ai vraiment l’impression qu’ils pourraient le faire, donc j’évite
Mais leur infrastructure était manifestement surchargée, donc 100 % des requêtes de chat 5.2 finissaient en timeout. Je réessaierai plus tard, quand l’infrastructure aura rattrapé les performances du modèle, et c’est seulement à ce moment-là que je pourrai juger si l’abonnement en vaut la peine
Aujourd’hui, j’ai été surpris de voir que GLM-5.2 était largement meilleur que GPT-5.5 pour le sens esthétique et les tâches UI
Je vais garder pour l’instant ma configuration Claude/Codex via Conductor, mais ce modèle m’a fait configurer OpenCode et télécharger l’application desktop, si bien que j’y ai fait la majeure partie de mon travail aujourd’hui
Quand je lis des phrases comme « GLM-5.2 coûtait bien moins cher. Opus a terminé en deux fois moins de temps et a produit un jeu plus propre », je reconnais immédiatement le style d’écriture LLM
On dirait que tous les modèles convergent vers ce style d’écriture, et même quand leurs performances s’améliorent, cet aspect change peu
Le secteur de la rédaction technique subit actuellement un choc majeur. Les entreprises exigent davantage de travail en moins de temps, la qualité baisse fortement, et il y a de moins en moins de temps au quotidien pour peaufiner la qualité des phrases
Nous travaillons en première ligne de ce changement, donc nous en subissons le plus fortement les effets, mais en même temps, le fait de pouvoir expérimenter ces évolutions en premier est à la fois stimulant et profondément frustrant