Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GLM 5.2 vs. Opus

techstackups.com

Post reply on HN
Print view View original

151–160 of 367 posts

Re: GLM 5.2 vs. Opus

#151

Post by rdsubhas »

cultofmetatron wrote: post #19

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…

IMHO, It's not the oneshotting.

It's the "starting from empty slate" greenfield that's the real problem.

We used to make fun of Engineers who follow a README on a framework, test it on an empty project, and say "this framework is the best for our 10 year running production app". Greenfield mentality is always the solution to all problems and problem to all solutions.

One should still measure oneshotting, it's an important self-measurement metric - but against an established, large codebase.

Re: GLM 5.2 vs. Opus

#152

Post by ulrikrasmussen »

cultofmetatron wrote: post #19

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…

I guess the experiment is interesting to determine if a model can produce something subjectively valued as "good" based on fairly vague and open-ended specifications. The benchmark is not to determine if the output fits the input, but whether the output is internally consistent: it's a game, but does it behave as one would expect that any game behaves? Does it end when you each the goal, do you die when hitting the spikes, are there weird edge cases in behavior when you move around?

I think however that they should have used the same harness and also repeated the experiment a few times to judge the variance in results.

Re: GLM 5.2 vs. Opus

#153

Post by tpm »

pietz wrote: 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.…

Also, I was testing out the GLM 5.2 using Openrouter because that's where I've got an account with some money and then when I wanted to perhaps subscribe for a better deal at z.ai, their infra was clearly overloaded to the point the 5.2 was timing out on 100% of chat requests, so perhaps I will try later when the infrastructure catches up with the model capability. Only then I can make sure their subscription is worth it.

Re: GLM 5.2 vs. Opus

#154

Post by Mashimo »

yanhangyhy wrote: post #70

i think GLM 5.2 is not cheap and not easy to get the coding plan... so even it's on the Opus level... still not attractive.

I used GLM (4.7, 5 and 5.1) both through their coding plan and now through OpenCode zen. Both where painless to get.

Re: GLM 5.2 vs. Opus

#159

Post by keheliya »

rdsubhas wrote: post #151
cultofmetatron wrote: post #19

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…

IMHO, It's not the oneshotting. It's the "starting from empty slate" greenfield that's the real problem. We used to make fun of Engineers who follow a README on a framework, test it on an empty project, and say "this framework is the best for our 10 year running production app". Greenfield mentality is always the solution to all problems and problem to all solutions. One should still measure oneshotting, it's an impo…

There are upcoming benchmarks aimed at measuring the ability to work with brownfield tasks. (Of course, benchmarks can be gamed, but they are still better than unrealistic toy tasks that earlier generations of benchmarks used. Frontier labs are yet to use them in their tech reports or marketing material, though.:-)

* SWE-EVO: Benchmarking Coding Agents in Long-Horizon Software Evolution Scenarios https://arxiv.org/abs/2512.18470 * SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration https://arxiv.org/abs/2603.03823

Re: GLM 5.2 vs. Opus

#160

Post by usef- »

stavros wrote: post #147
usef- wrote: post #40

Earlier quoted context omitted.

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.

Oh I know. But people often point to the API usage cost as an indicator of the magnitude of subsidisation, or to say that the big labs are far less efficient than cheap competitors.

I'm saying that this is not necessarily the case. They do a lot of optimisation and don't have the same price pressure to lower margins. They may not be losing as much on subscriptions as people think.

Post reply on HN