Running a Cheap Model Beside Your Expensive One (Claude Code + Codex)

Source: raw/Stop_Paying_200_For_Work_An_18_Model_Can_Do_Inside_Claude_Code_And_Codex..md — Nate B Jones, AI News & Strategy Daily, ~20 min (https://www.youtube.com/watch?v=4HvFqhtCb-A). The creator states he is working from Claude, Codex, and z.ai documentation.

The engine-swap mechanics are already documented here: point Claude Code at a different base URL and you get a cheaper model inside a harness you know. This source is about the layer above the environment variables — which work you move, what follows it, and what silently does not. The framing device is z.ai’s GLM coding plan, which starts at $18/monthagainst$200 for Claude Max or Codex Pro, and which officially supports both harnesses.

Key Takeaways

• Four things get conflated, and they move differently when you change models. The model (produces the tokens), the harness (Claude Code, Codex — reads files, runs commands, asks permission), the project context (CLAUDE.md, AGENTS.md, skills, hooks, rules, docs — lives in files, therefore portable to anything), and the conversation (this session’s history, corrections, and rejected hypotheses — not portable). Changing the model keeps the harness, reloads the context, and drops the conversation.
• Switching model mid-thread has a hidden cost even when the new model is cheaper. Anthropic’s own warning, as relayed: after /model, the next response rereads the whole conversation history without the old prompt caches. A late-in-the-job switch can be slower and materially more expensive than the sticker price suggests.
• First rule of thumb: start a substantial job on the model you expect to finish it. Do not build 40 turns of working history with one provider and then hand the last mile to another. Two models on one project is fine; the boundary between them has to be a clear unit of work, not a hope that the second model absorbs what the first learned.
• The economic argument for context hygiene, with a number. The creator’s own token tracking recorded days above 3–4 billion tokens across Codex and Claude threads, of which ~96% of volume was reused input — project instructions, tool definitions, file context, repeated history. Lessons that live only in a long conversation are expensive to move. Lessons that live in files move for free.
• Forked subagents cannot cross providers. A normal subagent starts with fresh context by design (bounded context is why they are good at narrow work). A forked subagent receives the full conversation and can reuse the parent’s prompt cache — but must use the same model as the parent. And Claude Code documents per-subagent model choice, not a per-subagent provider address. So there is no native “Anthropic stays in charge, this one child goes to z.ai.”
• The supported workaround is two sessions, not one clever config. Ordinary Claude Code as the lead, a GLM-specific launcher as the worker, an explicit handoff between them, and a git worktree for the worker if both will edit at once.
• Codex has the cleaner path. z.ai publishes a Responses-compatible endpoint specifically for Codex, so you register it as a model provider in your personal config and create a named profile. codex --profile glm runs the whole job on GLM while ordinary Codex keeps your OpenAI setup. Both can run simultaneously.
• The $18planisnota$200 plan. Smaller 5-hour and weekly limits, and not the same problem-solving ability. The opportunity is not replacing your subscription — it is “stop paying the most expensive model to do every job merely because it came bundled with your coding tool.”

Setting it up

Claude Code — a second launcher, not a settings change.

Create a private launch command (claude-glm or similar) that supplies three things before Claude Code opens: the z.ai API key, the z.ai Anthropic-compatible base address, and the model-name mapping from Claude’s model slots to GLM 5.3. Leave your normal Claude settings untouched, so claude still opens an Anthropic session and claude-glm opens a z.ai one. If GLM misbehaves, close it and go back.

Keep the key in your environment or a secret manager, never in the project. The creator is emphatic and repeats it: if you are unsure you can handle API secrets safely, do not hand-roll this.

The concrete env-var block — including the trap where setting only ANTHROPIC_MODEL leaves Haiku and Sonnet on Anthropic’s paid endpoints — is in Ollama + Claude Code. Every model slot has to be overridden.

What follows the swap: the same repository, the same CLAUDE.md, the same hooks, MCP servers, tools, and permissions. What does not: the Anthropic conversation, the prompt cache, and any decision that was never written to a file.

Codex — a provider plus a profile. Add z.ai as a model provider in your personal Codex config (the address, and the name of the environment variable holding the key), then define a profile that says “use GLM 5.3, send it through that provider.”

The handoff file

If you must move a job mid-flight, make the current model write a handoff first. The creator’s fields:

• Goal — e.g. “update these 38 API calls to the new field name”
• Current state — “the current branch is clean; the affected calls are in these two folders”
• Relevant files
• Constraints — “don’t change the public API”
• Definition of done — “the old field name appears nowhere and all existing tests pass”
• Checks to run before returning

His argument for it: an hour-long investigation that ruled out three causes, learned one log line is misleading, and agreed not to touch the auth middleware is worth a paragraph. Pasting the raw transcript instead makes the new model rediscover which parts mattered — which is exactly the reused-input cost the 96% figure describes.

The handoff doubles as a routing diagnostic. If you would have to pull the entire parent transcript to hand a job over, the job is too unbounded to give to the cheap model. Keep it.

The lead-and-worker pattern

1. Ordinary Claude Code is the lead.
2. claude-glm is the worker, opened on the same project.
3. The lead writes the six-line handoff; the worker gets that, not the conversation.
4. If both will edit concurrently, put the worker in a git worktree — a separate checkout of the repo — so they cannot overwrite each other.
5. The worker returns changed files, the checks it ran, and anything it could not resolve.
6. The lead reviews when the job is consequential.

Still one project, one familiar tool, two sessions with an explicit contract between them.

What to send where

Send to the cheap model	Keep on the strong model
Clear target and clear permissions	The hard part is deciding what the job should be
Repository contains worked examples	Hidden state or conflicting evidence
Tests exist that can judge the result	Risky trade-offs that need weighing
Definition of done is specific	Root-cause investigation

The worked example runs both ways: renaming a field across 38 API calls goes to GLM; an intermittent authentication failure stays with the strongest model you trust — though a cheap worker can still gather logs and trace code paths for it.

Do not switch models repeatedly inside one conversation. Visible history is only part of the state; prompt caching and mid-conversation behaviour drift are not visible, and a new provider has to reconstruct all of it.

Calibrating, without under-reaching

The creator refuses to tell you where the line is — “there’s no substitute for actually testing… your code has its own level of complexity” — but gives the method, and warns against the wrong failure mode:

“Don’t be under-ambitious… give it a couple of ambitious tasks in my codebase, let’s see how it does, and let’s back off as we see failure and see where the true-up level for this particular model is.”

Start high, walk down to the boundary, then route there. The same method applies to cheaper tiers from Anthropic and OpenAI — he names Sonnet, Terra, and Luna — not just to third-party providers.

The harness is the thing you are actually keeping

The closing argument is about unbundling. Interface, workflow, and underlying service historically arrived as one purchase; both the Claude and Codex teams are, in his reading, willing to let the model be swapped out. What survives the swap is the harness and its ergonomics:

Claude Code “feels like a cockpit right now — I have to stay close to the work and I steer it.” Codex “can feel more like an ops desk — I dispatch jobs, let them run, inspect what comes back.”

Those work styles are endogenous to the harness, so they persist when another company supplies the intelligence. That is the reason to swap the engine rather than the tool.

A cautionary counterexample from the same source: Flo Crivello’s team at Lindy moved off Claude and ended up rebuilding the harness around the work they actually did in order to take advantage of an open-source model. The lesson offered is to look at the whole system before assuming a model swap is a drop-in.

Try It

1. Audit where your project’s knowledge lives. Coding standards, test commands, permissions, definition of done — in files, or only in chat history? Everything in the second category is locked to one provider.
2. Set up the second launcher, not a settings edit. claude and claude-glm side by side, so falling back is closing a window.
3. Pick one job with tests and a clear definition of done and run it end to end on the cheap model. Renaming or mechanical refactors across many files are the canonical fit.
4. Write the handoff template once and keep it in the repo. Six fields, six lines.
5. Use the transcript test as your routing rule. Needs the whole transcript to hand over → keep it on the strong model.
6. If both sessions will edit, use a worktree. This is not optional; it is the only thing preventing two agents from clobbering the same files.
7. Measure the fully loaded cost, not the token price. Retries, review time, and the cache-invalidation penalty on a mid-job switch all count. A cheaper model that needs three attempts is not cheaper.

Related

• Ollama + Claude Code — Cutting Token Costs with Local and Open Models — the environment-variable mechanics for GLM, OpenRouter, and local models; read it first if you have not swapped an engine before
• GLM-5.2 — Z.ai’s Open-Weight Agentic-Coding Frontier — the model itself
• Cheap-Executor Delegation — Four Shapes of the Same Cost Lever — this is the same-harness, two-session shape
• Cost & Intelligence Levers for Agent Workflows — the lever taxonomy this sits inside
• Subagents — the fork-must-match-parent-model constraint that forces the two-session workaround
• Model vs Effort in Claude Code — the in-family version of the same routing decision
• Claude Code Token Optimization — where the reused-input economics come from
• Dynamic Workflows in Claude Code — worktree isolation for concurrently-editing agents, the primitive the worker session needs
• Claude AI — topic index

Open Questions

• GLM 5.3 capability is asserted, not benchmarked here. The source gives no head-to-head numbers against Sonnet or Opus 5 on the task classes it recommends routing to GLM. The routing table is reasoning from task shape, not from measurement.
• Exact z.ai endpoints and model-slot names are deferred to a companion guide on the creator’s Substack rather than stated in the video. Verify against z.ai’s own documentation before wiring anything.
• Is the prompt-cache invalidation on /model in-family too? The warning is framed generally, but the video’s cross-provider case is where it clearly bites. Whether an Opus→Sonnet switch has the same penalty is not established here.
• No measured savings. The whole case is $18versus$200 plus a routing discipline; there is no before/after bill in the source.
• Whether a gateway or custom integration can give one subagent a different provider. The creator says it is possible but explicitly declines to recommend it for beginners, and does not describe how.