Coding Wars 2.0: The Definitive Comparison of Kimi K2.6, GLM-5.1, and Claude Opus 4.7

We’re back for Coding Wars 2.0.

The public benchmark gap between Kimi K2.6 and GLM-5.1 on SWE-Bench Pro is 0.2 points.

Anthropic’s current flagship, Claude Opus 4.7, shipped on April 16, 2026. That’s close enough, and recent enough, that “which model is best?” stops being a useful question.

Of the open source models, Kimi K2.6 is the better first test when the job is visual, frontend-heavy, or built around parallel agent swarms and you have the hosted setup or compute to use it well. GLM-5.1 is the better first test when you want open weights, a more controlled deployment path, and a serious long-running coding agent. Claude Opus 4.7 is the premium escalation lane for high-risk review, architecture, and hard debugging where a bad answer costs more than the token bill.

If you’re coming from older Opus 4.6 comparisons, the current Anthropic version is Opus 4.7.

Note: I’ve actually switched back to 4.6 from 4.7 in some of my own flows because I didn’t see enough lift to justify the 1.3-1.4x token premium.

The Short Version

If the job is…	Start with…	Why
Frontend build, design-to-code, visual product work	Kimi K2.6	Best fit when you have hosted access or enough compute for its multimodal and interface-generation strengths
Large parallel agent experiment	Kimi K2.6	Best fit if you actually have the infra to run swarm-style workloads
Long-running coding agent	GLM-5.1	Built around sustained agentic engineering and a more controlled deployment path
Privacy-sensitive codebase	GLM-5.1	MIT license, open weights, and local serving support
Claude Code-native agent teams	Opus 4.7	Best fit if you already live in Claude Code and Anthropic’s agent workflow
Architecture review or high-risk code review	Opus 4.7	You pay for stronger judgment when a wrong answer is expensive
Routine refactors, test scaffolding, boilerplate	GLM-5.1 or Kimi K2.6	Don’t burn Opus money formatting code or writing first-pass tests

Why This Comparison Matters Now

The first “AI Coding Model Wars” post worked because February 2026 had a clean story: proprietary models still had the polish, open models were closing the gap fast, and the benchmark spread was getting too tight for a single-model worldview.

That story is messier now, but more useful. The question isn’t which company wins. It’s which model you actually put in the workflow for a given task. Anthropic also moved from Opus 4.6 to Opus 4.7 on April 16, 2026, so any comparison still anchored on 4.6 is already one version behind.

Release Timing and Runtime Modes

These models are close enough that release timing and how you run them matter more than they used to.

Model	Public release date	How people usually run it	What that implies
Kimi K2.6	April 20, 2026	Kimi.com, Kimi App, API, Kimi Code; open deployment via vLLM, SGLang, or KTransformers	Open model, but usually experienced through Moonshot’s own stack or custom inference infra rather than as a casual laptop model
GLM-5.1	April 7, 2026	Z.ai API or local deployment via SGLang, vLLM, xLLM, Transformers, or KTransformers; tuned for Claude Code and OpenClaw workflows	The most obvious open-weight backend in this set for long-running coding agents
Claude Opus 4.7	April 16, 2026	Claude products, Anthropic API, Amazon Bedrock, Google Cloud Vertex AI, or Microsoft Foundry	Managed premium lane. You buy workflow and availability, not weights

That split matters. Kimi and GLM can turn into infra work. Opus is a service you buy. Similar benchmark range, different ownership model.

One trust caveat: self-hosting and API use are different bets. Kimi’s API terms are looser on using inputs and outputs for service optimization. Z.ai says API content is processed in real time and not stored. If the code matters, read the terms or self-host.

Benchmark Snapshot

As of April 23, 2026, the public model pages put Kimi K2.6 and GLM-5.1 close enough that the benchmark table should not be the only thing making the decision.

Model	Access / license	Deployment / context	Published pricing	Selected coding signals
Kimi K2.6	Open weights, Modified MIT	~256K context	$0.95 input cache miss, $0.16 cached input, $4 output per 1M tokens	SWE-Bench Pro 58.6, SWE-Bench Verified 80.2, Terminal-Bench 2.0 66.7
GLM-5.1	Open weights, MIT	Local serving via SGLang, vLLM, xLLM, Transformers, KTransformers	$1.40 input, $0.26 cached input, $4.40 output per 1M tokens	SWE-Bench Pro 58.4, Terminal-Bench 2.0 63.5, CyberGym 68.7
Claude Opus 4.7	Proprietary	1M context window	$5 input, $25 output per 1M tokens	Anthropic positions it as stronger for advanced software engineering; Cursor reports a 13% lift on its own 93-task coding benchmark

Sources: Kimi K2.6 model card, Kimi K2.6 pricing, GLM-5.1 model card, GLM-5.1 release notes, Z.ai pricing, Anthropic Opus 4.7 release.

Don’t over-read the 58.6 vs. 58.4 gap on SWE-Bench Pro. That’s not a product strategy. It’s basically noise until you run both models against your own repo, your own prompts, and your own definition of “good enough.”

Vendor benchmark tables don’t always line up perfectly either. Different harnesses, settings, tool access, effort levels, and reporting choices move the number. That doesn’t make the numbers useless. It means they’re a starting filter, not the final answer.

Kimi K2.6: The Swarm and Design-to-Code Bet

Kimi K2.6 matters most if your coding work touches interfaces, visual inputs, or large parallel agent runs.

On paper, Kimi is a 1T MoE model with 32B active parameters, a roughly 256K context window, a 400M vision encoder, and image and video input. Moonshot’s own pages bounce between 256K and 262,144 tokens, so I would just treat it as “about 256K.” The part that matters is simpler: this model is built for multimodal agent work. Build the UI, read the screenshot, split up the work, keep the run moving.

The standout claim is the agent swarm system: 300 sub-agents and 4,000 coordinated steps. I wouldn’t build a production workflow around that number just because it’s in a model card. But it does tell you what Moonshot is optimizing for: messy, multi-surface jobs where the model needs to build the interface, read the screenshot, coordinate subtasks, and keep the run moving.

That makes Kimi K2.6 a better first test for frontend and design-to-code work than a backend-only benchmark would suggest.

Where I would be cautious: using Kimi as the default for backend-heavy refactors before testing it on your own codebase. The swarm story is attractive, but swarm coordination can hide failure. You get a lot of motion, a lot of files touched, and a polished-looking result. Then the real review starts.

For Kimi, I would measure edit quality hard:

• Did it make fewer changes than necessary?
• Did it preserve existing conventions?
• Did it produce tests that catch real failure modes?
• Did the output look better than it behaved?

That last one is the risk with design-capable models. A good-looking interface can make weak system boundaries feel more complete than they are. Ask anyone who’s reviewed a slick demo with a sad backend behind it.

GLM-5.1: The Long-Horizon Agentic Engineering Bet

GLM-5.1 is less flashy than Kimi, but it may be more useful for teams. Z.ai positions it for longer coding runs: break the problem down, run experiments, read the results, find blockers, revise the plan, and keep going for hundreds of rounds and thousands of tool calls.

That’s exactly where most AI coding workflows break. A lot of models look good for the first 20 minutes, then fall apart once the easy path fails.

GLM-5.1 also has a setup Kimi and Opus don’t share in the same way. Z.ai lists local serving support through SGLang, vLLM, xLLM, Transformers, and KTransformers. The model is MIT licensed. The API pricing is materially lower than Opus 4.7: $1.40 input and $4.40 output per million tokens, compared with Opus at $5 and $25. That’s about 3.6x cheaper on input and 5.7x cheaper on output before caching or batch discounts.

That gives GLM-5.1 three obvious lanes:

• privacy-sensitive codebases where cloud proprietary models are a non-starter
• high-volume routine coding where Opus pricing is wasteful
• long-running local or semi-local agents where control matters as much as raw score

If I were setting this up for a team, GLM-5.1 is the open model I’d test first for backend work. Not because it “wins” every benchmark. Because it gives you a serious coding model with better control over where and how you run it.

But here’s the tradeoff. Local serving a large model isn’t free just because the weights are available. You’re swapping token bills for infra, latency, deployment, monitoring, and maintenance. That’s a good trade for some teams and a terrible trade for others.

If you’re a solo developer, the managed API is probably the pragmatic path. If you’re a regulated team or a platform group with real volume, the local deployment option is the point.

Claude Opus 4.7: The Expensive Escalation Lane

Anthropic’s current Claude comparison target is Opus 4.7, released on April 16, 2026.

The context-window story is cleaner than some third-party leaderboard summaries make it look. Anthropic’s current public Opus page markets Opus 4.7 with a 1M context window. Opus 4.6 also had 1M, but Anthropic introduced it there as a beta capability. So if you’re comparing the models today, the right mental model is simple: Opus 4.7 is the current 1M-context Claude flagship.

The pricing didn’t change: $5 input and $25 output per million tokens. The capability story did. Anthropic positions Opus 4.7 as stronger on advanced software engineering than Opus 4.6. The release post also includes Cursor’s report of a 13% lift on its own 93-task coding benchmark, and the current Opus page leans on partner and customer reports for the longer-run follow-through, fewer tool errors, and stronger code-review claims.

Opus 4.7 is still the premium lane: closed, expensive, and wasted on routine scaffolding.

Anthropic’s advantage is the surrounding workflow: Claude Code, agent teams, effort controls, compaction, and long-context behavior. For a lot of real engineering work, that matters more than one benchmark line.

The place Opus earns its cost is expensive judgment:

• architecture decisions
• unfamiliar codebase exploration
• multi-file refactors with subtle system boundaries
• security-sensitive review
• failure analysis where the obvious fix already failed
• final review before a risky merge

This is the line I use in my own work: cheap models can draft the change; expensive models should review the risk.

That doesn’t mean Opus should always be the reviewer. It means the premium lane should be reserved for decisions where the model’s extra reasoning has somewhere to pay for itself. If the task is “write five unit tests for this validation function,” Opus is overkill. If the task is “review this migration for data loss, rollback gaps, and cross-service contract breakage,” now the price starts to make sense.

The earlier AI Coding Model Wars post was anchored on Opus 4.6. For an actual buying decision in late April 2026, use Opus 4.7 as the Claude comparison point.

The Decision Framework

Here’s the cleaner way to choose.

Workflow	First model to test	Escalation path	What to watch
UI generation from visual input	Kimi K2.6	Opus if reasoning fails	Pretty output hiding weak state/data logic
Frontend component build	Kimi K2.6	GLM-5.1 for refactor pass, Opus for review	CSS churn, accessibility gaps, over-built abstractions
Backend bug fix	GLM-5.1	Opus for hard root-cause analysis	Surface fix without understanding failure path
Test generation	GLM-5.1	Opus for high-risk domains	Tests that assert implementation instead of behavior
Local/private coding agent	GLM-5.1	None, unless policy allows cloud escalation	Infrastructure cost and context-management discipline
Large swarm experiment	Kimi K2.6	Opus for architectural review	Parallel agents stepping on each other’s assumptions
Architecture review	Opus 4.7	Human review	Confident but under-sourced tradeoffs
Code review before merge	Opus for risky changes, GLM for routine	Human reviewer	False positives and missed system-level issues

The better question is where each model fails, and whether that failure is cheap. Kimi failing on a visual prototype is usually cheap. Kimi failing on a payment migration isn’t. GLM failing on a routine refactor is manageable if tests exist. Opus failing is expensive in a different way because you paid more, trusted more, and probably gave it the harder task.

The Workflow Test I Would Run

Don’t pick from benchmark tables alone. Build a small internal eval.

Five tasks is enough to start:

1. A real bug fix from your repo history.
2. A test-generation task where you already know the edge cases.
3. A refactor with existing conventions the model must preserve.
4. A UI task with a screenshot or visual requirement.
5. A code review task on a risky diff.

Run Kimi K2.6, GLM-5.1, and Opus against the same task packet. Keep it in a markdown file so you can re-run it when the next version drops, because it will:

• the same repo context
• the same constraints
• the same success criteria
• the same time or token budget
• the same review rubric

Score the result on five things:

Score	What it measures
Correctness	Did the change actually work?
Edit discipline	Did it touch the smallest reasonable surface area?
Convention fit	Did it follow the codebase’s existing patterns?
Test quality	Did tests catch behavior or just mirror the implementation?
Review burden	How much human cleanup did it need?

The review burden score is the one people skip. It’s also the one that matters.

A model that finishes in 90 seconds but leaves you with 45 minutes of cleanup didn’t save you 45 minutes. It just moved the work into review, where the mistakes are harder to notice because the code already looks finished.

This is why I keep coming back to routing. The best teams won’t standardize on one model. They’ll standardize on an evaluation loop.

My Recommendation

If I were choosing today:

Use Kimi K2.6 first for visual, frontend, and swarm-heavy workflows. Its multimodal and agent-swarm direction is the differentiator. Make it prove itself on backend work before trusting it broadly.

Use GLM-5.1 first for open, local, privacy-sensitive, and long-running coding-agent workflows. It’s the model I’d pressure test hardest for routine engineering work where cost and control matter.

Use Opus 4.7 as the premium escalation lane. Architecture, hard debugging, high-risk review, weird cross-file reasoning. Don’t waste it on boilerplate. That’s how you end up with a very expensive autocomplete.

Pick the cheapest model that handles the task. Escalate when the mistake would be expensive. Measure review burden. Keep the routing rules somewhere explicit instead of scattered through human habit.

I’m also testing what local self-hosting actually looks like on an M1 Air with 16 GB, because a lot of “just run it locally” advice gets vague fast once the hardware is real.

That’s the kind of thing benchmark tables miss.

---

If you want the broader model-routing architecture, read LLM Gateway Architecture and Multi-Model Routing. For the original comparison that led to this update, read The AI Coding Model Wars.

I write about AI engineering, coding agents, and the boring workflow layer that makes the models useful. Subscribe here if that’s your thing.

---

Sources Checked

• Kimi K2.6 model card - Moonshot AI on Hugging Face
• Kimi research index - Moonshot AI
• Kimi K2.6 tech blog - Moonshot AI
• Kimi K2.6 pricing - Kimi
• Kimi Open Platform Service Agreement
• GLM-5.1 model card - Z.ai on Hugging Face
• GLM-5.1 release notes - Z.ai
• GLM-5.1 overview - Z.ai
• Z.ai terms of use
• Z.ai privacy policy / DPA
• Z.ai pricing docs
• Claude Opus 4.7 release - Anthropic
• Claude Opus page - Anthropic