$18 Model (GLM) as a Worker in Claude Code & Codex — Cost Leverage Without Changing Setups
It is 2 PM, the feature is half finished, and you have reached your limit on the $200 plan. The three obvious reactions are all bad: switch to API pricing (more expensive than the subscription), buy a second subscription (just another limit), or spend the afternoon migrating the project to an unfamiliar tool. There is a fourth: change the model provider and keep everything else.
We run our agent work across hosted and open models, and the operational question is rarely "which model is smarter." It is: which part of the work has such a clear definition of done that a cheaper model can handle it without rework eating up the price advantage.
The four things that are constantly mixed up here
Nate B. Jones separates four layers in his analysis that are almost always treated as one in the debate about "cheaper models" (Video, August 22, 2026). The separation is the whole trick:
- The model. The part that reasons and produces tokens. Interchangeable.
- The harness. Claude Code, Codex — the program that reads files, executes commands, asks for permissions, and displays results. Stays.
- The project context in files.
CLAUDE.md,AGENTS.md, skills, hooks, test commands, project rules. Portable — every session reads them anew, regardless of the provider. - The conversation. The ephemeral history of a session. Not portable.
Anyone who thinks switching models is a one-line process usually confuses 1 with 4. This is exactly what causes a cheaper model to become more expensive: the decisions of the last hour are in the chat history and nowhere else; the new session doesn't know them and processes them all over again.
Hence the first rule: What you write in files survives the provider switch. What is only in the chat does not. Context hygiene at this point is not about obsessive tidiness, but a matter of cost.
Claude Code: a second launch line, not a second tool
Z.ai provides an Anthropic-compatible endpoint. Claude Code therefore only needs three environment variables, documented in the Z.ai Developer Guide:
| Variable | Value |
|---|---|
ANTHROPIC_BASE_URL | https://api.z.ai/api/anthropic |
ANTHROPIC_AUTH_TOKEN | Your Z.ai API key |
ANTHROPIC_DEFAULT_SONNET_MODEL | glm-5.3 |
ANTHROPIC_DEFAULT_OPUS_MODEL | glm-5.3 |
ANTHROPIC_DEFAULT_HAIKU_MODEL | glm-5.3-flash |
The practical approach is not to rewrite the existing configuration, but to create a second launch command:
# ~/.zshrc — the normal installation remains untouched
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 continues to open an Anthropic session, claude-glm a Z.ai session. Both see the same repository, the same CLAUDE.md, the same hooks and MCP servers. If the GLM connection acts up, just close the window — nothing was changed in the normal installation.
The key belongs in your shell environment or a secret manager, not in the project. If you prefer the automated way: npx @z_ai/coding-helper writes the configuration itself.
What does not come along: the previous conversation history, the prompt cache, and any decision you never noted down outside of the chat.
Codex: a profile instead of a second session
Codex solves the same problem one layer deeper — via profiles in ~/.codex/config.toml (Z.ai Documentation):
[model_providers.ZAI]
name = "ZAI"
base_url = "https://api.z.ai/api/v1"
experimental_bearer_token = "<Your API key>"
wire_api = "responses"
[profiles.glm]
model_provider = "ZAI"
model = "glm-5.3"
model_reasoning_effort = "max"
Afterward, codex --profile glm starts a GLM run, while codex continues to run on your OpenAI configuration. The same applies here: same project, same AGENTS.md, same rules — but a new conversation.
This is the difference in workflow: Claude Code feels like a cockpit where you stay close to the work and steer; Codex feels more like a dispatcher's desk where you send out jobs and review the results. Both styles are preserved when another company provides the intelligence — they depend on the harness, not the model.
The handover note: six lines instead of 40 rounds of history
If a task goes to the cheaper model mid-run, the temptation is great to copy the conversation history. That is the most expensive way: The new model first has to figure out which part of it was even relevant. Better to use a handover note with six fields, written by the handing-off model itself:
Goal: Update these 38 API calls to the new field name.
Status: Branch is clean; affected calls in src/api/ and src/jobs/.
Files: src/api/*.ts, src/jobs/sync.ts, tests/api.spec.ts
Constraints: Do not change the public API. No new dependencies.
Done when: The old field name no longer appears anywhere, all tests run green.
Checks: pnpm test && pnpm lint && pnpm build
These six lines are simultaneously a diagnostic tool. If a task cannot be put into this format, it is not suitable for the cheaper model. Not because GLM is too weak, but because the task is not yet defined.
Lead and Worker: two sessions, one Git worktree
The most obvious thought in Claude Code: put the sub-agent on a different model. That doesn't hold up. A normal sub-agent intentionally starts with fresh context, and a forked sub-agent that inherits the full history must use the same model as the parent process. Natively, there is no custom provider per child agent.
The viable pattern is broader and more robust:
- Lead: the usual Anthropic session. Decides what the task is and reviews it at the end.
- Worker: a
claude-glmsession that receives the handover note. - Separation: The Worker operates in its own
git worktreeso that both sessions don't alter files out from under each other.
git worktree add ../project-worker -b feature/api-fieldname
cd ../project-worker && claude-glm
The Worker delivers back: changed files, executed checks, and anything it couldn't resolve. The Lead reviews if the change carries weight. It remains one project and a familiar tool — just with an explicit handover in between. We described how this fits into a larger multi-agent workflow in the Builder Guide for Claude Code 2.0.
Which work goes to the cheap model — and which doesn't
The dividing line doesn't run along "hard" and "easy," but along verifiable and unclear:
| To the Worker (GLM) | Keep with the strong model |
|---|---|
| Clear goal, clear end state | The question of what the task should even be |
| Examples of the same kind are in the repo | Hidden state, conflicting evidence |
| Tests decide whether it's done | Risk assessments with consequences |
| Limited scope of files | Root cause analysis across system boundaries |
| Renaming, migrations, recurring patterns | Architectural decisions |
An example of the right column: a sporadic authentication issue. A cheap worker can collect logs and trace code paths there — the actual investigation remains with the strongest model you trust.
And the sequencing tip that saves the most money: Start a larger task with the model that is meant to finish it. Building up forty rounds of history and then switching providers on the home stretch is the scenario where the cheap model definitely becomes more expensive.
What this really costs
Honesty belongs here, otherwise a tool becomes an empty promise:
- The $18 plan is not the $200 plan. Different limits, different token budget, different problem-solving capabilities. Z.ai operates with five-hour and weekly windows.
- Calculate fully loaded costs. The honest price is tokens plus retries plus your review time. A run that you start twice and then rework yourself was not cheap.
- Test on your own code. The complexity of your repo is what decides, not a benchmark. Deliberately give the worker demanding tasks and pull back where it fails — this is how you find the actual limit.
- Don't switch back and forth mid-conversation. Visible history is not the entire state; prompt caches and model behavior change along with it.
By the way, the same principle applies without changing providers: A smaller model from the same house is also a worker. We categorized what GLM 5.3 brings in terms of its own capabilities in GLM-5.3: Frontier Coding with Emergent Cyber Capabilities; the migration logic between two harness generations can be found in the Codex and Opus 4.7 Checklist.
Building this division for a specific stack — which tasks go to the worker, what the handover note looks like, and how you measure returns — is part of what our team works on.
Frequently Asked Questions
Do I have to switch my tool to use GLM 5.3?
No. Both Claude Code and Codex accept Z.ai as a model provider — Claude Code via ANTHROPIC_BASE_URL, Codex via a profile in config.toml. Files, hooks, permissions, and MCP servers remain unchanged (Source).
Does the new session carry over my previous conversation history?
No. Only what is written in files is portable — CLAUDE.md, AGENTS.md, skills, test commands. The history and the prompt cache are left behind. That's why you need the handover note with goal, status, files, constraints, definition of done, and checks.
Can I put a sub-agent in Claude Code on GLM?
Natively, no. A forked sub-agent must use the same model as the parent process, and there is no custom provider per child agent. The practical way is two sessions — Lead and Worker — with the Worker in its own git worktree (Source).
Which tasks are suitable for the cheaper model? Those with a clear goal, a limited scope of files, examples in the repo, and tests that decide when it's done. Root cause analysis with hidden states and decisions about the "what" belong to the strong model.
Do I actually save money doing this? Only if you calculate fully loaded costs: tokens plus retries plus review time. The $18 plan has smaller limits and is not a replacement for a $200 subscription, but rather a second track for bounded, verifiable work.