GLM 5.3

Présentation

glm-5.3 est un modèle de raisonnement textuel lancé par Zhipu, positionné sur l'ingénierie logicielle complexe et les tâches Agent de longue durée. Il reprend la base de la génération précédente ; toutes les améliorations proviennent du post-entraînement, le raisonnement est toujours activé et prend en charge trois niveaux d'intensité : low, high et max, avec une fenêtre de contexte d'environ 1 million de tokens. Il convient aux développeurs qui souhaitent que le modèle accomplisse de manière autonome des appels d'outils multi-étapes, la compréhension de code multi-fichiers et les opérations en terminal, ainsi qu'aux équipes attentives à l'efficacité des tokens de raisonnement et désireuses de réduire le coût de sortie à score égal sur une même tâche.

Points forts

• Capacités de codage et d'Agent nettement améliorées par rapport à la génération précédente — selon l'éditeur, sur son benchmark interne Z.ai Code Bench, le gain atteint environ 50 % par rapport à GLM-5.2, et le modèle obtient l'état de l'art open source sur des benchmarks publics tels que Terminal Bench 3.0.
• Moins de tokens de sortie pour un score plus élevé — environ 75K tokens/tâche en mode Max contre 96K pour la génération précédente ; performance et efficacité des tokens s'améliorent conjointement, rendant le coût des tâches longues plus maîtrisable.
• Trois niveaux d'intensité de raisonnement ajustables selon la tâche — low, high et max correspondent à différents investissements de raisonnement, avec max par défaut, ce qui facilite l'arbitrage entre latence et qualité.
• Fenêtre de contexte d'environ 1M de tokens — permet d'intégrer en une seule fois de grandes bases de code et de longues conversations, et d'effectuer une analyse globale multi-fichiers et multi-modules.

Description des capacités

Compréhension de contexte très long : la fenêtre de contexte est d'environ 1 048 576 tokens, ce qui permet d'inclure l'intégralité d'une grande base de code ou d'une longue conversation multi-tours dans une seule requête, réduisant ainsi la charge d'ingénierie liée au découpage et à la recomposition.

Intensité de raisonnement ajustable : le raisonnement est toujours activé et prend en charge trois niveaux d'intensité (low, high, max), avec max par défaut ; on peut choisir selon la complexité de la tâche pour équilibrer vitesse de réponse et profondeur de raisonnement.

Ingénierie logicielle et Agentic Coding : orienté vers les appels d'outils multi-étapes et la génération/refactorisation de code ; selon l'éditeur, le gain sur Z.ai Code Bench atteint environ 50 % par rapport à la génération précédente, ce qui convient pour confier au modèle la progression autonome de tâches d'ingénierie complexes.

Exécution en terminal et tâches de longue durée : atteint l'état de l'art open source sur des benchmarks tels que Terminal Bench 3.0 et Agents' Last Exam, adapté à l'automatisation des opérations en ligne de commande et aux flux Agent nécessitant des décisions successives sur plusieurs tours.

Raisonnement et sortie textuels : modalité d'entrée et de sortie textuelle, facturation au token, intégration directe dans les chaînes métier de dialogue, d'analyse et de génération.

Cas d'usage

• Analyse de grandes bases de code par les équipes logicielles — saisir du code source multi-fichiers et une description des besoins, produire des plans de refactorisation ou des suggestions de modification, pour les processus de développement quotidien et de revue de code.
• Construction de flux d'appels d'outils multi-étapes par les développeurs d'Agent — saisir l'objectif de la tâche et la définition des outils, produire des décisions d'appel successives sur plusieurs tours, pour l'orchestration de workflows automatisés et de tâches en arrière-plan.
• Automatisation de tâches en terminal par les équipes d'exploitation et d'outillage — saisir l'environnement de commandes et les instructions de tâche, produire des séquences d'opérations en ligne de commande exécutables, pour la génération de scripts et l'automatisation des opérations en terminal.
• Évaluation de la découverte de vulnérabilités par les équipes de sécurité — saisir le code cible et les conditions d'évaluation, produire des indices de vulnérabilité et des conclusions d'analyse, pour les évaluations de sécurité internes, après avoir évalué au préalable le risque de double usage.

Limites et conseils de sélection

Le processus de raisonnement ne peut pas être désactivé : même les requêtes peu complexes génèrent une latence et un coût de raisonnement supplémentaires ; pour la classification simple ou la réécriture de textes courts, un modèle plus léger peut suffire. Les améliorations proviennent du post-entraînement et non d'une refonte architecturale, la base reste identique à celle de la génération précédente. Les capacités liées à la découverte de vulnérabilités et aux chaînes d'exploitation progressent nettement ; le risque de double usage doit être évalué au préalable avant tout usage en sécurité. Les poids du modèle sont publiés ultérieurement ; dans un premier temps, l'accès se fait principalement via l'API. La facturation se fait au token ; le contexte long et le raisonnement en mode max amplifient sensiblement la consommation.