GLM 5.2: A Live Review of an Opus-Level Open-Weights Model

GLM 5.2 handled a repository audit, a landing-page redesign, and a 45-minute autonomous debugging session for a total recorded cost of $3.36 through OpenRouter. That combination alone makes it worth paying attention to if you spend a lot on frontier coding models.

In this episode of How I AI, I tested the open-weights model inside Cursor and Claude Code on real ChatPRD work instead of benchmark demos: understanding an existing Next.js app, redesigning a production marketing page, and pulling Sentry and Vercel signals into a prioritized fix plan.

GLM 5.2 is an open-weights model from Z.ai. Rather than running it locally, I used hosted inference through OpenRouter so I could compare it directly against the proprietary models already in my day-to-day coding workflow without changing tools or hardware.

The interesting question was not whether GLM 5.2 could score well on public benchmarks. It was whether it could survive real software-engineering tasks with my prompts, my repositories, and my existing design system. In practice, it was fast, surprisingly competent at architectural reasoning, and strong on HTML and UI iteration. The rough edge showed up once the work became heavily React and TypeScript dependent. During the long autonomous run, it repeatedly stumbled on implementation details before eventually recovering.

Setting up GLM 5.2 in Cursor and Claude Code

I used OpenRouter as the hosted inference layer. After creating an API key and adding a spending limit, I routed both Cursor and Claude Code through the same GLM 5.2 endpoint so the comparison stayed consistent across tools.

That setup also made it easy to swap models in and out of the exact same workflow instead of testing GLM 5.2 in isolation.

Cursor configuration

Cursor mostly worked out of the box, but one undocumented detail caused most of the setup friction: the OpenRouter base URL must include the trailing /cursor path.

1. 1. Open Cursor Settings and select the Models tab.
2. 2. In API Keys, paste the OpenRouter key into the OpenAI API Key field and enable it.
3. 3. Enable Override OpenAI Base URL and use the OpenRouter Cursor endpoint. The trailing /cursor path is required.
4. 4. Open the full model list, add a custom model, and enter zai/glm-5.2.

Once configured, GLM 5.2 appears like any other model inside the Cursor picker, routed through OpenRouter instead of a default provider. You can follow the full implementation in How to Configure the Open-Weight GLM 5.2 Model in Cursor. See How to Configure the Open-Weight GLM 5.2 Model in Cursor.

Claude Code configuration

Claude Code uses environment variables plus its local settings file, so the setup is a little more terminal-heavy than Cursor.

1. 1. Add the OpenRouter credentials to the shell profile used by the terminal. Keep the API key out of source control.

    export OPENROUTER_API_KEY="your-open-router-api-key"
    export OPENROUTER_BASE_URL="https://openrouter.ai/api/v1"
    export CLAUDE_ANTHROPIC_API_KEY=""

1. 2. Update the Claude settings file so its model property points to the GLM 5.2 identifier.

    {
      "model": "z-ai/glm-5.2"
    }

Model identifiers can change over time, so it is worth checking the current OpenRouter naming before copying the configuration directly. During this recording, the identifier was zai/glm-5.2.

After that, new Claude Code sessions route requests through OpenRouter automatically. The broader pattern here is simple: choose an inference provider, replace the API endpoint, and point your coding tools at the model you want to test.

Exploring a production codebase and generating an architecture review See How to Perform an AI-Powered Codebase Audit and Architecture Visualization.

The first test was intentionally practical. I dropped GLM 5.2 into the ChatPRD repository and asked it to explore the codebase, explain the architecture, and summarize the most recent product work. This is the kind of orientation task engineers constantly hand to AI tools when joining projects or revisiting older systems.

Example architecture prompt: This is the ChatPRD codebase. Explore it, explain its architecture, and summarize the most recent product work.

The response was fast and mostly accurate. It correctly identified the application as a Next.js stack, mapped major integrations, and summarized recent work around Chat V2 stability, billing updates, promotional flows, and dependency-security cleanup. More importantly, the summary sounded grounded in the repository contents rather than generic architectural filler.

I then pushed it one step further and asked it to turn the audit into a browsable HTML architecture page that could communicate both the current system and the roadmap to another developer.

Example follow-up: Turn the findings into an HTML page that explains the application architecture and upcoming roadmap. Choose the components that best communicate the major technical and product decisions to a developer, then give me a page I can open for review.

The generated page was genuinely useful. It broke the app into product pillars, diagrammed the anatomy of a chat turn, summarized recently shipped work, and proposed roadmap areas like enterprise functionality, integrations, and knowledge retrieval. Several of those suggestions lined up with active priorities.

The design itself also revealed something interesting about the model. The visual language still leaned toward the familiar blue-purple AI aesthetic I jokingly call "blurple," but it also picked up ChatPRD’s pink branding correctly, which many models fail to do consistently. The output was not production-ready design work, but it crossed the threshold from novelty into something an engineer could actually review with a team.

Redesigning the How I AI landing-page hero

The second workflow focused on frontend iteration inside an existing design system. I asked GLM 5.2 to redesign the hero section of the How I AI landing page, improve the call to action around workflows, and strengthen the page’s SEO presentation without rebuilding the whole site.

Example design prompt: Redesign the hero of the How I AI landing page. Improve the visual quality, make workflows easier to discover, and address relevant SEO needs. Use your judgment on the design and show me the result.

The first pass was better than I expected for a loosely specified design prompt. It improved the workflow call to action, added metadata about the show, and introduced a sidebar treatment for YouTube, Spotify, and Apple Podcasts that looked more like a media player.

The weaknesses were mostly aesthetic judgment issues. The platform buttons were oversized, overly saturated, and visually louder than the rest of the hero. I gave one direct round of feedback focused specifically on button width, brightness, and alignment with the existing ChatPRD visual system.

Example feedback: I like the direction, but the YouTube, Spotify, and Apple Podcasts buttons in the listening sidebar are too bright, wide, and visually dominant. Redesign that component so it feels more refined and proportional to its content.

The second pass was noticeably cleaner. The buttons became darker, smaller, and less distracting, and the overall component fit the surrounding page more naturally. There were still balance issues between the left and right sides of the layout, but the iteration loop worked well.

This was one of the clearest examples in the episode of where lower-cost models can still be very effective. The task had clear constraints, an existing design language, and fast human review. GLM 5.2 did not need exceptional originality. It needed enough taste and responsiveness to refine a bounded UI problem quickly, and it delivered that surprisingly well.

Running a 45-minute autonomous bug investigation

The longest test started before recording and ran in the background through most of the episode. I asked GLM 5.2 to pull the previous 72 hours of Sentry errors and Vercel logs, analyze the issues, and produce a prioritized remediation plan.

Example autonomous task: Pull the last 72 hours of Sentry errors and Vercel logs, then produce a prioritized bug-fix plan based on the observed issues.

Over roughly 30 to 45 minutes, the model behaved like a reasonably capable autonomous coding agent. It created a task list, made tool calls into Sentry and Vercel, paused for authentication when necessary, analyzed the incoming data, and assembled a structured output.

The process was not smooth the entire time. The model repeatedly hit friction while generating React and TypeScript code for the reporting interface. At several points it appeared stuck on compilation and implementation details rather than reasoning about the bugs themselves. The distinction mattered because the investigation logic remained useful even while the code generation quality dipped.

The final output was an HTML dashboard summarizing 20 Sentry issues, five Vercel runtime signals, and 14 proposed fixes. It identified two issues as P0 severity, grouped events by volume and severity, and suggested an order for remediation work.

What made the result compelling was not perfect execution. It was the amount of operational triage compressed into a single autonomous run. Instead of manually pulling logs, organizing issues, and drafting a repair sequence, the model assembled a reviewable engineering plan with prioritization already attached.

The caveat is important: these were model-generated recommendations, not validated fixes. The prioritization still required human review, especially because the model struggled during portions of the implementation phase. But as a long-running evidence-gathering and synthesis tool, the workflow was genuinely productive. See How to Deploy an Autonomous AI Agent for Bug Triage and Prioritization.

What the test showed and what it cost

Across all three workflows, GLM 5.2 consistently proved useful for repository orientation, UI iteration, HTML generation, and long-running investigative tasks. The model felt especially strong when it could reason over large amounts of text and produce structured summaries or interfaces from that information.

The biggest weakness was complex React and TypeScript work. The model could eventually recover from some implementation failures, but the struggle was visible enough that I would still hesitate to hand it unsupervised frontend engineering work with complicated application state or strict typing requirements.

OpenRouter reported a total cost of $3.36 for roughly six million tokens with a 72 percent cache rate across the recorded tests. Most of the usage came from the autonomous Cursor task pulling and analyzing operational logs.

That is not a universal price benchmark because costs depend on providers, caching behavior, and workflow patterns. Still, compared with running equivalent exploratory and agentic tasks on top-tier proprietary models, the economics were hard to ignore.

I kept GLM 5.2 installed in both Cursor and Claude Code after the episode because it earned a place in the rotation. The strongest case for it is not replacing frontier models outright. It is handling the large category of engineering work where speed, context handling, and low operating cost matter more than flawless code generation.

I would confidently use it for codebase audits, roadmap synthesis, operational investigations, HTML-heavy tooling, and iterative design work inside an existing system. I would still keep a closer human hand on complex React and TypeScript implementation, especially when correctness matters more than exploration speed.