27 upvotes with no comments for a <15 minute old post, and likely ai written?
Doesn't sound like it however.
Same harness, same task set, same agent scaffold, the only thing I swapped was the executor. Not a proper benchmark, no clean tok/s numbers, this is a workflow read not a leaderboard.
glm-5.2 is the better model and it shows on anything that needs an actual decision. When the plan is loose or the step is ambiguous it figures out what I meant, and ling-3.0-flash just does something confident and wrong.
But most of my executor steps aren't decisions, they're mechanical edits and tool calls off a spec, and on those ling is the one I keep. It's 124b with about 5b active so it's quick, and more importantly it stays inside the tool schema over a long chain and it fixes a compiler error by fixing that error instead of refactoring around it. glm is smart enough to occasionally decide it knows better, which is exactly what I don't want in the executor.
So the split for me ended up being about how tight the plan is, not which model is smarter. Tight spec, ling does it cheaper and doesn't wander. Loose spec, you want the smarter one, or better, tighten the spec.
The catch for this sub specifically: ling is api only, no weights yet, so this is not a local setup and I know that's half of why you're here. I run it through openrouter. If it lands as weights the 5b active shape is going to be very friendly to the boxes people here actually own, but it hasn't, so I'm not going to pretend.
If you run a planner plus executor split locally, where do you draw the smart/cheap line, and does tightening the plan move it the way it did for me?
27 upvotes with no comments for a <15 minute old post, and likely ai written?
Doesn't sound like it however.
Violates Rule Two: Off-topic for LocalLLaMA Probably violates Rule Three: LLM-generated content without disclosure or justification given.