Live data from Hacker News

GLM 5.2 vs. Opus

techstackups.com

141–150 of 367 posts

Re: GLM 5.2 vs. Opus

#141

I seriously dont' know all this big hullabaloo about one shot prompting. by definition, a single prompt wont' constitute the complexity of a software project. ergo, what you'll get is a series of assumptions made by the model based on preexisting code in its training corpus. I'd rather see a coding agent that can follow steps in a plan file to a T while following guardrails and adhering to the proper coding conventio…

If a model can take a series of increasingly complex instructions and satisfy the requirements without human intervention, we can pretty easily decide how well overall the model does. And, judging better models just means adding more requirements to a task. So, I think it's a useful method (Even if it's not a realistic use case). Of course, with a software engineer at the helm - the models are going to be able to be…

> If a model can take a series of increasingly complex instructions and satisfy the requirements without human intervention (...)

This is the wrong metric to target. Today's models can feel one-shot but they are so at the expense of resilient ReAct loops that brute force their way out of the mess initial prompts created.

And each iteration is expensive.

Sometimes failing fast and early is better than going for one-shot models that try to mitigate the mess they created with reasoning steps and ReAct loops.

Re: GLM 5.2 vs. Opus

#142
post #66

GLM 5.2 has one big issue that will limit its meaningful success and that's the value of their coding subscription. Yes, in terms of API pricing, GLM 5.2 outperforms the competition. But the only people that use API billing for their coding work are large corporations, where these highly subsidized subscriptions are being fazed out. At the same time, none of these companies will use a Chinese API for their employees.…

This is an important point. I suspect API pricing will eventually disappear just like how paying for an MMS disappeared. It's an antiquated model. The bulk of the work is being done on "coding plans" is my wild guess.

It's annoying that the plans are so restrictive beyond usage limits. Understandable maybe, but annoying. In practice, only Anthropic (and maybe Google) are really restrictive though. They really scared me away with their policy of charging API rates after the fact if they consider your usage not TOS-aligned. This might be an ungrounded fear that I have, but I feel this is something they'd do so they scared me away.

Re: GLM 5.2 vs. Opus

#143
I was surprised today by how much better GLM-5.2 was than GPT-5.5 at aesthetic/UI work. I'll keep my Claude/Codex setup via Conductor for now, but this model got me to set up OpenCode, download their desktop app and do most of my work there today.

Re: GLM 5.2 vs. Opus

#144

I seriously dont' know all this big hullabaloo about one shot prompting. by definition, a single prompt wont' constitute the complexity of a software project. ergo, what you'll get is a series of assumptions made by the model based on preexisting code in its training corpus. I'd rather see a coding agent that can follow steps in a plan file to a T while following guardrails and adhering to the proper coding conventio…

Single prompt performance is interesting because best agentic results of yesterday turned out to be best single prompt results of today.

If we stopped developing LLMs the the only reasonable way to benchmark them would be to compare yheir performance with all the tricks we can build on top of them. Sine the are still developing rapidly any apples to apples comparison is worthwhile.

Of course this particular benchmark is not really single prompt but rather "agentic without steering".

Re: GLM 5.2 vs. Opus

#145
post #66

GLM 5.2 has one big issue that will limit its meaningful success and that's the value of their coding subscription. Yes, in terms of API pricing, GLM 5.2 outperforms the competition. But the only people that use API billing for their coding work are large corporations, where these highly subsidized subscriptions are being fazed out. At the same time, none of these companies will use a Chinese API for their employees.…

Taking a view from outside the USA, European companies just had Fable taken away due to US export controls, and before that Anthropic announced it is holding their data for 30 days. There is immediate value to these firms to build their infrastructure around an AI that won’t be pulled away from them. And outside of Europe, other countries are more price sensitive and don’t have the same fear of building relationships with Chinese companies.

Re: GLM 5.2 vs. Opus

#146
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…

Its also nice that you can see its entire reasoning trace. I can see it going off the rails - or see something I forgot to tell it - and stop and correct it. Or I'll learn WHY it made the choice it did and not have to question it after.

Strong agree! I deeply appreciate this aspect of GLM. Watching it think & being able to nudge early is incredibly useful. Being able to point at bad assumptions is incredibly useful. Watching what it's seeing is super informative.

It's always a shock to me how opaque most other models are!

It also is pretty resilience to letting you inject in while it's working without going off course or while getting back on track after, which I appreciate

Re: GLM 5.2 vs. Opus

#147
post #40
post #11

Earlier quoted context omitted.

Is it fair when the one is heavily subsidized and the other one is not? I think it's most fair to compare the plain token pricing that is used by everyone.

Z.ai is also believed to be "subsidised". Its parent company is running at a large loss right now. Anthropic have claimed they expect their first profitable quarter this year -- they may have bigger margins on their raw API than you realise.

We're all sure they have big margins in their raw API, it's the subscription we're claiming is subsidised.

Re: GLM 5.2 vs. Opus

#148

I seriously dont' know all this big hullabaloo about one shot prompting. by definition, a single prompt wont' constitute the complexity of a software project. ergo, what you'll get is a series of assumptions made by the model based on preexisting code in its training corpus. I'd rather see a coding agent that can follow steps in a plan file to a T while following guardrails and adhering to the proper coding conventio…

One shotting is useful to test but only with a huge prompt (eg, build something according to this spec).

I agree generating millions of tokens from a handful of input tokens doesn't convey anything meaningful to me.

Re: GLM 5.2 vs. Opus

#149
post #66

GLM 5.2 has one big issue that will limit its meaningful success and that's the value of their coding subscription. Yes, in terms of API pricing, GLM 5.2 outperforms the competition. But the only people that use API billing for their coding work are large corporations, where these highly subsidized subscriptions are being fazed out. At the same time, none of these companies will use a Chinese API for their employees.…

I'm on glm pro subscription and I get so so so much more usage than Claude or Codex! I hammer on glm all day. It's a more expensive plan, but I would need a much much much bigger plan for codex or Claude to do what I do.

Re: GLM 5.2 vs. Opus

#150

Having issues with coding a render for good looking realistic smoke coming off burning incense, opus 4.8 & gpt-5.5 both have code issues, glm-5.2 did it. Amazing. The real time 3d fluid dynamics appear to be the tricky part, I wish I still had opus access, would love to see if it can do it.

You mean Fable?
Post reply on HN