Codex vs Claude vs GLM 5.2: A Practical Comparison
The question I keep getting asked is which AI coding assistant I actually use day to day. The honest answer is that I use more than one, and the reason is that none of them is uniformly the best. Each one has a lane where it clearly wins, and each one has a failure mode that pushes me back to the others.
This post is a practical comparison of three tools I have spent real time with: Codex, Claude, and GLM 5.2. I am not interested in benchmark scores or leaderboard positioning. I care about how these tools behave across the full lifecycle of a project: initial scaffolding, iterative refinement, design polish, and long-running reliability.
The short version: GLM 5.2 has replaced Codex as my daily driver for implementation work. Codex failed the wife test, which is what pushed me to switch. Claude is strong on design and polish but showed a huge regression after two weeks of use. GLM 5.2 is great at identifying tiny lingering issues and regressions, but the last 24 hours of work showed a 40% false positive rate when validated against Claude. The rest of this post explains what each of those statements actually means.
What I Mean by the Wife Test
The wife test is not a technical benchmark. It is the moment a tool has to explain itself to someone who is not a developer and does not care about the tool at all.
In my case, that is my wife using an app I built. She does not read the commit history. She does not care which model generated which screen. She cares about whether the app opens, whether the buttons do what they say, and whether anything feels broken or weird. If a tool produces code that passes my review but ships an experience that a non-developer immediately notices is off, that tool failed the wife test.
Codex consistently produced clean, well-structured code. The diffs were focused, the tests were reasonable, and the implementation logic was sound. But the resulting UX often felt like it was built by someone who had never watched a real person use the app. The spacing was slightly wrong, the empty states were unhelpful, and the error messages read like they were written for another engineer, not for the person staring at the screen.
That is the gap. Code quality is necessary but not sufficient. A tool can win every code review and still lose the room the moment a real user touches the product.
For infrastructure work, scripts, and backend logic, that tradeoff is fine. For anything a non-developer will touch, I have learned to expect a second pass with a different tool.
GLM 5.2 as Daily Driver: Code Quality and Productivity
GLM 5.2 has replaced Codex as my default for implementation work. When I want a focused change, a real test plan, and a diff I can review without reconstructing the entire file, GLM 5.2 is the tool I reach for first. I made the switch after finding that GLM 5.2 matched Codex on code quality while also being available through Ollama Cloud without the same rate limit pressure.
The strengths are consistent. GLM 5.2 understands the repo as a unit, not just the file in front of it. It preserves the thread of the work across sessions, runs the checks, and reports back with proof. The code quality is high enough that I rarely have to rewrite the logic. I edit, I tighten, and I move on.
I have been super productive with GLM 5.2. It identified a lot of technical debt across the codebase, and I churned through a large set of the issues it surfaced. The result is that my app is now stable and well tested in a way it was not before. The thoroughness that drives the false positive rate is the same thoroughness that made this cleanup possible: GLM 5.2 kept surfacing things until they were actually fixed.
The one thing that holds GLM 5.2 back is the Ollama weekly limit. The limit is real, and when you are in the middle of a productive cleanup pass it is the constraint that stops you, not the tool. That is the tradeoff for the always-available availability I mentioned earlier: the tool is always there until the weekly quota runs out, and then you wait.
Claude: Design and Polish, Then Regression
Claude is the tool I reach for when the work is the experience. If GLM 5.2 builds the skeleton, Claude does the finish work: layout, spacing, copy, empty states, and the small interactions that make a product feel intentional.
The design sense is real. Claude will rework a screen so that it reads better, suggest copy that actually sounds like a human wrote it, and catch the UX inconsistencies that GLM 5.2 leaves behind. When I need a feature to feel finished rather than just functional, Claude is the right tool.
The problem is what happens over time. After about two weeks of steady use, I saw a huge regression. The quality of the suggestions dropped noticeably. The design instincts that made Claude valuable early on seemed to flatten out. The output became more generic, less tuned to the project, and more like a template than a collaborator.
I do not know exactly what causes that regression. It could be context management, it could be model drift, or it could be the way the tool adapts to repeated prompts. What I can say is that the drop was large enough that I stopped trusting Claude as the primary tool for a long-running project and started using it for targeted polish passes instead.
A disclaimer on the Claude regression: the observations above were written a few weeks back using Claude Sonnet 4.6 and 4.8. I have been using Sonnet 5.0 for a week and Fable 5 for the last 24 hours, and the results are fantastic. The regression problem I described may turn out to be specific to the 4.x line, but it is too early to say for certain. I will update this post if the pattern holds or breaks over a longer stretch.
GLM 5.2: Catching Regressions, With Caveats
GLM 5.2 is the newest of the three in my workflow, and it is the one that surprised me. I am running GLM 5.2 through Ollama Cloud, which means the tool is always available with no quota window to wait out. Where GLM 5.2 really shines is identifying tiny lingering issues and regressions that slip past the other tools. It will flag a subtle edge case or a half-finished refactor that Codex and Claude both missed. The specific things it catches well are the structural ones: missing try/catch blocks, logic errors where a branch returns the wrong value or skips a needed step, and swallowed exceptions where an error is caught and silently dropped instead of being handled or surfaced. Those are exactly the bugs that survive a code review because the diff looks reasonable in isolation. Notably, Claude Sonnet 4.6 and 4.8 both missed these same missing and swallowed exceptions, so this is a real gap in Claude, not just a general blind spot. GLM 5.2 is also very good at finding missing test coverage, sometimes obsessively. It will flag an untested branch, an uncovered error path, or a public function with no corresponding test, and it will keep surfacing those gaps until they are addressed. That is genuinely useful, though it can tip into overkill when the coverage it demands is more than the change actually warrants.
The catch is the false positive rate. Over the last 24 hours of work, I ran every GLM 5.2 finding through Claude to validate it, and roughly 40% of the issues GLM 5.2 flagged turned out not to be real problems. GLM 5.2 is great at surfacing candidates, but you cannot take its output at face value. The validation step is not optional; it is the difference between fixing a real regression and chasing a ghost.
One thing that made the validation step more reliable was Claude Sonnet 5.0. Across the same set of flagged issues, Sonnet 5.0 was noticeably more certain about which fixes were actually needed than Opus 4.8 and Sonnet 4.6. Where Opus 4.8 and Sonnet 4.6 would hedge or suggest multiple possible interpretations, Sonnet 5.0 would commit to a clear diagnosis and a clear fix. That confidence is what made the 40% false positive rate manageable: I could trust Sonnet 5.0's judgment on which GLM 5.2 findings were real and which were noise.
The other cost of GLM 5.2's thoroughness is token churn. GLM 5.2 second-guesses itself a lot. It will flag an issue, walk it back, re-flag it from a different angle, and then circle around to the original framing before settling. That looping behavior burns tokens fast. I burnt 45% of my weekly limit in two sittings, mostly on GLM 5.2 re-examining the same concerns instead of committing to a fix. The always-available availability I mentioned earlier cuts both ways: nothing stops the tool from spending that availability on re-deriving conclusions it already reached, and the weekly quota is what runs out first.
There is also a reliability wrinkle I have not fully diagnosed. Some work times out once in a while, and I am not sure whether that is an Ollama thing or a GLM thing. The failure mode is that a run just stops responding and I have to restart it, which is annoying but not frequent enough to be a deal breaker. The other quirk is specific to GLM in VSCode: it keeps asking if we should pause frequently. Mid-task, it will surface a prompt checking whether I want to stop or continue, which breaks the flow when I am trying to let it run. I do not know whether that is a model behavior or a client behavior, but it is worth knowing before you commit to a long unattended session.
There is one important caveat. GLM 5.2 ignored the AGENTS.md file in this repository and implemented fixes directly on main instead of branching out. The AGENTS.md file documents the workflow rules for this repo, including the expectation that changes are surgical and tied to an issue. GLM 5.2 produced workable code, but it skipped the process guardrails entirely. That is the same pattern as the wife test problem from a different angle: the output was right, but the workflow around it was not. Code quality is not enough if the tool cannot also respect the conventions of the repo it is working in. One thing to note though: GLM 5.2 is more honest about its mistakes than Claude. Claude would not admit it failed to follow the AGENTS.md file, or it would blame the failure on lack of memory from a different session. GLM 5.2 would own up to it.
That is the pattern I have settled on. GLM 5.2 for implementation and for surfacing issues and regressions, Claude for the polish pass and validation. None of them is the whole answer. Together they cover the range of work a real project requires.
How I Actually Use Them Together
The practical workflow looks like this:
- Start with GLM 5.2 for the implementation. GLM 5.2 produces reviewable, testable code that holds up under scrutiny.
- Run GLM 5.2 again to catch lingering issues and regressions it missed on the first pass, but validate every finding through Claude before acting on it.
- Run a polish pass with Claude on anything a user will see. Let Claude fix the copy, the spacing, and the empty states.
- Validate the polished result against the original implementation. If Claude changed the logic, that is a signal to review, not accept.
- For the riskiest changes, keep GLM 5.2 on a tight leash: review the diff carefully and lean on Claude Sonnet 5.0 or Fable 5 to validate the logic before accepting.
The point is not to pick a winner. The point is to use each tool for what it is actually good at and to stop expecting any single model to be uniformly best across code, design, and long-running reliability.
Going Forward: GLM and Claude Side by Side, Split by Criticality
The rate limits are the real constraint, and the workaround I have settled on is not a rotation but a split. The perfect model for me in the last few days is to run GLM 5.2 with an Ollama monthly plan in one window, working on a medium-criticality project, and Claude with Sonnet 5.0 in another window, working on a critical project. Both tools stay busy at the same time, and because the work is spread across two providers, I can get through a significant amount of work without triggering either one's limits.
GLM 5.2 handles the medium-criticality work where its thoroughness at catching regressions and missing test coverage is an asset and its false positive rate is tolerable. Claude with Sonnet 5.0 handles the critical work where I need the most certain diagnoses and the cleanest fixes. The two windows do not compete for the same quota, so neither one becomes the bottleneck for the other.
Claude is also on a monthly plan right now, but I am strongly considering moving it to an annual plan. The split setup has made Claude the tool I lean on for the work that matters most, and locking in the annual plan would remove the month-to-month friction around renewal and pricing. GLM 5.2 stays on the Ollama monthly plan for now, since it is the newer tool in my workflow and I want to keep the option to adjust as it matures.
Final Thought: Two $20 Plans Is Enough
As of today, here is where I have landed. I started on Codex, switched completely to Claude, and iterated from Sonnet 4.6 to 4.8 to finally 5. I was disappointed with 4.8; it did not feel like a clear step forward over 4.6, and in some ways it felt like a step sideways. That disappointment is what pushed me to look harder at the other tools. I finally settled on Sonnet 5 for daily routine work and Fable 5 for codebase analysis and validation. GLM 5.2 complements Fable 5 nicely on a less user-facing project I am simultaneously working on: GLM 5.2 surfaces the issues and does the implementation, and Fable 5 validates the codebase-level concerns that are hard to see from a single diff.
My current thinking is that I will settle on two $20-a-month plans, one for Claude and one for Ollama. That is enough tokens to cover the day-to-day for a part-time hobbyist. I am not running any single tool all day, and the split across two providers means I am not paying for capacity I do not use. Two $20 plans, two tools, two windows, and the work gets done.
Comments