If you only use one large language model, you optimize around its idiosyncrasies until they stop looking like idiosyncrasies. Switch to a second one and the differences re-surface, and now you have a baseline. Run the same well-specified task through four models in parallel and you stop having opinions about models. You have evidence.
Over the last few sessions I have been doing exactly this: writing a tight, structured prompt (usually a single deliverable like a bash script or a markdown skill file with every constraint enumerated) and dispatching it to GPT-5 (via the codex CLI), GLM-5.1, GLM-4.6, and DeepSeek-V3.2 in parallel. Then comparing the outputs side by side, fixing whatever each one got wrong, and shipping. The fixing patterns are not random. Each model has a signature failure mode that shows up across tasks, and once you know what to look for you can route work to the model most likely to nail it on the first pass.
This is a working set of observations, not a benchmark study. Model versions, wrappers, and prompts change, so these routing choices need to be retested against the current workload.
The single dominant failure mode for the GLM family: reasoning leakage
GLM-5.1 has a visible “thinking” mode. It can produce a draft, notice its own bugs, write meta-commentary about what it should fix, and then emit a corrected version. All of this may land in stdout. In one bounded example, extracting the corrected script meant identifying the second #!/usr/bin/env bash and slicing from there.
This is not a defect of the prompt. The prompt said “output only the script contents.” The thinking-mode output is just what GLM-5.1 produces when it is being thoughtful. The fix is post-processing, not prompt engineering. Strip the reasoning block before treating the output as canonical.
GLM-4.6 has a different problem: it does not reason visibly, but it also does not fully transform prompt scaffolding into final content. If your prompt says “include a short intro (3-4 lines)” and “a bulleted list of 4-5 triggers,” GLM-4.6 will sometimes leave the literal strings “A short intro:” and “A bulleted list of 4-5 triggers:” in the body, as if it were halfway through a draft. The structure is there, the content is mostly there, but the prompt’s instructions about the form leak through into the form itself.
The corrective for both is the same: never ship a GLM output without reading it end-to-end. They produce good content, but they also produce content that looks done before it is.
Codex is precise and expensive
In this comparison, GPT-5 via the codex CLI followed the specification more closely and usually needed less post-processing. Its mistakes came from plausible but wrong assumptions about the target repository, such as an import path or local pytest-marker convention. That is a reminder to test against the real project rather than treating clean output as proof.
The tradeoff is reasoning cost versus review cost. Codex spent more of its budget reasoning before producing the output, while the GLM runs were cheaper but needed more cleanup. Neither is strictly better. The right choice depends on the failure cost and how cheaply a reviewer can catch the mistakes.
One DeepSeek-V3.2 dispatch produced a working helper script with an idiomatic bug: it used ${PYTHON_VENV:-python3} to pick an interpreter, which falls back when the variable is empty or unset, not when the path is missing. One example is not enough to establish a routing rule, but it is useful as a reminder that a mostly working script can still miss the operating condition that matters.
The plumbing has its own failure modes
The tooling you use to reach the models matters as much as the models. Two failure modes show up no matter which model is on the other end, and both come from the command-line wrappers rather than from the model itself.
The first is a silent hang. Some tools wait for their input stream to close before they run, and a scripted invocation may never send that signal. It looks like the model stalled, but the model was never called. The lesson worth keeping is that a stalled dispatch is not always a stalled model.
The second is a runaway process. If you launch a long dispatch in the background and then stop the wrapper that started it, the underlying model call does not always stop with it. It keeps running, detached, and on a metered API it keeps spending money for as long as it wants to continue. Worse, the status you get back reads “completed,” because the wrapper is reporting on itself, not on the process it left behind. The lesson is to confirm the work actually stopped, not just that the launcher exited.
When to route what
A working set of rules, given the patterns above:
Codex for any production Python or bash script where correctness is load-bearing and the spec is detailed. Specifically: subprocess shims, test files with structural assertions, anything that pins an API surface, anything where a silent bug costs more than the extra tokens.
GLM-5.1 when you want a self-correcting pass and you are willing to post-process. Useful for medium-complexity bash where you want the model to catch its own off-by-one errors before you do.
GLM-4.6 for high-volume structured prose: skill documentation, markdown templates, anything where the shape is fixed and the content is the variable. Faster than GLM-5.1, more prone to placeholder leakage, but the output is recoverable with a single cleanup pass.
DeepSeek for bash-plus-Python glue, given a strong reviewer downstream. One data point is not enough to recommend it for production-grade work without further use.
The cross-cutting rule: never run a parallel dispatch without an output review step. The whole point of dispatching to multiple models is that each one will get something wrong. The cost of the dispatch is the parallel API calls; the cost of not reviewing the outputs is the bugs you ship because one of the models was confident and wrong.
A note on token economics
A naïve reading is “the model with cheaper tokens is cheaper to use.” That ignores review and rework. Subscription terms, per-call pricing, and model availability also change. The useful calculation is what the completed, reviewed task costs in wall clock and attention.
This is the same trap as the agent-swarm decomposition pattern I wrote about last week. Cheaper-per-call is not cheaper-per-task. Decomposing a task across many small cheap models can cost more than running it once through a model that gets it right on the first pass, because the cleanup cost is not paid by the API.
The takeaway
Use the model that nails your spec on the first pass, not the model that is cheapest per token. For most well-specified tasks today that means codex. For prose where the shape is more forgiving, GLM-4.6 is faster and the post-processing cost is acceptable. For everything else, run a parallel dispatch and pick the best output, but only if you trust your review process to catch what each model gets wrong. The interesting question is not “which model is best.” It is “which failure mode am I prepared to handle.”