Modèle à 18 $ (GLM) en tant que Worker dans Claude Code & Codex — Levier de réduction des coûts sans changer de configuration

Modèle à 18 $ (GLM) en tant que Worker dans Claude Code & Codex — Levier de réduction des coûts sans changer de configuration

Il est 14 heures, la fonctionnalité est à moitié terminée et votre limite du forfait à 200 dollars est atteinte. Les trois réactions évidentes sont toutes mauvaises : passer à la tarification de l'API (plus chère que l'abonnement), acheter un deuxième abonnement (encore une limite) ou passer l'après-midi à migrer le projet vers un outil inconnu. Il y en a une quatrième : changer le fournisseur du modèle et conserver tout le reste.

Nous gérons notre travail d'agents à travers des modèles hébergés et ouverts, et la question opérationnelle est rarement « quel modèle est le plus intelligent ». Elle est plutôt : quelle partie du travail a une définition de terminé suffisamment claire pour qu'un modèle plus abordable puisse l'accomplir, sans que le travail de retouche n'annule l'avantage tarifaire.

Les quatre éléments qui sont constamment confondus ici

Nate B. Jones sépare dans son analyse quatre niveaux qui sont presque toujours traités comme un seul dans le débat sur les « modèles moins chers » (Vidéo, 22 août 2026). Cette séparation est toute l'astuce :

1. Le modèle. La partie qui raisonne et produit des tokens. Interchangeable.
2. Le Harness (l'environnement). Claude Code, Codex — le programme qui lit les fichiers, exécute les commandes, demande des autorisations et affiche les résultats. Reste en place.
3. Le contexte du projet dans les fichiers. CLAUDE.md, AGENTS.md, Skills (compétences), Hooks, commandes de test, règles du projet. Portable — chaque session les lit à nouveau, indépendamment du fournisseur.
4. La conversation. L'historique volatil d'une session. Non portable.

Ceux qui considèrent le changement de modèle comme une opération d'une seule ligne confondent généralement 1 et 4. C'est exactement de là que vient l'effet selon lequel un modèle moins cher devient plus cher : les décisions de la dernière heure sont dans l'historique et nulle part ailleurs, la nouvelle session ne les connaît pas et doit les traiter à nouveau.

D'où la première règle : Ce que vous écrivez dans les fichiers survit au changement de fournisseur. Ce qui n'est que dans le chat, non. L'hygiène du contexte n'est pas ici une manie de l'organisation, mais une question de coût.

Claude Code : une deuxième ligne de démarrage, pas un deuxième outil

Z.ai fournit un point de terminaison (endpoint) compatible avec Anthropic. Claude Code n'a donc besoin que de trois variables d'environnement (selon la base), documentées dans le Z.ai Developer Guide :

L'approche pratique n'est pas de réécrire la configuration existante, mais de créer une deuxième commande de démarrage :

# ~/.zshrc — l'installation normale reste intacte
claude-glm() {
  ANTHROPIC_BASE_URL="https://api.z.ai/api/anthropic" \
  ANTHROPIC_AUTH_TOKEN="$ZAI_API_KEY" \
  ANTHROPIC_DEFAULT_SONNET_MODEL="glm-5.3" \
  ANTHROPIC_DEFAULT_OPUS_MODEL="glm-5.3" \
  ANTHROPIC_DEFAULT_HAIKU_MODEL="glm-5.3-flash" \
  API_TIMEOUT_MS=3000000 \
  claude "$@"
}

claude continue d'ouvrir une session Anthropic, claude-glm ouvre une session Z.ai. Les deux voient le même dépôt, le même CLAUDE.md, les mêmes hooks et serveurs MCP. Si la connexion GLM se comporte mal, fermez la fenêtre — rien n'a été modifié dans l'installation normale.

La clé doit se trouver dans votre environnement shell ou un gestionnaire de secrets, pas dans le projet. Pour ceux qui préfèrent la méthode automatique : npx @z_ai/coding-helper écrit la configuration lui-même.

Ce qui ne suit pas : l'historique de la conversation précédente, le cache des prompts et toute décision que vous n'avez jamais notée en dehors du chat.

Codex : un profil au lieu d'une deuxième session

Codex résout le même problème un niveau plus bas — via des profils dans ~/.codex/config.toml (Documentation Z.ai) :

[model_providers.ZAI]
name = "ZAI"
base_url = "https://api.z.ai/api/v1"
experimental_bearer_token = "<Votre clé API>"
wire_api = "responses"

[profiles.glm]
model_provider = "ZAI"
model = "glm-5.3"
model_reasoning_effort = "max"

Ensuite, codex --profile glm lance une exécution GLM, tandis que codex continue de fonctionner sur votre configuration OpenAI. Ici aussi : le même projet, le même AGENTS.md, les mêmes règles — mais une nouvelle conversation.

Voici la différence dans la méthode de travail : Claude Code ressemble à un cockpit où vous restez au plus près du travail et pilotez ; Codex ressemble plus à un pupitre de dispatcher où vous envoyez des tâches et vérifiez les résultats. Les deux styles sont préservés lorsqu'une autre entreprise fournit l'intelligence — ils sont liés au Harness, pas au modèle.

La fiche de transmission : six lignes au lieu de 40 tours d'historique

Lorsqu'une tâche est transmise au modèle moins cher en plein milieu de son exécution, la tentation est grande de copier l'historique de la conversation. C'est la méthode la plus coûteuse : le nouveau modèle doit d'abord déterminer quelle partie était pertinente. Il vaut mieux utiliser une fiche de transmission avec six champs, que le modèle cédant rédige lui-même :

Objectif:    Passer ces 38 appels API au nouveau nom de champ.
État:        La branche est propre ; appels concernés dans src/api/ et src/jobs/.
Fichiers:    src/api/*.ts, src/jobs/sync.ts, tests/api.spec.ts
Contraintes: Ne pas modifier l'API publique. Aucune nouvelle dépendance.
Terminé si:  L'ancien nom de champ n'apparaît plus nulle part, tous les tests sont au vert.
Vérif.:      pnpm test && pnpm lint && pnpm build

Ces six lignes sont en même temps un outil de diagnostic. Si une tâche ne peut pas être mise sous cette forme, elle n'est pas adaptée au modèle moins cher. Non pas parce que GLM serait trop faible, mais parce que la tâche n'est pas encore définie.

Lead et Worker : deux sessions, un Git-Worktree

L'idée la plus évidente dans Claude Code : assigner le sous-agent à un autre modèle. Cela ne tient pas. Un sous-agent normal démarre délibérément avec un contexte frais, et un sous-agent forké qui hérite de l'historique complet doit utiliser le même modèle que le processus parent. Il n'y a pas de fournisseur distinct par agent enfant de manière native.

Le modèle viable est plus brut et plus robuste :

• Lead (Chef de file) : la session Anthropic habituelle. Décide de ce qu'est la tâche et vérifie à la fin.
• Worker (Travailleur) : une session claude-glm qui reçoit la fiche de transmission.
• Séparation : Le Worker travaille dans son propre git worktree, afin que les deux sessions ne modifient pas les fichiers l'une sous l'autre sans le savoir.

git worktree add ../projet-worker -b feature/nom-champ-api
cd ../projet-worker && claude-glm

Le Worker renvoie : les fichiers modifiés, les vérifications exécutées et tout ce qu'il n'a pas pu résoudre. Le Lead vérifie si la modification a du poids. Cela reste un seul projet et un outil familier — seulement avec une transmission explicite entre les deux. La façon dont cela s'intègre dans un flux multi-agents plus large a été décrite dans le Guide du Builder pour Claude Code 2.0.

Quel travail confier au modèle abordable — et lequel ne pas confier

La ligne de démarcation ne se situe pas entre « difficile » et « facile », mais entre vérifiable et flou :

Un exemple pour la colonne de droite : une panne d'authentification sporadique. Un Worker abordable peut y collecter des logs et tracer des chemins de code — l'investigation proprement dite reste avec le modèle le plus puissant, en qui vous avez confiance.

Et le conseil de séquencement qui permet d'économiser le plus d'argent : Commencez une tâche majeure avec le modèle qui doit la terminer. Construire quarante tours d'historique puis changer de fournisseur dans la dernière ligne droite est le cas où le modèle bon marché devient assurément plus cher.

Ce que cela coûte réellement

L'honnêteté est de mise ici, sinon un outil devient une promesse en l'air :

• Le forfait à 18 dollars n'est pas le forfait à 200 dollars. D'autres limites, un autre budget de tokens, d'autres capacités de résolution de problèmes. Z.ai travaille avec des fenêtres de cinq heures et des fenêtres hebdomadaires.
• Prenez en compte le coût total. Le prix honnête, ce sont les tokens, plus les exécutions répétées, plus votre temps de révision. Une exécution que vous lancez deux fois et que vous retouchez ensuite vous-même n'était pas bon marché.
• Testez sur votre propre code. La complexité de votre dépôt est déterminante, pas un benchmark. Donnez délibérément au Worker des tâches exigeantes et reprenez la main là où il échoue — c'est ainsi que vous trouverez la limite réelle.
• Ne basculez pas d'un modèle à l'autre au milieu de la conversation. L'historique visible n'est pas l'état complet ; les caches de prompts et le comportement du modèle changent avec lui.

Le même principe s'applique d'ailleurs sans changer de fournisseur : même un modèle plus petit de la même entreprise est un Worker. Nous avons classé ce que GLM 5.3 apporte en termes de performances propres dans GLM-5.3 : Codage Frontier avec des capacités cyber émergentes ; la logique de migration entre deux générations de Harness se trouve dans la Checklist de migration Codex et Opus 4.7.

Construire cette répartition pour une stack concrète — quelles tâches vont au Worker, à quoi ressemble la fiche de transmission et comment mesurer les retours — fait partie de ce sur quoi travaille notre équipe.

Foire aux questions (FAQ)

Dois-je changer d'outil pour utiliser GLM 5.3 ? Non. Claude Code et Codex acceptent tous deux Z.ai comme fournisseur de modèle — Claude Code via ANTHROPIC_BASE_URL, Codex via un profil dans config.toml. Les fichiers, hooks, autorisations et serveurs MCP restent inchangés (Source).

La nouvelle session emporte-t-elle mon historique de conversation précédent ? Non. Seul ce qui se trouve dans les fichiers est portable — CLAUDE.md, AGENTS.md, Skills, commandes de test. L'historique et le cache des prompts restent en arrière. D'où l'importance de la fiche de transmission avec l'objectif, l'état, les fichiers, les contraintes, la définition de "terminé" et les vérifications.

Puis-je assigner un sous-agent à GLM dans Claude Code ? Pas nativement. Un sous-agent forké doit utiliser le même modèle que le processus parent, et il n'y a pas de fournisseur distinct par agent enfant. La solution pratique consiste en deux sessions — Lead et Worker — avec le Worker dans son propre git worktree (Source).

Quelles tâches conviennent au modèle moins cher ? Celles avec un objectif clair, un cercle de fichiers limité, des exemples dans le dépôt et des tests qui décident si c'est terminé. La recherche de causes avec un état caché et les décisions sur le "quoi" relèvent du modèle puissant.

Est-ce que j'économise vraiment de l'argent avec ça ? Seulement si vous prenez en compte le coût total : tokens plus répétitions plus temps de révision. Le forfait à 18 dollars a des limites plus petites et ne remplace pas un abonnement à 200 dollars, mais constitue une deuxième voie pour un travail limité et vérifiable.

Sources

1. Z.AI Developer Docs — Claude Code
2. Z.AI Developer Docs — Codex
3. Nate B. Jones — Stop Paying $200 For Work An $18 Model Can Do Inside Claude Code And Codex (YouTube, 22 août 2026)
4. Anthropic — Sous-agents Claude Code
5. Git — worktree