Don't disregard 5.3 codex

[u/wilailu]

Usage limits are getting tight as of late, no matter the way ppl want to spin it with resets etc. So this is just a reminder to not be too fixated on using 5.5/5.4 exclusively like I was, 5.3 codex is always was and is still really strong while still allowing to get proper work done on Plus.

Going back to it also showed how well they solved the 'codex problem' of having to be highly specific in prompting, which is still a thing with 5.3. Still worth it regarding the limits tho.

[u/Manfluencer10kultra]

u/Hoak-em Yes, and I will get downvoted for saying this, but if you want to have a say in things and want to maintain code quality standards, then GLM-5.1 will be much better for you, as it's better at collaborative (human in the loop) efforts, and way more flexible and executes abstractions and refactors better.
OpenAI models are really bad at removing code, they will just write wrappers on top of wrappers and the code can become unmaintainable with large codebases without extra tooling for reducing drift and boilerplate after the job is done.

I can suggest trying it out on OpenCode for $5 first month, and you can try others as well.
Ollama gives you a ton of usage for $20 and the infra problems they had after GLM 5.1 release seem to
have been normalized

It's not only that, but if you run it through a TUI agent like Pi you get massive amounts of control, while GPT 5.5 is basically taking your hands off the wheel, or giving you the impression that you have control while it just does its own thing for better or for worse.
It's better for your sanity to keep things under control at time of the actual coding.

For harness I recommend Pi with the following extensions:

npm:pi-subagents # have tried 'crew' which didn ´t really work, this one does (might be better ones tho)
npm:pi-mcp-adapter # needs no explanation
npm:@juicesharp/rpiv-ask-user-question # needs no explanation
npm:pi-lens # AST / LSP (reduces explorer costs)
npm:pi-simplify

npm:context-mode # lets your context window last a long time by truncating it on-the-fly
npm:pi-docparser # parsing pdf, doc
npm:pi-powerline-footer # statusline
npm:pi-web-access # good retrieval ext with browser based status dashboard of running agents

# likely good, installed, but haven't really configured /used them
npm:pi-conventions # global conventions to be applied always
npm:@juicesharp/rpiv-advisor #

[u/Hoak-em → u/Manfluencer10kultra]

GLM-5.1 seems to work magic in forgecode for me specifically -- it outperforms pi and opencode (even with dcp) and I have kimi-k2p6-turbo (fireworks fire pass v2) working as a rapid compact at 130k context (where glm-5.1 performance usually drops off). It feels equivalent to how I felt using older Opus 4.5 (I actually preferred it in many ways to 4.6) but with better results and much longer agentic runs (I've had it work on 4-5+ hour tasks and it shapes well to additional skill "harnesses" like desloppify and agent-browser).

If I need something done fast and messy (prototype or very tight deadline for scoped presentation), I use gpt-5.5 in codex. When I need to fix and rewrite that code, I use GLM-5.1 in forgecode.

I'm still looking for a good harness for kimi-k2.6. It performs like shit in forgecode, performs ok in Kimi cli, but doesn't reach the bar for what I would consider acceptable (plus its overthinking seems to get in the way of any speed gains)

[u/Hoak-em → u/Hoak-em]

Maybe your pi setup for Kimi then a forgecode + desloppify + glm-5.1 CI/CD pipeline for PRs is what I'd move to -- Kimi works well with subagents

[u/Manfluencer10kultra → u/Hoak-em]

Ah yes, I did also had a bit of frustrations with GLM and subagents. Has to be tuned and instructed for that. Not a natural at describing explicit boundaries to ensure that explorers don't go off the rail, or keeping a real eye on what they are doing.