Run GLM 5.3 Inside Claude Code and Codex: A Setup Guide
How to configure GLM 5.3 as an alternate model provider inside Claude Code and Codex to cut costs without switching your coding tool.
Why route GLM 5.3 through Claude Code or Codex instead of switching tools?
GLM 5.3, the coding model from Z.ai, can run as a model provider inside both Claude Code and Codex without you giving up either harness. Instead of paying top-tier subscription prices for every task, or hitting a usage limit mid-project and reaching for the API (which bills far more than a monthly plan), you point your existing tool at Z.ai’s endpoint for a specific job and keep your files, hooks, permissions, and habits exactly as they were. The model changes. The tool around it doesn’t.
TL;DR
- GLM 5.3 works as a drop-in provider inside both Claude Code and Codex, letting you offload certain coding tasks to a cheaper model without abandoning the harness you already know.
- Four things change independently when you swap models: the model itself, the harness (Claude Code or Codex), the project context saved in files, and the live conversation history, and only some of those actually transfer.
- Conversation history does not follow you to a new provider, so mid-task switches lose whatever decisions weren’t written down somewhere outside the chat.
- The practical pattern is two separate sessions, one on your normal provider and one configured for GLM, connected by an explicit handoff document rather than a shared live conversation.
- Claude Code sub-agents can’t easily use a different provider than the parent session, so running GLM as a “worker” means opening a second session, not spawning a sub-agent.
- Codex supports this more natively through profiles, letting you add Z.ai as a provider and launch a GLM-specific profile alongside your normal OpenAI setup.
- Cheaper doesn’t automatically mean cheaper overall, since retries, review time, and lost context from a bad handoff can erase the savings from a lower per-token price.
One coffee. One working app.
You bring the idea. Remy manages the project.
What actually changes when you switch the underlying model?
It helps to separate four layers that people tend to lump together.
The model is the part doing the reasoning and generating tokens. It could be a Claude model, an OpenAI model, or GLM 5.3.
The harness is the program you interact with, Claude Code or Codex. It handles file access, running commands, tool permissions, and displaying results. Swapping the model underneath doesn’t change how the harness itself operates.
Project context lives in files: your CLAUDE.md or AGENTS.md, task lists, documentation, skills, scripts, hooks, and project rules. This is portable. Any session, on any model, can read it because it’s just sitting in the repository.
Conversation is the live, temporary history of a specific session: what you asked, what the model read, what you both decided, and any corrections along the way. This is the layer that does not automatically transfer when you point the harness at a different provider.
The mistake is assuming that changing the model swaps out only that top layer. In practice, unless you’ve been disciplined about writing decisions into files, a lot of institutional knowledge about a task lives only in that fourth layer, the conversation, and it evaporates the moment you open a fresh session on a new provider.
How do you set up GLM 5.3 inside Claude Code?
Claude Code’s /model command lets you switch models within the same provider (Anthropic) while keeping the conversation intact, but Anthropic’s own documentation notes that switching rereads the entire conversation history without the benefit of existing prompt caches. That makes a late switch slower and pricier than expected, even to a nominally cheaper model.
Moving from Anthropic to Z.ai is a bigger change than that, because you’re also changing the endpoint Claude Code sends requests to. The practical approach is to leave your normal Claude Code setup untouched and create a second, separate launch command, something like claude-glm, that supplies three things before the session opens: the Z.ai API key, the Z.ai address for Anthropic-compatible requests, and the mapping that tells Claude Code which model name corresponds to GLM 5.3. Keep the API key in your environment or a secrets manager, never in the project files.
Once that command runs, Claude Code opens the same repository, reads the same CLAUDE.md file, and keeps your existing hooks, MCP servers, and permission settings. The model answering underneath is now GLM 5.3. What doesn’t come back is any prior Anthropic conversation, prompt cache, or undocumented decision from an earlier session. If your Anthropic session spent an hour ruling out causes of a bug and never wrote that down, a fresh GLM session starts from zero on that investigation.
What’s the best way to hand off work between Claude and GLM?
Before moving a job to a new model mid-stream, write a handoff file. Have the outgoing model document the goal, the current state, relevant files, constraints, what “done” looks like, and which checks to run before returning. For example: the goal is updating a set of API calls to a renamed field, the current branch is clean, the affected calls live in two named folders, the public API must not change, and the job is done when the old field name no longer appears and existing tests pass.
That’s a far more reliable starting point for a new model than pasting a full conversation transcript and hoping it extracts what matters.
For anything beyond a single-session task, the recommended pattern is two Claude Code sessions running side by side: your normal Anthropic session as the lead, and a claude-glm session as the worker. Give the worker session a handoff file. If both sessions might touch the same files simultaneously, put the worker in a separate Git worktree so the two don’t collide. The worker returns changed files and passing checks; the lead session reviews the result when the work matters enough to warrant it.
Can Claude Code sub-agents run on GLM instead of Claude?
Not cleanly, at least not as a beginner-friendly setup. Claude Code’s normal sub-agents start with fresh, bounded context: they get the delegated task and applicable project instructions, not the full parent conversation. That’s intentional, and it’s part of why sub-agents are good at narrow, contained work.
Claude Code also supports “forked” sub-agents, which do inherit the full parent conversation and its prompt cache, but a fork must use the same model as its parent. There’s no simple native setting to keep the main session on Anthropic while routing one forked child through Z.ai. Rather than fighting the harness with a custom gateway, the more workable option is running two full sessions (lead and worker) as described above.
How do you set up GLM 5.3 inside Codex?
Codex handles this more directly through profiles. You add Z.ai as a model provider in your personal Codex configuration, giving it the Z.ai address and the environment variable that holds your API key. Z.ai provides a Responses-compatible endpoint built specifically for Codex. From there, you create a GLM profile specifying that requests should use GLM 5.3 and route through the Z.ai provider.
To run a job on GLM, you launch Codex with that profile. Your normal Codex setup, using OpenAI models, stays untouched and available in parallel. As with Claude Code, the GLM profile opens the same project and loads the same AGENTS.md files, skills, and project rules already in place. The project context reloads, but the conversation does not automatically carry over, so the same handoff discipline applies.
Is switching to a cheaper model actually worth it?
It depends on the fully loaded cost, not just the sticker price. A $18-a-month coding plan has smaller usage limits than a $200-a-month plan, and it’s not a wholesale replacement for your primary subscription. The value is in choosing which specific jobs go to the cheaper model: work with a clear definition of done, well-documented constraints, and low ambiguity, like renaming a batch of API calls across a known set of files or reproducing a well-scoped intermittent bug.
Everyone else built a construction worker.
We built the contractor.
One file at a time.
UI, API, database, deploy.
If a task requires deep, unwritten context accumulated over many conversation turns, moving it to a new model late in the process can cost more in retries and review time than it saves in token price. The rule of thumb: start a substantial job on the model you expect to finish it with, and only hand off across providers at clear boundaries backed by a written handoff, not mid-stream on a hope that the new model will infer what the old one learned.
Frequently Asked Questions
Does GLM 5.3 replace my Claude or Codex subscription?
No. It’s a lower-cost provider you can route specific tasks to alongside your existing subscription, useful for offloading well-defined work or continuing when you hit a usage limit, not a full substitute given its smaller usage caps.
Will my project files and instructions work with GLM 5.3?
Yes. CLAUDE.md, AGENTS.md, hooks, MCP server configs, and project rules live in files and load normally regardless of which model provider answers the request.
What happens to my conversation history when I switch models?
It doesn’t transfer. A new session on a different provider starts fresh except for what’s saved in project files, which is why writing a handoff document before switching matters.
Can I run a GLM sub-agent inside a Claude Code session automatically?
Not natively. Forked sub-agents must use the same model as the parent session, so running GLM as a worker means opening a separate Claude Code session, not spawning a sub-agent from the main one.
How do I decide which tasks to send to GLM 5.3?
Favor tasks with a clear definition of done, explicit constraints, and low reliance on undocumented context from earlier conversation turns, such as mechanical refactors or well-scoped bug investigations.
