CHAPTERS
- 0:00 – 0:30
Why GLM 5.2 matters: “Opus-level” reasoning without the frontier price tag
Claire frames the video as a practical test of whether an open-weight model can match top proprietary models for coding while costing far less. She sets expectations: this is the start of a series evaluating whether developers can avoid paying the “Anthropic/OpenAI tax” by using open models locally or via cheaper inference providers.
- •Goal: compare GLM 5.2’s real-world coding performance vs. premium frontier models
- •Positioning: open-weight/open-source model reviews as an ongoing series
- •Motivation: cost, reliability of access, and vendor lock-in concerns
- •Promise to test on personal machine/projects rather than only benchmarks
- 0:30 – 1:31
Sponsor break: Mercury Command (conversational banking workflows)
A sponsored segment introduces Mercury Command, emphasizing getting work done via conversation rather than dashboards. Claire highlights how it uses real account data and respects permissions and approvals.
- •Mercury Command as a chat-based interface for banking actions and questions
- •Focus on reducing friction vs. navigating dashboards/menus
- •Actions like invoices, categorization, and payments via conversation
- •Data is grounded in the user’s Mercury account; permissions apply
- 1:31 – 4:02
What “open-weight” actually means (and why it changes the economics)
Claire explains GLM 5.2’s origin (Z.AI, Beijing) and clarifies what open-weight implies: downloadable model weights, self-hosting, and potential fine-tuning. She notes licensing nuances and emphasizes the practical benefits—lower inference costs and reduced vendor lock-in.
- •GLM = General Language Model; produced by Beijing-based startup Z.AI
- •Open-weight = weights available to download/run/inspect/fine-tune
- •License varies: open-weight doesn’t automatically mean “free” for all uses
- •Benefits: self-hosting, cheaper inference, and flexibility across providers
- 4:02 – 4:32
Capabilities & constraints: huge context window, text-only I/O, modern tooling features
Before setup and testing, Claire outlines what the model can and can’t do. GLM 5.2 supports many ‘modern’ ergonomics like tool/function calling and structured output, but it’s limited to text-in/text-out despite its massive context window.
- •1M-token context window for large codebases and long tasks
- •Constraint: text-to-text only (no images in/out)
- •Supports thinking/reasoning mode and streaming output
- •Function calling, context caching, structured outputs, and MCP support
- 4:32 – 6:03
Benchmark positioning: why it’s worth a serious coding test
Claire reviews external benchmark results showing GLM 5.2 competing with or nearing frontier models on coding-relevant suites. The takeaway: on paper, it’s in the same arena as top models, which justifies hands-on evaluation.
- •Strong showing on Frontier Suite/Post-Train Bench/SWE-Marathon vs. major models
- •SWE-Bench Pro performance roughly comparable to some top proprietary options
- •Claim under test: ‘Opus-level coding’ at much lower cost
- •Decision: move from benchmarks to real developer workflows
- 6:03 – 7:04
Getting GLM 5.2 into your coding stack via OpenRouter (provider choice and API key)
Claire chooses OpenRouter as the inference provider because her laptop won’t run GLM 5.2 locally. She walks through the basic prerequisites: OpenRouter account, billing limits, and creating an API key that will be reused across tools.
- •Using hosted inference instead of local due to hardware constraints
- •OpenRouter as a unified gateway for commercial + open-weight models
- •Account setup: add card, optional spend limits, generate API key
- •Plan: connect OpenRouter to Cursor and Claude Code
- 7:04 – 8:34
Setup walkthrough: GLM 5.2 in Cursor (the undocumented “/cursor” base URL nuance)
Claire demonstrates the specific Cursor configuration needed to route requests through OpenRouter. The key gotcha is the base URL must include a special “/cursor” suffix, and the model must be added as a custom model identifier.
- •Cursor → Settings → Models: paste OpenRouter key into OpenAI API key field
- •Critical base URL override: openrouter.ai/api/v1/cursor
- •Add custom model name: z-ai/glm-5.2
- •Verify model appears in Cursor chat model selector
- 8:34 – 11:06
Setup walkthrough: GLM 5.2 in Claude Code (shell env vars + settings.json)
For Claude Code, Claire follows OpenRouter’s docs: add environment variables in the shell profile and update Claude’s settings to use the GLM model string. She explains where shell profiles live and how non-terminal experts can edit them safely.
- •Edit shell profile (zshrc/bashrc) to set OpenRouter API key + base URL
- •Claude Code base URL differs from Cursor setup (no “/cursor” suffix)
- •Clear/replace Anthropic default auth token so traffic routes to OpenRouter
- •Update .claude/settings.json to set model to GLM 5.2 identifier
- 11:06 – 12:37
Live test #1: codebase exploration + architecture/ship history audit (ChatPRD)
Claire asks GLM 5.2 to explore the ChatPRD repository and summarize architecture plus recent shipping work. The model returns quickly with a correct Next.js full-stack overview and identifies recent themes like stability, billing, promos, and security hygiene.
- •Prompt: explore codebase, summarize architecture + recent shipped work
- •Result: accurate Next.js full-stack understanding and component breakdown
- •Correct callouts: Chat v2 stability, billing, promo work, security/dependency hygiene
- •Initial impression: fast, accurate, not ‘a dumb model’
- 12:37 – 15:10
Live test #2: generate an HTML architecture + roadmap page (communication + design taste)
To test clarity and “agent-to-human” communication, Claire asks for a polished HTML page visualizing architecture and roadmap. The output is surprisingly presentable, reflects product pillars accurately, and even matches brand color preferences better than some frontier models.
- •Prompt: create a reviewable HTML page for architecture + roadmap
- •Output includes: app anatomy (chat turn), product pillars, shipped items, roadmap themes
- •Design quality: ‘slop-adjacent’ but not ugly; coherent layout and styling
- •Positive surprise: good brand color choices (ChatPRD pink) and relevant roadmap suggestions
- 15:10 – 16:41
Sponsor reprise: Mercury Command (ditching dashboards for conversational actions)
A second sponsor segment reinforces Mercury’s positioning: fewer dashboards, more direct task completion via conversation. It reiterates that responses/actions come from real financial data and respect existing controls.
- •Critique of dashboard-heavy workflows for founders
- •Command enables asking for cash position, invoices, categorization, etc.
- •Built-in context from Mercury account data
- •Permissions/approval workflows remain intact
- 16:41 – 21:15
Live test #3: redesigning the How I AI landing page hero in Cursor (iterate with feedback)
Claire tasks GLM 5.2 with redesigning a specific hero/header section to improve design quality, workflow CTA, and SEO. The first pass is ‘not bad’ with stronger CTAs and useful metadata; she then gives targeted critique about overly bright buttons and requests a second iteration.
- •Prompt: redesign hero for better design, workflow CTA, and SEO alignment
- •First pass: improved workflow CTA, hover effects, useful metadata/value props
- •Adds a ‘listen’ sidebar/player concept; some UI details feel off/busy
- •Second pass after feedback: subtler styling, but still some layout imbalance; overall promising for design work
- 21:15 – 22:45
Live test #4: 45-minute autonomous task—pull Sentry + Vercel logs and plan fixes
Claire evaluates GLM 5.2’s agentic behavior with a long-running task: gather 72 hours of Sentry errors and Vercel logs, then produce a prioritized fix plan. The model uses tool/MCP calls, requests Vercel auth, and compiles a plan artifact for review.
- •Prompt: pull last 72 hours of Sentry + Vercel errors and prioritize fixes
- •Runs for ~30–45 minutes during recording; uses tools/MCPs and reads outputs
- •Asks for Vercel authentication mid-run (good real-world behavior)
- •Generates a reviewable plan (presented as HTML/canvas) with priorities and sequencing
- 22:45 – 25:17
Where it struggled (and what it still did well): TypeScript/React friction vs. strong HTML/tooling
Mid-task, Claire observes the model struggling with TypeScript/JavaScript compilation and worries about React reliability—critical for her workflow. After some back-and-forth, it compiles cleanly and the final plan quality redeems the experience.
- •Observed weakness: initial TypeScript/JS errors; concern about React generation
- •Strengths: strong HTML/CSS output and effective tool querying/data digestion
- •Temporary failure state resolved: eventually compiled cleanly
- •Lesson: agentic planning + tooling can be great even if framework codegen is uneven
- 25:17 – 27:13
Verdict + cost breakdown: surprisingly capable, extremely cheap for the output
Claire concludes GLM 5.2 is good enough to keep in her rotation for front-end work and long-running back-end agent tasks. She reports spending $3.36 for ~6M tokens via OpenRouter (with high cache rate), calling it a ‘steal’ compared to premium frontier models and hinting she may later run it locally with better hardware.
- •Overall take: strong performance; worth keeping in Cursor + Claude Code rotation
- •Best use: front-end iterations + long-running agentic debugging/planning tasks
- •Cost: $3.36 for ~6M tokens; ~72% cache rate; bulk spent on long autonomous run
- •Next steps: continue testing, consider buying hardware for local inference; invites model requests from viewers
