How to Use GLM-5.2 in Codex and Cut Costs by Up to 50%

GLM-5.2 is an excellent coding model. Codex is an excellent coding-agent harness.

You can combine them through OpenRouter.

Codex supports custom model providers in ~/.codex/config.toml. OpenRouter exposes GLM-5.2 as z-ai/glm-5.2. Put those together and you can run local Codex workflows against GLM-5.2 while keeping Codex's repo workflow, shell execution, file editing, review loop, and verification habits.

The cost target is simple: lower cost per accepted coding task. Model price matters, but retries, broken tool calls, review cleanup, and abandoned sessions decide the real economics.

Key Findings

Evidence and Methodology

Codex custom providers define how Codex connects to a model: base URL, wire API, authentication, and optional headers. That makes Codex a good fit for OpenRouter-based model routing.

OpenRouter's Codex setup uses a custom provider with:

model_provider = "openrouter"

[model_providers.openrouter]
name = "openrouter"
base_url = "https://openrouter.ai/api/v1"
env_key = "OPENROUTER_API_KEY"

For GLM-5.2, use the exact OpenRouter model ID:

z-ai/glm-5.2

At the time of writing, OpenRouter lists GLM-5.2 with a 1M-token context window and $0.95 / $3 per 1M input/output token pricing. That makes it a strong candidate for coding-agent work where the highest-cost default model is not required.

Useful references:

• OpenAI Codex custom providers: https://developers.openai.com/codex/config-advanced
• OpenAI Codex models: https://developers.openai.com/codex/models
• OpenRouter Codex CLI guide: https://openrouter.ai/docs/cookbook/coding-agents/codex-cli
• OpenRouter GLM-5.2 model page: https://openrouter.ai/z-ai/glm-5.2

Concrete Operator Scenario

An engineering team uses Codex locally for repo work. Engineers like the harness: it can inspect files, edit code, run commands, execute tests, and explain diffs. The team wants to reduce AI coding spend without changing the daily developer workflow.

The team adds OpenRouter as a Codex provider and tests GLM-5.2 on specific work classes:

The rollout pattern is model routing. Keep Codex as the interface. Use GLM-5.2 for task classes where it lowers accepted-task cost. Keep premium models available for harder or riskier work.

Measurement Approach

Benchmark full Codex sessions, not isolated prompts.

Use the same repository, task prompt, acceptance criteria, and verification commands across your current Codex model and GLM-5.2.

Track:

Lower model pricing is the hypothesis. Lower cost per accepted coding task is the result that matters.

OpenRouter Setup

Add this to ~/.codex/config.toml:

model = "z-ai/glm-5.2"
model_provider = "openrouter"
model_reasoning_effort = "high"

[model_providers.openrouter]
name = "OpenRouter"
base_url = "https://openrouter.ai/api/v1"
env_key = "OPENROUTER_API_KEY"
wire_api = "responses"

Set your OpenRouter key:

export OPENROUTER_API_KEY="sk-or-..."

Start Codex:

codex

Check the route:

/status

Run a real task in a real repository. Do not judge the setup from a single chat-style prompt.

One-Off Test

If the provider block already exists in ~/.codex/config.toml, you can test GLM-5.2 for one run:

OPENROUTER_API_KEY="sk-or-..." \
codex -c model_provider='"openrouter"' -m z-ai/glm-5.2

Use the persistent config for team guidance. It is easier to inspect, version in internal docs, and reproduce across machines.

Internal Proxy Option

Use an internal proxy only if your team already operates an AI gateway or needs controls that OpenRouter does not provide.

The shape is:

Codex
  -> custom model provider
  -> internal gateway
  -> model backend

Use this when you need:

• team-level attribution,
• internal logging,
• policy controls,
• caching,
• fallback routing,
• model aliases,
• provider abstraction.

Keep the same Codex contract: base URL, auth, wire API, and model ID must match what Codex expects. If the gateway only supports Chat Completions, test carefully. Codex can support Chat Completions providers today, but that path is deprecated in Codex and should not be the default recommendation for new setups.

Caveats And Failure Modes

Most failures come from provider compatibility and agent-loop behavior.

The practical rule: use GLM-5.2 where it lowers accepted-task cost without increasing retries, tool failures, or review burden.

What To Do Next

Run this five-task benchmark:

• Ask Codex to inspect a real repo and explain the relevant files.
• Ask it to make a small implementation change.
• Ask it to update or add tests.
• Ask it to run tests and fix failures.
• Ask it to summarize the final diff and risks.

Compare GLM-5.2 against your current Codex default on:

• total session cost,
• retry count,
• latency,
• tool-call success,
• test success,
• review rewrite,
• accepted outcome rate.

If GLM-5.2 reduces cost without hurting completion quality, make it the default for those task classes. Keep stronger models available for harder work.

Related Pages

• How to Use GLM-5.2 in Claude Code and Cut Costs by Up to 50%
• What Is AI-Native Developer Intelligence?
• What Is Engineer-Agent Effectiveness?
• What Is Agent Readiness?
• What Is Token Cost Effectiveness for AI Coding?

FAQ

Can I use GLM-5.2 inside Codex?

Yes. Use Codex custom model providers with OpenRouter and set the model to z-ai/glm-5.2.

Should I use OpenRouter or direct provider setup?

Use OpenRouter for this workflow. It has a documented Codex CLI setup and exposes GLM-5.2 directly.

Where should I put the Codex provider config?

Put it in user-level ~/.codex/config.toml. Provider and auth settings are not appropriate for project-local .codex/config.toml.

Does this work for Codex cloud tasks?

This guide is for local Codex CLI and IDE workflows. Codex cloud task model defaults are separate.

What is the biggest caveat?

Provider compatibility. Verify the full coding loop: file search, edits, shell commands, tests, git diff, streaming, retries, and review quality.