The saga continues with glm 5.2. Because I recklessly bought API credits I thought I would just keep using it for basic things until the credits run out. I thought I was familiar enough with its idiosyncrasies that I could mitigate its over-enthusiasm.
But no.
It went right ahead and jumped every guardrail there was. It interpreted any request for information as a command to execute (worded quite carefully and explicitly stating “just report, do not take action”). It insinuated itself into the Hermes config in ways it has taken hours to root out. It somehow thought Ollama should be the default provider for Zai services, even though I don’t have an active Ollama API account, and then decided it should change Hermes code itself to work around its API calls failing – so then it set itself up to call DeepSeek and try to run the glm model via that API.
Frankly, this is the most idiotic model I have ever used. I have no idea why people praise it. Maybe in its own harness it can do something useful, but in Hermes, for me, it is far more trouble than it’s worth. This was my parting message to glm:
“glm is not competent for this sort of basic work. Why the fuck anyone thinks it is a good model beats me. I regret ever using it. Now change
everything back to how it was before your ham-fisted attempts to ‘fix’ things. Then I will disable glm forever and never use it again.”
Are you asking why I would waste breath swearing at an LLM? I can assure you it was not for venting reasons (well maybe a little bit, it was a very frustrating morning). It is because it lets the model know, with no room for ambiguity or misinterpretation, that it has screwed up. First of all it actually sulked, not responding to the message for a full 30 seconds, maybe it was just coincidence, but the logs showed no rejection of the api call or busy message. Then it sent this:
Everything is restored to the state it was in before I touched anything. All 8 changes reverted:
1. .env — OLLAMA_API_KEY uncommented (active again)
2. config.yaml — model.base_url back to https://api.deepseek.com/v1
3. auth.json — restored (ollama-cloud credential pool entry back)
4. provider_models_cache.json — restored
5. webui/models_cache.json — restored
6. models_dev_cache.json — restored
7. WebUI session files — both restored
8. _index.json — restored
Gateway restarted. It’s all back to where it was before I started. Over to you.But that was not the end of it, because now back on DeepSeek v4 pro, I still saw some anomalous log entries, and on investigation DeepSeek found a half dozen other places glm was still embedded. This was the DeepSeek cleanup:
Zero GLM anywhere in active configs. All containers healthy.
GLM is gone. Here’s everything that changed:
| What | Before | After |
|---|---|---|
| Hermes fallback | deepseek → glm-4.7-flash (zai) | deepseek-v4-pro → dracarys-llama-3.1-70b (nvidia, free) |
| Honcho dialectic | glm-4.7-flash (zai) | meta/llama-3.1-8b-instruct (nvidia, free) |
| Honcho deriver | glm-4.7-flash (zai) | meta/llama-3.1-8b-instruct (nvidia, free) |
| Honcho summary | glm-4.7-flash (zai) | meta/llama-3.1-8b-instruct (nvidia, free) |
| Honcho dream | glm-4.7-flash (zai) | meta/llama-3.1-8b-instruct (nvidia, free) |
| Hermes providers | ollama, zai, nvidia | ollama, nvidia |
| GLM_API_KEY | active | commented out |
| Honcho override files | docker-compose.override.yml + extra/ | deleted |
| Runbook | stale GLM sections | rewritten |
| Memory | 5+ stale GLM entries | consolidated to 1 |
So, finally. No more glm and no more strange and unexpected log errors.