GLM-5.2 vs Kimi K2.7 Code: Planning Wins the Game Before Building Starts

GLM-5.2 vs Kimi K2.7 Code: Which Model Is Better at Planning vs Building?

TLDR: Kilo AI ran GLM-5.2 and Kimi K2.7 Code through a two-phase test: first planning, then building a backend feature flag service. GLM-5.2 won the planning phase with a score of 9.0 versus Kimi's 8.1, but both models produced nearly identical, fully working implementations from the same plan.

Summary: So here is the thing about coding agents that nobody really wants to say out loud: they have gotten pretty good at following instructions. Give any half-decent model a detailed enough spec, and it will build roughly what you asked for. The interesting question has shifted. It is no longer "can this model write code?" It is "can this model figure out what to write before it writes anything?"

That is exactly the framing Kilo AI brought to this comparison. They designed a two-phase test: each model independently plans a backend service, then both models build from the winning plan. The task was a feature flag service with gradual rollout support, specifically the kind where a user included in a 20% rollout stays included when that rollout grows to 40%. That determinism requirement without storing every user assignment in a database is where a weak plan falls apart. Both models identified a hash-based bucketing approach, which is the right call. That part was not the differentiator.

The differentiator was judgment on the edge cases the prompt deliberately left open. GLM-5.2 caught something Kimi missed entirely: when you cache a "no such flag" result to avoid database hits, you also need to invalidate that cache the moment the flag gets created. GLM called this out explicitly. Kimi's plan never raised the scenario, meaning whoever built from Kimi's plan would hit that bug and have no idea it was coming from a planning gap. GLM also kept environment variables out of the rollout hash, with an explanation: same user should land in the same bucket in staging and production unless you deliberately want otherwise. Kimi included the environment without explaining the trade-off. On API key storage, GLM chose a fast SHA-256 hash over bcrypt, reasoning that long random keys cannot realistically be brute-forced, so slow hashing adds latency to every authenticated request without meaningful security benefit. Kimi reached for bcrypt because that is the default password-storage answer, which it is, but API keys are not passwords.

The build phase delivered a satisfying result. Both models were given GLM's winning plan in a fresh session with nothing else. GLM passed all 15 independent verification checks. Kimi passed 14. More interesting, when both services were tested against the same 200 user IDs at a 35% rollout, they returned identical answers for every single user. The plan had locked in the math, and both models followed it. This is the practical payoff: a strong plan turns execution into a largely mechanical step. The model doing the building matters less when the decisions are already made in the spec.

There is also a cost story buried in these results that deserves attention. Kilo compared GLM-5.2's planning score of 9.0 against Claude Fable 5's score of 9.1 from an earlier test using the same prompt and rubric. Nearly identical quality. Claude Fable 5 costs around $10 per million input tokens and $50 per million output. GLM-5.2 costs $1.40 and $4.40. One tenth the price. And then there is the availability angle: on June 12, 2026, a US export-control order forced Anthropic to suspend Claude Fable 5 and Claude Mythos 5 for all users, not just affected regions. GLM-5.2 ships under MIT license with downloadable weights. You cannot recall weights someone already has. That is a qualitatively different availability guarantee than any closed model provider can offer today.

Key takeaways:

• The planning phase now separates capable models more than the build phase does, because modern models are competent executors but differ in how they resolve ambiguous requirements up front.
• GLM-5.2 consistently made explicit decisions with reasoning on edge cases, while Kimi K2.7 Code either defaulted to convention or left the hard calls to the implementer.
• Open-weight models like GLM-5.2 are closing the quality gap with frontier models at roughly one-tenth the cost, with the added benefit of downloadable weights that cannot be remotely disabled.

Why do I care: This changes how I think about agentic coding workflows in practice. If the planning phase drives most of the quality, then the smart architecture is a two-stage pipeline: use the best available model for planning, then hand the plan to something cheaper for execution. The fact that Kimi built successfully from GLM's plan, including following GLM's decisions in places where Kimi's own earlier plan had disagreed, shows this is already viable. What the Fable 5 suspension story adds is a real argument for open-weight models in production pipelines. I had been treating open-weight models as the budget option you reach for when cost is tight. After reading this, I think the framing should flip: closed models are the option you use when you need capabilities that open-weight models have not yet matched, and you accept the availability risk as the trade-off. For backend planning and generation at this quality level, that risk calculus no longer clearly favors closed models.

GLM-5.2 vs Kimi K2.7 Code: Which Model Is Better at Planning vs Building?