Live data from Hacker News

GLM 5.2 vs. Opus

techstackups.com

241–250 of 367 posts

Re: GLM 5.2 vs. Opus

#241
i think inference is the thing, that also fast inference, so enterprises can just host their own and run, ig vercel do it, many more would. but zs it thinks toooo much idk how fast we can make it.

Re: GLM 5.2 vs. Opus

#242

I’m actually amazed at the output since GLM doesn’t have eyes. If GLM 5.2 costs 1/5 as much, seems like it could be set up to reach out to a multimodal model for vision tasks when required. Closer to parity but probably still significantly cheaper.

I'm also very impressed at the output given the lack of image support.

They picked a task that heavily favors a model that can do multi-modal with images, and GLM still came within striking distance.

What I'm hearing from this article is that the next generation of open models that includes better multi-modal support are basically no-brainers for adoption.

Seems like a HUGE win for Z.ai and open models in general here.

Re: GLM 5.2 vs. Opus

#243

Earlier quoted context omitted.

Enforcing structured outputs from LLMs is not the same thing as using linters, formatters, static analysis to control how an agent writes code.

No, it's not. It's strictly better.

Can you share examples, links to Github of this approach? I'd like to learn.

Re: GLM 5.2 vs. Opus

#244

I was never able to get these models to collaborate with me the way Opus does. I'm probably an outliner, I don't one-shot projects, I don't vibe code. I basically use LLMs are if I was working with a coworker, fairly smart one, but with short memory and often missing the big picture. Sometimes I can delegate more, sometimes less, but I know I always have to stay on top of what's happening, because it WILL create mess…

> Opus 4.6 which was bad for some reason

If I recall, that model had a couple issues. One was the issue of being monkeyed with, for which they gave everyone credits.

The other feature/bug, depending on your POV, was being Anthropic's least personable release, not papering over everything with self help guru therapy language.

Opus 4.6 didn't LARP. It was more direct, less fussy, less discussy, and very much less "wait, one more thing" within a couple edits after embarking on what should have been the spec, than 4.7 or 4.8 are.

When in engineer brain mode, working as as you describe (good old fashioned XP-style staff engineer pair programming with a language-savvy mentee not yet full-stack or system wise), I found the clearer I was about my goal and the better I could express it, the more often I'd get an expanded clarified response I could then iterate to steer for ever tighter cleaner more specified responses, then let it go build the whole thing without it agonizing and waffling.

The next two releases regressed on that dimension, wanting to figuratively "sit with" every decision and re-validate spiritual alignment along the way, no matter how clearly expressed.

Curiously to me, Fable seemed to hit the best of both worlds, I had the highest commit per turn with Fable, approaching 73%, where I'm usually under 17% of LOC written being good enough to commit, usually taking 9 - 11 turns to get the code where I'm comfortable with it.

Thanks to this, Fable cost more, but actually cost less, if that makes sense.

Arguably, Fable, and 4.6, played more outcome-correctness oriented than journey-experience oriented. It's easy to see how this could happen with human reinforced learning if not all judges are staff or principal engineer level, or constitution values are more Portlandia than Finlandia.

ANTHROP\C needs to balance these at the constitution level:

“We will work in a humane and thoughtful way, but production is the final judge. We will listen to people, but we will not let discussion replace decision. We will value craft, but not at the expense of usefulness. We will move fast, but not by hiding risk. We will measure outcomes, but not pretend that everything important is easy to measure.”

Re: GLM 5.2 vs. Opus

#245

I was never able to get these models to collaborate with me the way Opus does. I'm probably an outliner, I don't one-shot projects, I don't vibe code. I basically use LLMs are if I was working with a coworker, fairly smart one, but with short memory and often missing the big picture. Sometimes I can delegate more, sometimes less, but I know I always have to stay on top of what's happening, because it WILL create mess…

What do they do instead of collaborating?

Re: GLM 5.2 vs. Opus

#247
It is insane that we are comparing locally-hostable models to leading cloud providers, it is wild to me that this article even exists.

We have come a long way, and very clearly have a long way yet to go.

Re: GLM 5.2 vs. Opus

#248

Earlier quoted context omitted.

Care to share more about your pi setup? I've recently started using it (after long-time Claude Code work) and was wondering how you'd achieve these long-running tasks. Do you allow it to spawn sub-agents? Thank you!

My pi usage over the past ~5 months went roughly like this: * Install pi and a bunch of extensions from their package repo * Realize that all the packages (with a few exceptions) are massively overcomplicated and vibe coded * Ask pi to rebuild a very simple version of the packages I used. So e.g. subagents - all the default subagent extensions are massively complicated with named agents, recursion, communication. I m…

What type of task are you running for ten hours? Is this a programming task?

I've not come across a programming task that would take an LLM ten hours.

Re: GLM 5.2 vs. Opus

#249

It is insane that we are comparing locally-hostable models to leading cloud providers, it is wild to me that this article even exists. We have come a long way, and very clearly have a long way yet to go.

Calling GLM-5.2 locally hostable is a bit of a stretch. It's 1.5Ti of weights at bf16. FP8 requires >800Gi of VRAM which is well into data center multi-GPU systems

Re: GLM 5.2 vs. Opus

#250
post #6

I've been checking out GLM 5.2 on some projects and few thoughts on it: - it takes it sweet time to get code rolling, not the fastest model by any means - it strays a lot during discovery/planning but then corrects - it's not steering friendly, as it hallucinates things that it doesn't follow later on - its output is quite good A sample use case: I was optimizing rendering on Swift+Zig codebase. It chocked on 5k data…

>it takes it sweet time to get code rolling, not the fastest model by any means

Which provider are you using? I got a z.ai Lite Coding Plan and it's my understanding z.ai is on the slower side of providers and the Lite plan gets lower priority on top of that. In the api key console, it shows dipping below 60 tok/sec which is quite slow.

Post reply on HN