3 ms·

It's an okay model. My biggest issue using GLM 5.1 in OpenCode is that it loses coherency over longer contexts. When you crest 128k tokens, there's a high chanc

It's an okay model. My biggest issue using GLM 5.1 in OpenCode is that it loses coherency over longer contexts. When you crest 128k tokens, there's a high chance that the model will start spouting gibberish until you compact the history. For short-term bugfixing and tweaks though, it does about what I'd expect from Sonnet for a pretty low price.

embedding-shape 7mo ago
> It's an okay model. My biggest issue using GLM 5.1 in OpenCode is that it loses coherency over longer contexts Since the entire purpose, focus and motivation of this model seems to have been "coherency over longer contexts", doesn't that issue makes it not an OK model? It's bad at the thing it's supposed to be good at, no?
- wolttam 7mo ago
  long(er) contexts (than the previous model) It does devolve into gibberish at long context (~120k+ tokens by my estimation but I haven't properly measured), but this is still by far the best bang-for-buck value model I have used for coding. It's a fine model
  - verdverm 7mo ago
    Have you tried gemma4? I'm curious how the bang for buck ratio works in comparison. My initial tests for coding tasks have been positive and I can run it at home. Bigger models I assume are still better on harder tasks.
  - disiplus 7mo ago
    i have glm and kimi. kimi was in most of the cases better and my replacement for claude when i run out of tokens. Now im finding myself using glm more then kimi. Its funny that glm vs kimi, is like codex vs claude. Where glm and codex are better for backend and kimi and claude more for frontend. as kimi did a huge amount of claude distilation it seems to be somewhat based in data https://www.anthropic.com/news/detecting-and-preventing-distillation-attacks https://www.anthropic.com/news/detecting-and-preventing-dist...
whimblepop 7mo ago
That's pretty few, at least for the way I'm currently using LLMs. I have them do some Nix work (both debugging and coding) where accuracy and quality matters to me, so they're instructed to behave as I would when it comes to docs, always consulting certain docs and source code in a specific order. It's not unusual for them to chew through 200k - 600k tokens in a single session before they solve everything I want them to. That's what I currently think of when I think of "long horizon within a single context window". So I need them to not only not devolve into gibberish, but remain smart enough to be useful at contexts several times longer than that.
azuanrb 7mo ago
Have you compared it with using Claude Code as the harness? It performs much better than opencode for me.
jauntywundrkind 7mo ago
Chiming in to second this issue. It is wildly frustrating. I suspect that this isn't the model, but something that z.ai is doing with hosting it. At launch I was related to find glm-5.1 was stable even as the context window filled all the way up (~200k). Where-as glm-5, while it could still talk and think, but had forgotten the finer points of tool use to the point where it was making grevious errors as it went (burning gobs of tokens to fix duplicate code problems). However, real brutal changes happened sometimes in the last two or three months: the parent problem emerged and emerged hard, out of nowhere. Worse, for me, it seemed to be around 60k context windows, which was heinous: I was honestly a bit despondent that my z.ai subscription had become so effectively useless. That I could only work on small problems. Thankfully the coherency barrier raised signficiantly around three weeks go. It now seems to lose its mind and emits chaotic non-sentance gibberish around 100k for me. GLM-5 was already getting pretty shaky at this point, so I feel like I at least have some kind of parity. But at least glm-5 was speaking & thinking with real sentances, I could keep conversing with it somewhat, where-as glm-5.1 seems to go from perfectly level headed working fine to all of a sudden just total breakdown, hard switch, at such a predictable context window size. It seems so so probable to me that this isn't the model that's making this happen: it's the hosting. There's some KV cache issue, or they are trying to expand the context window in some way, or to switch from one serving pool of small context to a big context serving pool, or something infrastructure wise that falls flat and collapses. Seeing the window so clearly change from 200k to 60k to 100k is both hope, but also, misery. I've been leaving some breadcrumbs on Bluesky as I go. It's been brutal to see. Especially having tasted a working glm-5.1. I don't super want to pay API rates to someone else, but I fully expect this situation to not reproduce on other hosting, and may well spend the money to try and see. https://bsky.app/profile/jauntywk.bsky.social/post/3mhxep7ekg22r https://bsky.app/profile/jauntywk.bsky.social/post/3mhxep7ek... All such a shame because aside from totally going mad & speaking unpuncutaed gibberish, glm-5.1 is clearly very very good and I trust it enormously.
- esseph 7mo ago
  > "aside from totally going mad & speaking unpuncutaed gibberish [...] I trust it enormously." The bar is very low :(
cassianoleal 7mo ago
I've done some very long sessions on OpenCode with Dynamic Context Pruning. Highly recommend it. https://github.com/Opencode-DCP/opencode-dynamic-context-pruning https://github.com/Opencode-DCP/opencode-dynamic-context-pru...
HumanOstrich 7mo ago
I wonder if running the compaction in a degraded state produces a subpar summary to continue with.
- gunalx 7mo ago
  Indeed it does. Once i see degraded state i revert to last task and run a compact, before starting up again.
nkko 7mo ago
Yes, this is frustrating, but it doesn’t occur in CC. I run the conversation logs through an agent and opencode source, and it identified an issue in the reasoning implementation of opencode for Zai models. Consequently, I ceased my research and opted to use CC instead.

embedding-shape 7mo ago

> It's an okay model. My biggest issue using GLM 5.1 in OpenCode is that it loses coherency over longer contexts Since the entire purpose, focus and motivation of this model seems to have been "coherency over longer contexts", doesn't that issue makes it not an OK model? It's bad at the thing it's supposed to be good at, no?

wolttam 7mo ago
long(er) contexts (than the previous model) It does devolve into gibberish at long context (~120k+ tokens by my estimation but I haven't properly measured), but this is still by far the best bang-for-buck value model I have used for coding. It's a fine model
- verdverm 7mo ago
  Have you tried gemma4? I'm curious how the bang for buck ratio works in comparison. My initial tests for coding tasks have been positive and I can run it at home. Bigger models I assume are still better on harder tasks.
- disiplus 7mo ago
  i have glm and kimi. kimi was in most of the cases better and my replacement for claude when i run out of tokens. Now im finding myself using glm more then kimi. Its funny that glm vs kimi, is like codex vs claude. Where glm and codex are better for backend and kimi and claude more for frontend. as kimi did a huge amount of claude distilation it seems to be somewhat based in data https://www.anthropic.com/news/detecting-and-preventing-distillation-attacks https://www.anthropic.com/news/detecting-and-preventing-dist...

whimblepop 7mo ago

That's pretty few, at least for the way I'm currently using LLMs. I have them do some Nix work (both debugging and coding) where accuracy and quality matters to me, so they're instructed to behave as I would when it comes to docs, always consulting certain docs and source code in a specific order. It's not unusual for them to chew through 200k - 600k tokens in a single session before they solve everything I want them to. That's what I currently think of when I think of "long horizon within a single context window". So I need them to not only not devolve into gibberish, but remain smart enough to be useful at contexts several times longer than that.

azuanrb 7mo ago

Have you compared it with using Claude Code as the harness? It performs much better than opencode for me.

jauntywundrkind 7mo ago

Chiming in to second this issue. It is wildly frustrating. I suspect that this isn't the model, but something that z.ai is doing with hosting it. At launch I was related to find glm-5.1 was stable even as the context window filled all the way up (~200k). Where-as glm-5, while it could still talk and think, but had forgotten the finer points of tool use to the point where it was making grevious errors as it went (burning gobs of tokens to fix duplicate code problems). However, real brutal changes happened sometimes in the last two or three months: the parent problem emerged and emerged hard, out of nowhere. Worse, for me, it seemed to be around 60k context windows, which was heinous: I was honestly a bit despondent that my z.ai subscription had become so effectively useless. That I could only work on small problems. Thankfully the coherency barrier raised signficiantly around three weeks go. It now seems to lose its mind and emits chaotic non-sentance gibberish around 100k for me. GLM-5 was already getting pretty shaky at this point, so I feel like I at least have some kind of parity. But at least glm-5 was speaking & thinking with real sentances, I could keep conversing with it somewhat, where-as glm-5.1 seems to go from perfectly level headed working fine to all of a sudden just total breakdown, hard switch, at such a predictable context window size. It seems so so probable to me that this isn't the model that's making this happen: it's the hosting. There's some KV cache issue, or they are trying to expand the context window in some way, or to switch from one serving pool of small context to a big context serving pool, or something infrastructure wise that falls flat and collapses. Seeing the window so clearly change from 200k to 60k to 100k is both hope, but also, misery. I've been leaving some breadcrumbs on Bluesky as I go. It's been brutal to see. Especially having tasted a working glm-5.1. I don't super want to pay API rates to someone else, but I fully expect this situation to not reproduce on other hosting, and may well spend the money to try and see. https://bsky.app/profile/jauntywk.bsky.social/post/3mhxep7ekg22r https://bsky.app/profile/jauntywk.bsky.social/post/3mhxep7ek... All such a shame because aside from totally going mad & speaking unpuncutaed gibberish, glm-5.1 is clearly very very good and I trust it enormously.

esseph 7mo ago
> "aside from totally going mad & speaking unpuncutaed gibberish [...] I trust it enormously." The bar is very low :(

cassianoleal 7mo ago

I've done some very long sessions on OpenCode with Dynamic Context Pruning. Highly recommend it. https://github.com/Opencode-DCP/opencode-dynamic-context-pruning https://github.com/Opencode-DCP/opencode-dynamic-context-pru...

HumanOstrich 7mo ago

I wonder if running the compaction in a degraded state produces a subpar summary to continue with.

gunalx 7mo ago
Indeed it does. Once i see degraded state i revert to last task and run a compact, before starting up again.

nkko 7mo ago

Yes, this is frustrating, but it doesn’t occur in CC. I run the conversation logs through an agent and opencode source, and it identified an issue in the reasoning implementation of opencode for Zai models. Consequently, I ceased my research and opted to use CC instead.