This feels like the first open model that doesn’t require significant caveats when comparing to frontier proprietary models. The parameter efficiency alone suggests some genuine innovations in training methodology. I am keen to see some independent verification of the results and to see how if does on Aider’s LLM Leaderboard.
I've been playing around with GLM-4.5 as a coding model for a while now and it's really, really good. In the coding agent I've been working on, Octofriend [1], I've sometimes had it on and confused it for Claude 4. Subjectively, my experience has been:
1. Claude is somewhat better at whole-codebase tasks, where you need to reason over a bunch of context and consider system interactions.
2. GLM-4.5 is somewhat better at being "honest" — i.e. I rarely see it doing the things Claude does like making broken tests pass by changing the test instead of fixing the bug.
Both are quite good though, and GLM-4.5 has found bugs that both Claude 4 Sonnet and 4.1 Opus have failed to catch. In general I think Claude wins a little more frequently on debugging tasks than GLM-4.5, but it's close.
Compared to GPT-5, both Claude and GLM feel like they're more consistent, although GPT-5 sometimes has long brilliant runs where it nails everything with subjectively higher code quality than either of the latter. However, once GPT-5 goes off the rails, it's hard to get it back on track, so it can be a bit frustrating to work with in comparison.
Really appreciate the depth of this paper; it's a welcome change from the usual model announcement blog posts. The Zhipu/Tsinghua team laid out not just the 'what' but the 'how,' which is where the most interesting details are for anyone trying to build with or on top of these models.
The post-training methodology (Sec 3) is what really stands out to me. The idea of creating specialized 'expert models' for reasoning, agents, and chat, and then distilling their capabilities into a final unified model is a fascinating approach. It feels like a more structured way to solve the "jack of all trades, master of none" problem that can plague generalist models. Instead of just mixing all the data, they're essentially having a generalist learn from a committee of specialists.
A couple of the findings from their RL experiments are pure gold for anyone working in this space. The counter-intuitive result that a single-stage RL process at the full 64K context length outperforms a progressive, multi-stage approach (Fig 6) is a fantastic lesson. I've seen teams assume the opposite would be true. Also, the pragmatic choice to use an XML-like template for function calls to avoid JSON escaping hell (Fig 4) may be a small but brilliant engineering decision that makes a huge difference in practice. Wrangling escaped code inside JSON turns out to be a mess.
The performance on SWE-bench is impressive, putting it in the same league as much larger or proprietary models. What I’d love to see, and maybe others here have thoughts, is whether this hybrid training recipe holds up outside ARC-style evals. For example, do the agentic improvements transfer to messier, real-world workflows where APIs are undocumented, partial failures are common, and user input is full of ambiguity?
Seems like we may get local, open, workstation-grade models that are useful for coding in a few years. By workstation-grade I mean a computer around 2000 USD, and by useful for coding I mean around Sonnet 4 level.
Current cloud based models are fun and useful, but a tool that is / will be so core to the developer experience, I want to be able to run locally.
The sheer number of things "they observed" in this paper that could be whole papers in themselves is astounding! Lots of great stuff in here around training processes and data collection+synthesis.
Does anyone have any background information on the authors? Have they published similarly impressive works in the past?
Ok so I asked "how many bs in bluberry" and it "thought" the following -
-----
First, the question is: "How many bs in bluberry?" That seems like a typo. I think it's meant to be "blueberry," but it's spelled "bluberry" with one 'e' missing. Also, "bs" probably refers to the letter 'b'.
So, rephrasing the question: How many times does the letter 'b' appear in the word "blueberry"?
But the word given is "bluberry," which might be a misspelling of "blueberry." Let me confirm the correct spelling. The standard spelling is "blueberry," which has two 'e's: b-l-u-e-b-e-r-r-y.
The question says "bluberry," which is missing the second 'e', so it's spelled b-l-u-b-e-r-r-y. That might be intentional or a mistake. I should answer based on the word as given.
The question is: "How many bs in bluberry?" So, I need to count the 'b's in "bluberry."
Let me write it out: B-L-U-B-E-R-R-Y.
Now, I'll go through each letter:
Position 1: B (that's one b)
Position 2: L (not b)
Position 3: U (not b)
Position 4: B (that's the second b)
Position 5: E (not b)
Position 6: R (not b)
Position 7: R (not b)
Position 8: Y (not b)
So, there are two 'b's in "bluberry."
But is "bluberry" the correct word? It's probably a misspelling of "blueberry." In "blueberry," it's B-L-U-E-B-E-R-R-Y.
Position 1: B (one)
Position 2: L
Position 3: U
Position 4: E
Position 5: B (two)
Position 6: E
Position 7: R
Position 8: R
Position 9: Y
"Blueberry" has nine letters, and there are two 'b's: one at the start and one after the 'e'.
In "bluberry," as given, it's eight letters: B-L-U-B-E-R-R-Y, with two 'b's.
Perhaps the question is tricking me with the misspelling. But I should answer based on what's written.
Another thought: "bs" might be plural for 'b', meaning how many 'b's, or it could be something else. But in context, it's likely about the letter.
Maybe it's a riddle. "Bluberry" sounds like "blueberry," but spelled differently.
Perhaps "bs" refers to something else, like the fruit or something, but that seems unlikely. The question says "bs," which is probably "b's" meaning the letter b.
Let me read the question carefully: "How many bs in bluberry?"
It might be a play on words. "Bluberry" could be intended as "blueberry," and "bs" might be misinterpreted.
Another idea: in some contexts, "b" could stand for something, but here it's probably straightforward.
Perhaps it's about the sound. But the question is written, so it's about spelling.
I think I should just count the 'b's in the given word.
So, in "bluberry": letters are B, L, U, B, E, R, R, Y. So, B appears twice.
Therefore, there are two 'b's.
But to be thorough, let's consider if "bluberry" is a word. It's not standard; it's a misspelling. However, for the purpose of this question, I'll use it as is.
Perhaps the question has a typo, and it's meant to be "blueberry." But since it's written as "bluberry," I'll go with that.
Final answer should be 2.
The question says "bs," which might be lowercase, but in counting, case usually doesn't matter, and here it's all lowercase or mixed? The word is "bluberry," which is lowercase, and "bs" is lowercase, so it's fine.
In English, when counting letters, we don't distinguish case unless specified.
So, I think two is correct.
But let me double-check the spelling. The user wrote "bluberry," which has one 'u' and no ...
So GLM-4.5 series omits the embedding layer and the output layer when counting both the total parameters and the active parameters:
> When counting parameters, for GLM-4.5 and GLM-4.5-Air, we include the parameters of MTP layers but not word embeddings and the output layer.
This matches with the calculation I did for GLM-4.5 (355B A32B):
In [14]: 356732107008 - (775946240 * 2) # token_embd / output are 775946240 each. assume omitted
Out[14]: 355180214528
In [15]: 356732107008 - 339738624000 - (775946240 * 2) # parameters that are always active
Out[15]: 15441590528
In [16]: 339738624000 * 8 / 160 # parameters from activated experts
Out[16]: 16986931200.0
Meanwhile, GPT OSS series includes both the embedding layer and the output layer when counting the total parameters, but only includes the output layer when counting the active parameters:
> We refer to the models as “120b” and “20b” for simplicity, though they technically have 116.8B and 20.9B parameters, respectively. Unembedding parameters are counted towards active, but not embeddings.
And Qwen3 series includes both the embedding layer and the output layer when counting both the total parameters and the active parameters.
Why there is no standard in counting? Which approach is more accurate?
What’s up with the charts? In their first figure they show sonnet 4 as having a swebench score of 53; in the next figure it’s close to 70. In reality it’s closer to the latter. [0]
18 comments
[ 9.5 ms ] story [ 73.1 ms ] thread1. Claude is somewhat better at whole-codebase tasks, where you need to reason over a bunch of context and consider system interactions.
2. GLM-4.5 is somewhat better at being "honest" — i.e. I rarely see it doing the things Claude does like making broken tests pass by changing the test instead of fixing the bug.
Both are quite good though, and GLM-4.5 has found bugs that both Claude 4 Sonnet and 4.1 Opus have failed to catch. In general I think Claude wins a little more frequently on debugging tasks than GLM-4.5, but it's close.
Compared to GPT-5, both Claude and GLM feel like they're more consistent, although GPT-5 sometimes has long brilliant runs where it nails everything with subjectively higher code quality than either of the latter. However, once GPT-5 goes off the rails, it's hard to get it back on track, so it can be a bit frustrating to work with in comparison.
1: https://github.com/synthetic-lab/octofriend
The post-training methodology (Sec 3) is what really stands out to me. The idea of creating specialized 'expert models' for reasoning, agents, and chat, and then distilling their capabilities into a final unified model is a fascinating approach. It feels like a more structured way to solve the "jack of all trades, master of none" problem that can plague generalist models. Instead of just mixing all the data, they're essentially having a generalist learn from a committee of specialists.
A couple of the findings from their RL experiments are pure gold for anyone working in this space. The counter-intuitive result that a single-stage RL process at the full 64K context length outperforms a progressive, multi-stage approach (Fig 6) is a fantastic lesson. I've seen teams assume the opposite would be true. Also, the pragmatic choice to use an XML-like template for function calls to avoid JSON escaping hell (Fig 4) may be a small but brilliant engineering decision that makes a huge difference in practice. Wrangling escaped code inside JSON turns out to be a mess.
The performance on SWE-bench is impressive, putting it in the same league as much larger or proprietary models. What I’d love to see, and maybe others here have thoughts, is whether this hybrid training recipe holds up outside ARC-style evals. For example, do the agentic improvements transfer to messier, real-world workflows where APIs are undocumented, partial failures are common, and user input is full of ambiguity?
Does anyone have any background information on the authors? Have they published similarly impressive works in the past?
-----
> When counting parameters, for GLM-4.5 and GLM-4.5-Air, we include the parameters of MTP layers but not word embeddings and the output layer.
This matches with the calculation I did for GLM-4.5 (355B A32B):
Meanwhile, GPT OSS series includes both the embedding layer and the output layer when counting the total parameters, but only includes the output layer when counting the active parameters:> We refer to the models as “120b” and “20b” for simplicity, though they technically have 116.8B and 20.9B parameters, respectively. Unembedding parameters are counted towards active, but not embeddings.
And Qwen3 series includes both the embedding layer and the output layer when counting both the total parameters and the active parameters.
Why there is no standard in counting? Which approach is more accurate?
[0] https://www.swebench.com/