I’ve seen the headlines for weeks straight:
GLM 5.2 beating Claude Code on Semgrep’s IDOR benchmark
GLM 5.2 landing within a few points of Opus 4.8 on Terminal-Bench
GLM 5.2 costing a fraction of what I normally pay per session.
As someone who runs Claude Code daily for my products, I wanted to see if any of that held up on an actual task, not a leaderboard.
So I picked something small and personal:
I sit at a standing desk, and every single time I forget to actually stand up before a call starts.
I wanted a tiny macOS background utility that watches my mic, and the second it goes active, fires a notification telling me to get up.
I pointed Claude Code at GLM 5.2 and gave it one prompt.
Fifteen minutes later I had a working tool.
Here’s exactly how it went, what broke, and whether I’d actually recommend switching.
Setting Up GLM 5.2 Inside Claude Code
This is the part that trips most people up, so it’s worth being precise about it.
You don’t need a separate CLI or a forked version of Claude Code.
GLM Coding Plan hooks directly into Claude Code’s existing model-routing settings.
I opened ~/.claude/settings.json and added:
{
"env": {
"ANTHROPIC_DEFAULT_SONNET_MODEL": "glm-5.2[1m]",
"ANTHROPIC_DEFAULT_OPUS_MODEL": "glm-5.2[1m]",
"CLAUDE_CODE_AUTO_COMPACT_WINDOW": "1000000"
}
}The [1m] suffix turns on GLM's 1-million-token context window, which is honestly overkill for a five-file utility, but I wanted to see if it broke anything on a small session.
It didn't.
Claude Code booted up exactly the way it always does like the same UI, same tool-calling loop, just routed to Zhipu's infrastructure instead of Anthropic's on the backend.
The Prompt
I described the idea the way I would to a junior engineer, not an AI:
“Build a lightweight macOS background utility that detects when my microphone becomes active (Zoom, Meet, FaceTime, Slack calls) and fires a native notification telling me to stand up. Should auto-start on login, poll efficiently, avoid notification spam from mute/unmute toggling, and need zero third-party dependencies beyond Xcode Command Line Tools.”
That’s it. One paragraph.
Lately, I’ve also started experimenting with my prompts. You can read this later:
What GLM 5.2 Actually Built
Without much back-and-forth, it produced a genuinely sensible architecture:
mic_check.swift— a compiled Swift binary that queries CoreAudio directly (kAudioDevicePropertyDeviceIsRunningSomewhere) to check if the input device is livemic_monitor.sh— a bash daemon that polls the Swift binary every 5 seconds and runs a simpleIDLE ↔ ON_CALLstate machinecom.standup.micmonitor.plist— a LaunchAgent so the whole thing survives reboots and starts on logininstall.sh/uninstall.sh— one-command setup and teardown
What impressed me wasn’t the code itself
Because this isn’t complicated software, it’s that GLM made the right small decisions without me asking:
a 10-second cooldown so mute/unmute doesn’t spam me with notifications, sensible defaults for poll interval and sound, and a clean separation between the fast Swift detector and the bash orchestration layer instead of trying to do everything in one language.
That’s the kind of judgment call that’s easy to get lazy about, and it didn’t.
The whole thing compiled and ran on the first try.
No hallucinated CoreAudio APIs, no phantom Swift packages, no fighting with entitlements.
Ngl, It Actually Struggled Too!
Notification permissions. GLM’s first pass used a raw osascript call to fire notifications, which macOS attributes to "Script Editor" rather than the tool itself.
It's a known quirk with this approach, not a GLM-specific bug, but a frontier model with more macOS-specific training data might have flagged the permissions prompt proactively instead of leaving it as a troubleshooting note in the README.
Verbosity in edits. On a couple of follow-up tweaks (changing the notification sound, adjusting the cooldown), GLM rewrote more of the file than necessary instead of doing a surgical patch.
Nothing broke, but it’s the kind of token-inefficiency that would add up on a bigger codebase, which tracks with what Semgrep and others have flagged about GLM 5.2’s tendency to take the scenic route.
The Real Comparison: Cost
This is where GLM 5.2 actually wins the argument for a side project like this.
Z.ai prices GLM 5.2 at roughly $0.40 per million input tokens and $1.60 per million output tokens.
Claude Opus runs $15 input / $75 output.
For a fifteen-minute build session, that’s the difference between a session costing pocket change and one costing a few dollars.
For someone running Claude Code constantly across multiple micro-SaaS repos, that math changes behavior.
You stop rationing sessions.
You let the model write the README and the uninstall script without wincing at the invoice.
Will I Switch?
Not entirely, and not for everything.
On boilerplate, single-purpose utilities, README generation, and well-scoped refactors, GLM 5.2 inside Claude Code held up completely and I’d trust it with the next ten tools like this one without a second thought.
For anything touching a large, tangled codebase with real architectural ambiguity, the benchmark gap (GLM trails on SWE-bench-style, multi-file reasoning tasks) is a real signal, not noise, and I’d still reach for Claude’s native models.
Here is the full repo, including the install script and the LaunchAgent template, is open source:
github.com/hubshashwat/get-up-on-calls
Clone it, run ./install.sh, join a call, and see if it actually gets you off the chair.
In case we are meeting for the first time, come over here, it’ll be worth the roller coaster of articles that are gonna come up in the next few weeks.
And if you’re hunting for your next startup idea, GritGlean aggregates real demand signals and pain points from Reddit, X, HN, Stack Exchange, Quora and more, and it even finds existing apps for sale if you’d rather skip the build :)