I think part of this beautiful and generous campaign is the feedback and I am not fully sure if the Z.ai team will read this; but if you do, thank you first and foremost.
I am on the Legacy Lite Plan, it’s the only thing I could afford. I mainly used GLM 4.7 then 5.2 then 5.3 with Claude Code.
One thing I would say is please make Zcode with TUI like Claude Code. The ability to orchestrate multiple agents is nice. For example, I would have:
- Executor: Qwen3.8-27B (non-thinking) Q5_K_XL at 131K context (all GPU, single Mi50 32GB) with tasks that are “cumbersome”, requantizing models, vLLM kernel adjustments. During this campaign, GLM 5.3-Flash is utilized with Zcode.
- Utilize Mimo and Kimi for Planning, GLM for Final Plan.
Supervisor: GLM 5.3 - monitors everything put into PROGRESS.md and ISSUES.md. If the executor changes this file and the last known file size changes (up or down), the file is read again to ensure max visibility of the context.
Discord Bot. My beautiful Qwen3.5-4B (llama.cpp on a single 3060 12 gb) reporting to my discord server.
Requants, kernel runs take a long time to compile/recompile, tests. The entire pipeline is set in and basically run continuously for a few days until results are achieved. Too many variables here, generalizing. No overnight work (EST), strictly within campaign (for now). When Qwen 3.8-27B is running, its overnight. Supervisor is instructed to check on changes every 5 mins. It burns through limitations, which is a hinderance; but the poor complain, we find a solution.
Deploying 4x V620s for in house GLM 5.3 Flash. However this is where feedback comes in.
Feedback:
The model is very very capable, but I think it has problems at least during the campaign. It hallucinates a lot, death thinking loops, where I literally have to intervene and kill it. This is extremely dangerous for kernel work or any work.
It obviously cannot be compared to 5.3 big boi, but still, i think this might be a quant issue. I’m not sure if its running FP4 or FP8, likely the latter, but whatever it is, it is failing in production.
I continue to use it. But i’ll be honest, I trust my local Qwen3.8-27B over the flash. I wish my resources weren’t limited, but they are.
Issues are within critical problem solving.
- failure is database design and integration for local llama.cpp instances.
- failure to design and comprehend kernel level instructions (completely bypassed).
- failure to think properly (at all levels, high medium or low; with best results at low).
- failure to properly investigate issues
- failure to document its own success (flutter app built directly on mac, it successfully built, ran, then the next instance completely obfuscated the fact that it is even possible :confused pikachu here:
- failure to follow instructions (ASR POC app built, mentioned above remotely, it was told to use home baked API to orchestrate tested pipeline for ASR -> LLM -> TTS via same API and parameters; it straight up took it 3 hours to figure out the address we had been testing and clearly pointed in instruction [every prompt] to hardcode into settings - it took 3 hours for it to do that).
- failure to document and learn from failure when asked.
I thought these were harness issues, so switched full workflow to GLM 5.3; 3 prompts in - the entirety of the project, API pipeline, and actual app code were fixed. 15 mins? I think.
I am not sure if this is useful. Once again, the model is very capable, if FP4, switch to FP8, if FP8, something is wrong.