GLM 5.3 Pricing: An $18 Coding Plan Inside Claude Code and Codex
GLM 5.3's coding plan starts at $18/month and plugs into Claude Code and Codex as a second provider. Here's how the setup and tradeoffs work.
Why GLM 5.3’s pricing matters if you already pay for Claude or Codex
Z.ai’s GLM coding plan starts at $18 a month and can run as a second model provider inside Claude Code and Codex, the same harnesses you already use for Anthropic or OpenAI models. That’s a fraction of the $200-a-month top tiers for Claude Code (Max plan) or Codex (Pro plan). The point isn’t to replace your existing subscription. It’s to route some of your coding work, the parts with a clear definition of done, to a cheaper model without rebuilding your setup from scratch.
TL;DR
- GLM 5.3’s coding plan costs $18 a month at its entry tier, well under the $200 top-tier plans for Claude Code and Codex, but it comes with smaller usage limits, so it’s a supplement, not a swap.
- Both tools support it natively: Claude Code accepts a Z.ai-compatible endpoint and API key, and Codex has a documented Z.ai provider config, so you don’t need a different coding tool to try GLM 5.3.
- Switching providers mid-session is expensive: Anthropic’s own docs warn that changing models mid-conversation forces a full reread of history without prior prompt caching, which can spike cost and latency right when you’re trying to save money.
- Four things move independently when you switch models: the model itself, the harness (Claude Code or Codex), your saved project context (files like CLAUDE.md or AGENTS.md), and the live conversation, and only the first three transfer cleanly to a new provider.
- A written handoff file beats pasting conversation history: goal, current state, relevant files, constraints, definition of done, and validation commands are enough to get a second model productive without re-litigating the whole investigation.
- Sub-agent forking has a hard limit: Claude Code’s forked sub-agents inherit the parent’s full context and prompt cache, but must use the same model as the parent, so you can’t natively fork a cheaper model mid-task.
- The practical pattern is two parallel sessions, not one session juggling models: run your primary model as lead, run GLM 5.3 as a separate worker session with an explicit handoff, and use a Git work tree if both are editing at once.
How much does GLM 5.3 actually cost compared to Claude Code and Codex?
Z.ai prices its coding plan starting at $18 a month. That sits well below the $200-a-month ceiling that Claude Code’s Max plan and Codex’s Pro plan charge for their highest usage tiers. The catch is usage volume: the $18 tier comes with meaningfully smaller limits than what you get on a $200 subscription. This isn’t a like-for-like replacement. It’s a way to add cheap throughput for a specific slice of your workload, so when you hit your Claude or Codex limit at 2pm on a real project, you have somewhere else to send the next task instead of eating API overage pricing or stalling until your quota resets.
The other cost trap is the “fully loaded” price of a model switch. If you tally only the sticker price per token, GLM 5.3 looks cheap. But retries, review time, and context reconstruction all add real cost. A cheaper model that requires more back-and-forth, or that has to redo investigation work an expensive model already finished, can end up costing more in wall-clock time and token overhead than just staying put.
How do you set up GLM 5.3 inside Claude Code?
Claude Code lets you switch models within the same provider using a /model command, and it preserves the conversation when you do. But Anthropic’s documentation notes that the next response after a switch rereads the full conversation history without the benefit of existing prompt caches, which slows things down and raises cost, especially in a long session.
Moving from Anthropic to Z.ai is a bigger jump than an in-provider model switch, because you’re changing the API endpoint and key that Claude Code uses entirely. The practical approach is to leave your normal Claude Code setup untouched and create a second launch command, something like claude-glm, that supplies the Z.ai API key, the Z.ai endpoint for Anthropic-compatible requests, and the mapping to GLM 5.3. Store the key in your environment or a secrets manager, not in the project itself. Running claude-glm opens a separate session that still reads your existing CLAUDE.md, hooks, MCP servers, and permissions, because that context lives in files. What it won’t carry over is any prior Anthropic conversation, decisions made mid-session, or a warm prompt cache.
What doesn’t transfer when you switch models, and why does it matter?
There are four separate things at play whenever you change which model is doing the work: the model (the reasoning engine), the harness (Claude Code or Codex, which handles file access, tool calls, and permissions), your project context (files like CLAUDE.md, AGENTS.md, task docs, and scripts), and the conversation (the live back-and-forth in a given session).
Seven tools to build an app. Or just Remy.
Editor, preview, AI agents, deploy — all in one tab. Nothing to install.
Switching models doesn’t move all four equally. The harness stays the same. Project context transfers cleanly because it lives in files that any session can read. The conversation does not transfer. If your current session spent an hour ruling out causes of an intermittent bug and agreed not to touch a particular piece of middleware, none of that survives into a fresh GLM 5.3 session unless it was written down somewhere outside the chat.
This is why context hygiene has real economic weight. Teams pushing large token volumes through Claude and Codex threads, with high percentages of reused input tokens, are implicitly relying on cached context and long conversation history to keep costs down. If your key project decisions live only in one long thread, they’re stuck there. If they live in files, a different model can pick up the work with no loss.
Can you run GLM 5.3 as a sub-agent inside Claude Code?
Not cleanly, at least not for a fresh model on a forked task. Claude Code has two sub-agent patterns. A normal sub-agent starts with fresh, bounded context: it gets the delegated task and relevant project instructions, not the full parent conversation. That’s useful for narrow, self-contained work. A forked sub-agent is different: it inherits the full parent conversation and reuses the parent’s prompt cache, but it’s required to use the same model as the parent process.
That constraint rules out a native “fork this one task to a cheaper model” setup. There’s no documented way to keep the main Claude Code session on Anthropic while routing a single forked child to Z.ai. The workaround is to skip forking and run two separate sessions instead: your normal Claude Code session as the lead, and a claude-glm session as an independent worker with its own explicit handoff document. If both sessions might touch the same files, put the worker in a Git work tree, a separate checkout of the repository, so the two don’t collide.
How does the Codex setup for GLM 5.3 differ from Claude Code?
Codex offers a more structured version of the same idea. You add Z.ai as a model provider in your Codex configuration, pointing it at the Z.ai address built for Codex’s response format, and specifying the environment variable holding your API key. From there you create a GLM profile that tells Codex to use GLM 5.3 through that provider. Launching a job with that profile (something like codex --profile glm) runs it on Z.ai while your default Codex setup keeps using OpenAI, so both configurations coexist without conflict.
As with Claude Code, the GLM profile reloads your project’s AGENTS.md files, skills, tools, and rules, since those live in the repository. It does not inherit a running conversation. Codex treats it as a new session, so the same handoff discipline applies: write down the goal, current state, affected files, constraints, and definition of done before moving a job over.
Is it worth routing work to a cheaper model like GLM 5.3?
Other agents ship a demo. Remy ships an app.
Real backend. Real database. Real auth. Real plumbing. Remy has it all.
It depends on the type of task. Work with a clear, checkable definition of done, mechanical refactors, renaming API fields across dozens of call sites, updating repetitive boilerplate, tends to translate well to a handoff document and a cheaper model. Work that requires deep, undocumented investigation, like chasing an intermittent bug through multiple false leads, is expensive to hand off because so much of the value is locked inside a conversation that doesn’t transfer.
The rule of thumb: start a substantial job on the model you expect to finish it with. Don’t build up dozens of turns of history on one provider and then try to hand it to another provider in the final stretch. Reserve model switches for clean task boundaries, not last-minute rescues.
Frequently Asked Questions
How much does the GLM 5.3 coding plan cost?
Z.ai’s coding plan starts at $18 a month, according to the plan structure referenced in coverage of the tool. That’s the entry tier; it comes with smaller usage limits than premium plans from Anthropic or OpenAI, so it functions as a supplement rather than a full replacement.
Does GLM 5.3 work inside Claude Code and Codex without switching tools?
Yes. Both Claude Code and Codex support configuring Z.ai as an alternate model provider. In Claude Code this means supplying a Z.ai API key and endpoint through a separate launch command. In Codex it means adding Z.ai as a provider and creating a profile that routes requests to GLM 5.3.
Will my existing project setup carry over to a GLM 5.3 session?
Anything saved in files, like CLAUDE.md, AGENTS.md, hooks, scripts, and project rules, carries over because any session in the same repository can read those files. The live conversation history and any decisions made only within it do not carry over.
Can I fork a Claude Code sub-agent to run on GLM 5.3 while the parent uses Claude?
No. Claude Code’s forked sub-agents inherit the parent’s full conversation and prompt cache, but they must use the same model as the parent. To mix models, run two separate sessions instead, with an explicit handoff between them.
What’s the best way to hand off a task from one model to another?
Write a short document covering the goal, current state, relevant files, constraints, what “done” means, and which commands to run for validation. This gives the new model, and a new session, everything it needs without requiring it to parse an entire prior conversation.
