GLM-5.2 vs Claude Opus 4.8 – Does GLM REALLY Beat Claude?

Summary of the Video (Subtitles) — GLM 5.2 vs Claude Opus 4.8

A creator runs an objective head-to-head comparison between GLM 5.2 (open weights) and Claude Opus 4.8 (closed model) across multiple tasks. The motivation is to test claims that GLM 5.2 may match or exceed Opus, noting that many prior claims lacked “visual evidence.”

---

1) Test: Open-ended game generation (3D skydiving simulator)

Method / Setup

• Each model is run inside its own vendor coding harness:
  • GLM 5.2 via ZAI / Zcode, using a “million context window” and Max reasoning.
  • Claude via Claude Code using command line on Linux (no official GUI/desktop for Linux).
• Both are used with paid subscription tiers:
  • GLM coding plan: ~$65/month
  • Claude Max 5X: ~$100/month
• The prompt is intentionally open-ended: build a 3D skydiving simulator with high-fidelity visuals, smooth gameplay, and indie polish.

Results

• Similar runtimes:
  • GLM 5.2: ~26m 57s
  • Claude Opus 4.8: ~27m 39s

GLM 5.2 gameplay observations

• Implements controls for:
  • speed changes (W/S)
  • deploying parachute/canopy
  • camera toggling
  • wind audio
• Gameplay includes flying through floating rings, with rings appearing connected to the player/interaction system.

Claude Opus 4.8 gameplay observations

• Also includes controls (examples):
  • Space to deploy canopy
  • A/D to steer
  • S to flare to land
• Includes UI elements like altimeter/compass, terrain detail, and wind noise.
• Includes rings and a navigable landscape with more varied terrain (e.g., a lake).

Critique noted (both)

• Both start the player mid-air (omitting the plane), described as an “abhorrent omission” for realism.

Takeaway

For this interactive 3D game generation, both models perform similarly well—at least at the level of functional gameplay + visuals + sound.

---

2) Test: Windows XP GUI AI chat app + packaged EXE (connects to local model server)

Goal

• Build a Windows XP-compatible GUI chat application that ships as a working EXE.
• The EXE should connect (over LAN) to a backend serving Ornith 35B MOE (served by an external system, e.g., LM Studio-like behavior).
• The prompt includes hardcoded endpoint/network assumptions and a specific request shape.

Constraints / Troubleshooting

• Testing is done from Linux; both models face a limitation: Linux box lacks Wine, so the creator can’t easily “eyeball” the GUI environment directly.
• The creator transfers files to a XP netbook and tests by phone-recording the screen.

Initial result

Both models launch the GUI, but cannot connect to the server:

• GLM: Windows error/crash on send attempt.
• Claude: “Could not reach the server” / “system cannot find the file specified”-style network error.

A follow-up prompt tries to simplify connection logic.

Third attempt (final success)

• GLM succeeds after the creator realizes the initial cause wasn’t the network; the fix appears related to text rendering / crash behavior.
• Claude succeeds after more work focused on network connectivity.
• By the end, both apps connect successfully, with GPU utilization mentioned for the server.

Results (timing)

• GLM initial attempt: ~23 minutes
• Claude Opus initial attempt: ~28 minutes
• Follow-ups:
  • GLM: ~15m 50s
  • Claude: ~9m 31s

Takeaway

Contrary to the expectation that one model would dominate, both can deliver a working XP chat app, but they fail for different reasons and require different fixes.

---

3) Test: Generate printable STL for a V8-looking engine/transmission for a tiny N20 DC motor

Goal

Create an STL (3D-print file) for a realistic V8 engine + transmission that:

• Fits an N20 motor used in small RC/tiny robots.
• Accounts for:
  • the output shaft hole/exit
  • wire access for positive/negative motor leads
  • possible presence of a geared N20 gearbox
  • intended direction/orientation (rear-wheel drive style chosen)

Important evaluation approach

• STL outputs are inspected via a slicer / OpenSCAD-like workflow.
• The focus is functional fit, not just aesthetics.

GLM 5.2 outcome

• GLM asks multiple clarifying questions (e.g., N20 type, whether a gearbox exists, whether motor drives wheels, shaft direction, print method like FDM).
• It generates multiple separate components/parts rather than a single monolithic assembly.
• Main issues during inspection:
  • floating cylinders/parts that would interfere
  • still missing functional output shaft exit
  • the author notes the output shaft is blocked by surrounding geometry/walls
• Wire routing space exists (noted as a partial positive).

Claude Opus 4.8 outcome

• Produces an OpenSCAD-style model with a visually impressive V8 + transmission appearance.
• Main issues:
  • no output shaft outlet, so the motor shaft couldn’t physically protrude for real use
  • gearbox inclusion not properly accounted for (or at least not correctly accommodated)

Overall verdict for the STL test

Both models can produce complex engine-like geometry, but both miss at least one critical mechanical constraint, especially the shaft outlet / gearbox accommodation.

• The creator frames it as:
  • GLM is respectable but not perfect
  • Claude was better, described as being in a “different league” for this prompt—despite also missing the shaft outlet.

---

4) Test: 3D “city block time travel” scene with a year slider (1945, 1965, 1985, 2005, 2025)

Goal

Create a high-end 3D city block scene with:

• a timeline slider supporting five years
• full transformations across:
  • buildings, vehicles, storefronts, ads, outfits, etc.
• sound effects, navigation controls, and “go all out” polish

The creator checks whether year changes feel like:

• a static “flick switch,” or
• richer transition effects with consistent world updates.

Observed issues

• GLM pauses/bugs during generation (beta-like behavior on Ubuntu app). A revised prompt is used: “don’t ask follow-up questions, just build it.”
• After ~an hour, both results are completed.

Visual / playback observations

GLM 5.2

• Interactive navigation: drag to look, zoom, pan
• Period-appropriate mood:
  • era-appropriate vehicles and pedestrian clothing
  • era-specific lighting changes
• Includes an “auto tour” moving between eras.
• Era-to-era changes are described as dynamic and impressive (e.g., streetlights shifting, outfit correctness, atmosphere).
• Includes sound effects and even smog particles for earlier/later periods.

Claude Opus 4.8

• Highly detailed scene with navigation and era-based transformations.
• Period elements are consistently updated:
  • outfits, ads, building textures, streetlight styles
• Similar transition behavior across eras, including attention to infrastructure changes (e.g., power lines changing between years).
• Some sound choices are described as annoying/noisy, leading the creator to turn sound off at points.

Takeaway

Both models are strong for this 3D asset / time-transformation scenario, but the creator concludes:

• Claude still has a massive lead overall in high-end 3D scene work and realism
• GLM can match some details, but falls short versus Claude’s polished results

---

Overall Conclusions Drawn by the Creator

• 3D game generation: GLM and Claude are close
• XP GUI chat app: both succeed after multiple tries; failure causes differ
  • GLM: appears to crash due to text rendering
  • Claude: struggled more initially with connection logic
• STL mechanical/fit test: both miss key mechanical constraints (notably the motor shaft outlet), but Claude’s modeling is judged better overall
• High-end 3D time-sliced city scene: Claude remains ahead in final polish and 3D scene quality

The creator emphasizes this is a performance/capability comparison, not a cost comparison—though subscription tiers are mentioned.

---

Main Speakers / Sources

• Main speaker/source: the YouTube video narrator/host (one person running the tests and operating the prompts/harnesses)
• Models tested:
  • ZAI / GLM 5.2
  • Anthropic / Claude Opus 4.8 (via Claude Code)