GLM-5 vs DeepSeek V4: which one actually finishes your coding tasks?

Two model families come up in almost every "which Chinese model should I use for coding" thread: Z.ai's GLM line and DeepSeek's flagship. Both are cheap relative to Western frontier models. Both are good. The difference only shows up once you put them inside an agent loop that edits files, runs tests and recovers from its own mistakes.

This is not a leaderboard post. Published benchmark scores move weekly and rarely survive contact with a real repository. What follows is the structural difference between the two, and a harness you can run against your own codebase in under an hour.

Where they actually differ

Instruction following vs. self-correction. GLM models are tuned hard for tool use and terminal-style task completion. They tend to call tools early, keep going after a failed command, and rewrite their own patch. DeepSeek models are tuned for reasoning depth: they will spend more tokens thinking before they act. On a multi-step refactor with an ambiguous spec, that usually helps. On a task that has an obvious mechanical solution, it can waste your budget.

Cost shape, not just cost. A reasoning-heavy model that thinks for 3,000 tokens before writing 40 lines is not cheaper than a model that writes the patch on the first pass, even at a lower per-token price. Compare cost per completed task, not cost per million tokens. Both models expose input, output and cached pricing on their model pages here — check them before you assume.

Failure modes. In practice, agentic coding failures cluster into three buckets:

• wrong file touched (tool-selection error)
• correct plan, broken syntax (generation error)
• correct patch, no test run (loop-termination error)

Reasoning-tuned models fail mostly in the third bucket: they decide they are done. Tool-tuned models fail mostly in the first: they get confident about the wrong file. Whichever bucket costs you more review time should decide the pick.

The 40-minute harness

You do not need a benchmark suite. You need ten tasks from your own backlog that are small, verifiable, and already solved.

1. Pick ten merged PRs of 20–80 changed lines each. Revert them on a branch.
2. Give each model the same prompt template: issue text, failing test command, and the repo tree. No hints.
3. Run both through the same agent scaffold with the same tool budget — 30 steps, no retries beyond that.
4. Record four numbers per task: completed (y/n), test pass (y/n), wall-clock, and total tokens billed.
5. Multiply tokens by the live price for both models and compare cost per completed task.

Ten tasks is enough to see a 30% difference. It is not enough to see a 5% difference, and a 5% difference does not matter.

What we would default to

• Greenfield feature work with a clean spec: the tool-tuned model, with a tight step budget.
• Refactors across unfamiliar code, migrations, test repair: the reasoning-tuned model, with an explicit "run the tests before you answer" instruction.
• Anything with a per-task budget: run both on the harness once, then standardise. The price gap between these two families is small enough that task completion rate dominates the decision.

Two operational notes

Cache aggressively. Both lines support cached input pricing, and agent loops resend the same system prompt and repo context on every step. If your scaffold does not reuse the prompt prefix, you are paying full input price ten to thirty times per task.

Pin versions. Model IDs on this platform are versioned, and upstream providers do swap weights under the same family name. Pinning the exact ID in your agent config is the difference between a reproducible eval and a moving target.

Both models are live in the Model Square, and the exact per-token numbers are on each model page. Run the harness before you commit to either.