Tester GLM 5.2 dans Claude Code à l’aide d’un SDK réel pour cinq dollars.

Un projet Claude Code dont les coûts continuent d’augmenter est une bonne raison de chercher un moteur moins cher. Le candidat habituel est GLM 5.2, un modèle open-source issu d’un laboratoire chinois que les articles de benchmark ne cessent de louer. Au lieu de lire davantage de ces articles, un développeur a investi cinq dollars dans OpenRouter et a appliqué ce modèle à un véritable codebase, un SDK d’interface utilisateur générative conçu pour React Native, en vérifiant chaque ligne qu’il produisait. L’audit a coûté 59 cents et la compilation quatre dollars. Les détails en valent la peine, y compris une erreur presque fatale concernant les types de code qui devraient être envoyés à un modèle hébergé.

Pourquoi le tester du tout

Deux motivations ont guidé cette expérience. La première était le coût. Un modèle dont le prix représente un dixième du tarif habituel, capable de gérer même la moitié de la charge de travail, permettrait de réaliser des économies substantielles, surtout pour quelqu’un qui utilise simultanément de nombreux agents, parfois même un grand nombre d’entre eux. La seconde motivation était la curiosité envers les laboratoires chinois, qui expédient rapidement leurs modèles et affichent des résultats de benchmarks impressionnants, mais dont les modèles n’avaient jamais été testés sur le propre code du développeur.

La règle du test était simple : utiliser la base de code que le développeur connaît mieux que quiconque, et vérifier chaque affirmation figurant dans les résultats.

La configuration est plus simple que prévu

GLM 5.2 provient de Z.ai. Il est apparu à la mi-juin, dispose d’une fenêtre de contexte de un million de tokens, et est souvent décrit comme un modèle de pointe pour la programmation à un prix bien inférieur. Les chiffres publics confirment cette réputation. Design Arena d’OpenRouter le classe parmi les 1 % les meilleurs pour la génération de code, sur la base de 3 243 tournois en duel. Il s’agit cependant du benchmark d’autrui, et les benchmarks sont eux-mêmes basés sur du code créé par d’autres personnes.

Claude Code ne se soucie pas de ce qui se trouve derrière lui. Il utilise le format API d’Anthropic et lit deux variables d’environnement pour déterminer où envoyer les demandes. En orientant ces paramètres vers un autre point de terminaison, l’outil continue de fonctionner, avec le même agent, la même capacité d’édition de fichiers et les mêmes tests, mais avec un « cerveau » différent en arrière-plan.

OpenRouter a servi d’endpoint. Un seul compte et une seule clé API peuvent être utilisés pour accéder à des dizaines de fournisseurs, y compris Z.ai, ce qui éliminait la nécessité d’établir une relation de facturation distincte avec un laboratoire étranger simplement pour mener une expérience. Un petit montant de crédit suffit pour accéder à n’importe quel modèle grâce à cette seule clé. Le processus comporte trois étapes.

Créer la clé. Créez une clé API sur OpenRouter et ajoutez un peu de crédit. GLM 5.2 ne dispose pas de version gratuite, mais le crédit offert est très généreux : toute l’expérience a pu être réalisée avec cinq dollars, avec encore de la marge. Le champ de limite de crédit de la clé agit comme filet de sécurité, avec ici une limite stricte de cinq dollars. Après l’expérience, le tableau de bord indiquait que 4,59 dollars de cette limite avaient été utilisés, couvrant tout ce qui a été décrit ci-dessous.

Utilisez Point Claude Code pour cela. Quelques paramètres suffisent : l’URL de base pointe vers l’API OpenRouter, le jeton d’authentification correspond à la clé OpenRouter, et les noms par défaut des modèles Opus et Sonnet sont tous deux définis sur l’identifiant GLM 5.2.

ANTHROPIC_BASE_URL = https://openrouter.ai/api
ANTHROPIC_AUTH_TOKEN = your_openrouter_key
ANTHROPIC_DEFAULT_OPUS_MODEL = z-ai/glm-5.2
ANTHROPIC_DEFAULT_SONNET_MODEL = z-ai/glm-5.2
ANTHROPIC_DEFAULT_HAIKU_MODEL = z-ai/glm-4.5-air

Avec cela en place, lancer Claude Code signifie communiquer avec GLM. Pour revenir à Claude, il suffit de supprimer ces lignes. C’est tout le mécanisme de basculement.

Fixer le fournisseur. La plupart des gens sautent cette étape, or elle est importante. Sur OpenRouter, un même nom de modèle peut être proposé par de nombreuses entreprises, et les prix varient considérablement, allant de moins d’un dollar par million de tokens à plus de trois. Cette différence n’est pas fortuite. Certains hébergeurs utilisent des versions quantisées du modèle, qui sont plus petites, plus rapides, mais aussi nettement moins performantes ; c’est pourquoi l’onglet « Fournisseurs » inclut même un filtre de quantification. Si le routage automatique est activé, une demande pourrait être acheminée vers l’un de ces hébergeurs, et le testeur finirait par évaluer une version compressée et dégradée en pensant qu’il s’agit de la version originale.

Afin d’obtenir une comparaison équitable, le routage a été configuré pour aller directement vers Z.ai, l’hébergeur officiel, avec les mécanismes de secours désactivés. Chaque requête atteignait ainsi le véritable modèle à haute précision et rien d’autre. Si l’équité est l’objectif, c’est ce paramètre qui détermine le résultat.

La quasi-erreur : tout le code n’est pas partageable

Le SDK est open source, mais le même répertoire contient également des éléments qui ne le sont pas : un kit d’intégration dynamique, des fonctionnalités de facturation, de la logique liée aux utilisateurs, ainsi que les éléments destinés à générer des revenus. Envoyer l’ensemble du monorepo vers un modèle hébergé dans un autre pays constitue ce type de fuite accidentelle qui n’est détectée qu’après coup.

Au préalable, avant que quoi que ce soit ne fonctionne, une copie propre a été créée. Seules les parties visibles y ont été intégrées, à savoir le paquet SDK et une application d’exemple avec son backend d’agent, tandis que le code commercial est resté sur le disque du développeur. Ensuite est venue la vérification fastidieuse mais essentielle : la copie a été fouillée à la recherche de mots qui pourraient trahir le fonctionnement du jeu, tels que « onboarding », « billing », « tenant » et « stripe », et aucun résultat n’a été trouvé avant même que le premier token ne quitte la machine.

Cette habitude constitue la véritable leçon : un modèle bon marché ne change pas les règles. Le code public peut être hébergé dans une API, tandis que le code privé reste local ou n’est pas du tout utilisé. Ce même raisonnement a conduit le développeur à choisir un modèle plus coûteux mais conforme aux normes de l’UE pour le backend client, et il reste tout aussi valable lorsque l’expérience n’a pour but que le divertissement.

Tâche un : lire le SDK et indiquer où il présente des failles

La première tâche était un véritable test de lecture. GLM a été chargé d’auditer l’architecture comme si une nouvelle génération d’outils devait y être développée : identifier les points critiques, nommer les fichiers, déterminer ce qui casserait en premier. Une règle était primordiale : chaque affirmation devait citer un fichier et une ligne réels, et les incertitudes devaient être admises plutôt que dissimulées par des inventions.

Le modèle a lu quarante-et-un fichiers et a fourni un rapport d’audit révélant trois problèmes réels que le développeur connaissait déjà :

• Les types de composants sont fixés dans le paquet au démarrage de l’application, de sorte qu’un agent ne peut pas définir de nouveau composant en temps de exécution, ce qui est précisément ce dont a besoin la prochaine fonctionnalité.
• Le streaming ne produit aucun effet sur le chemin principal de l’agent, car l’adaptateur responsable n’a jamais eu de méthode de streaming écrite.

Un bug de dérive avait été ignoré : le SDK peut afficher treize composants, mais le serveur n’en autorise que onze et ne communique au modèle que l’existence de sept d’entre eux, ce qui rend deux composants parfaitement fonctionnels inaccessibles via l’agent.

Rien de tout cela n’a été pris à la légère. Chaque citation a été vérifiée à l’aide de grep contre le code, et elles se sont avérées exactes. Les chemins des fichiers et les numéros de ligne étaient corrects, et le modèle n’avait inventé aucune fonction. Il a même détecté quelque chose que personne n’avait signalé : un commentaire backend affirmant fièrement l’utilisation des derniers modèles Claude, situé juste au-dessus de code qui fait en réalité appel à un modèle OpenAI moins cher. Un commentaire obsolète s’était transformé en une petite mensonge. C’est une découverte remarquable de la part d’un modèle que le développeur était prêt à rejeter.

L’audit a coûté 59 cents et a duré six minutes.

Tâche deux : modifier le code

La lecture permet à tout modèle de paraître intelligent, donc la étape suivante a été de lui permettre d’accéder au code. Il a reçu la correction la plus difficile issue de son propre audit : mettre fin définitivement à l’écartement des composants. Le SDK deviendrait la source unique de vérité, un manifeste serait généré à partir de lui, et le serveur lirait ce manifeste au lieu d’une liste tapée manuellement, afin que les deux ne puissent plus jamais diverger. Un test devait échouer si cela se produisait un jour.

Le modèle a terminé chaque partie du processus. Un manifest a été généré par le SDK, le serveur a été mis à jour pour le consommer, les deux composants en panne sont devenus des éléments intégrés fonctionnels et sont ainsi enfin accessibles, et un test de surveillance des écarts a été ajouté. L’exécution personnelle du développeur du jeu de tests a montré quatre-vingt-douze tests réussis : les quatre-vingt-sept originaux inchangés plus cinq nouveaux. Ensuite, une tentative délibérée de le faire échouer a été effectuée : suppression manuelle d’un composant du manifest puis réexécution du test de surveillance. Cela a échoué de manière évidente, au bon endroit. Le filet de sécurité était efficace.

Pendant ce temps, le modèle est également tombé dans un piège agaçant lié à la chaîne d’outils, un problème de syntaxe de React Native qui empêche l’exécuteur de tests de charger certains fichiers. Il n’a ni caché le problème ni abandonné. Il a créé une petite solution de contournement et a enregistré ce problème comme une mise en garde dans son rapport, une honnêteté plus précieuse qu’un résultat parfaitement présentable.

Le piège

La compilation a coûté quatre dollars contre 59 cents pour la lecture, et c’est cette différence que les vidéos promotionnelles omettent de mentionner. Pour la lecture, GLM était clairement supérieur : environ dix fois moins cher que la configuration habituelle et trois fois plus rapide. La compilation a réussi, mais la majeure partie des quatre dollars a été consacrée à effectuer sans cesse les tests, dans un cycle de lancement, lecture de l’erreur, modification et relancement, répété sur environ trois cents itérations. Seulement une trentaine de ces étapes correspondaient à de véritables modifications de code. Le reste relevait de la persévérance.

En conclusion, l’affirmation est plus restreinte que « le GLM remplace l’installation existante ». Pour la lecture, l’examen, l’audit et l’explication d’une base de code, dans des tâches où le modèle réfléchit une fois et fournit une réponse, le GLM 5.2 représente vraiment une bonne affaire et mérite d’être choisi délibérément. Pour des développements prolongés sans surveillance, où les coûts augmentent à cause des boucles de débogage, il reste efficace, mais les économies diminuent et la nécessité d’un modèle de pointe réapparaît.

Un après-midi, cinq dollars et du code familier ont permis d’obtenir une réponse définitive là où des opinions hâtives n’y parviendraient jamais, ce qui en a fait la recherche la moins coûteuse du mois.

Utilisation courante

Deux approches sont possibles, en fonction du code.

Pour tout ce qui est public, la configuration d’OpenRouter se trouve dans un bloc commenté au sein des paramètres de Claude Code. Pour obtenir un avis externe peu coûteux sur un dépôt open source, une analyse d’architecture ou pour poser la question « qu’y a-t-il de mal ici ? », supprimez les signes de commentaire, changez le fournisseur en Z.ai et laissez GLM effectuer la lecture intensive pour un prix modique. Claude reste la solution par défaut lorsqu’il s’agit de développer.

Pour tout ce qui est privé, le modèle est intégré au code et non l’inverse. Cela signifie soit des poids locaux, soit rien du tout.