DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1 : Three LLMs Put to the Test of Long-Context Vibe Coding

First session with Kimi. Task: implement the method`resolveActiveKey()in`codebase.kt— an API key resolution function with CLI fallback. Context is at 30K tokens, Kimi reasons quickly, produces clean code with key expiration management.

The code compiles. The 7 test cases pass. I am optimistic.

Second session. Context climbs to ~90K tokens with exchanges. I ask Kimi to add an AsciiDoc snapshot mechanism that anonymizes secrets before writing.

This is where it goes wrong. Kimi starts inventing classes that don’t exist. He proposes`AnonymizedObjectMapper`— a fictitious class. He confuses`ReadmeYmlAnonymizer` et CodebaseYmlAnonymizer. He suggests importing`com.fasterxml.jackson.anonymize.*`— a package that never existed.

Worse: in its reflection phase, I see it building reasoning on false premises. It "remembers" that`GitConfig`has a field`anonymizedToken`— no, it’s`resolvedToken(). It attributes to`SiteYmlAnonymizer`a method`maskSupabaseCredentials()— which does not exist.

_ This wasn’t a bug. It was a progressive dissolution of coherence. As if each token added to the context further diluted the memory of the first 30,000. _

I stop Kimi after two sessions. The diagnosis is clear: MLA compresses the KV cache well, but without a fine-grained sparse selection mechanism, attention mechanically dilutes beyond 60K tokens. Each token "sees" the distant context less and less — and begins to fill the gaps with noise.

The difference is fundamental. Where Kimi compresses history into a single latent space (and progressively loses the ability to discriminate relevant information), GLM grafts a post-training indexer that performs explicit sparse selection.

The technical report states explicitly: DSA is "lossless by construction" — unlike alternatives like SWA (pattern search), Gated DeltaNet, or SimpleGDN which lose up to 5.69 pts on RULER@128K.

GLM-5.1 holds the distance better. In session 11 (~60K tokens), it remains coherent. It produces a`SnapshotManager`that is functional with correct management of the four anonymizers.

But latency is an issue. DSA reflection phases are heavier than pure MLA — the indexer must rescan history at each step. A response that took 8 seconds with Kimi takes 15 with GLM. Over a 30-message session, it’s noticeable.

And then there are the subtle errors. GLM doesn’t rave like Kimi — but it makes naming errors. It calls`toAnonymizedYaml()the method that should be called`anonymize(). It reverses`loadReadmeConfiguration()` et loadCodebaseConfiguration()`in the`renderFileSection(). These aren’t hallucinations, they are surface confusions — but in production, a surface confusion can break a build.

I lasted three sessions with GLM. It is undeniably better than Kimi. But three sessions of manual correction on naming details is wearing.

Two levels of compression, two granularities of attention:

Result: at 1M tokens, DeepSeek-V4-Pro consumes only27% of inference FLOPs et 10% of KV cache sizecompared to DeepSeek-V3.2, the previous model.

And above all, the technical report (Figure 9) announces: "Retrieval performance remains highly stable within a 128K context window."

I spent eight sessions with DeepSeek-V4-Pro on`codebase-gradle`. Eight sessions without a single hallucination, without a single invented class, without a single naming confusion.

Session 1: implementation of`CodebaseYmlConfig` et CodebaseYmlAnonymizer. 350 lines of Kotlin, inline tests, everything compiles. Session 4: addition of the`SnapshotManager`with tree view, file collection, AsciiDoc rendering per file. 279 lines, zero errors. Session 7: debug of the`renderFileSection()`which had to handle four different types of anonymizers without resolution ambiguity. Resolved in three messages.

Latency is higher than Kimi — about 10-12 seconds per response in thinking mode. But the correction rate is nearly zero. I don’t spend my time repairing the agent’s errors. I code with it.

At session 8, the cumulative context exceeds 100K tokens. I ask for a heavy refactoring: extract the four inline verification tasks from`build.gradle.kts`to JUnit5 test files in`buildSrc/src/test/`.

The agent proposes a plan in three phases:

The plan is correct. The execution is clean. It even identifies an edge case I had missed: duplicate Jackson dependencies between`buildscript {}` et `buildSrc/build.gradle.kts`that must be unified during migration.

100K tokens of context, and the agent remembers that`CodebaseYmlAnonymizer.TOKEN_MASK`is`"*"`, that`GitConfig.resolvedToken()is an extension function defined in`readme.kt, and that`SnapshotManager.PRUNED_DIRS`excludes`build`, .gradle et .git.

That is the difference.

Assisted software development is an extreme use case for long-context attention. You need: - Local precision (what does this class inherit from? where is this method defined?) →CSA - Global vision (why does this module exist? how do the four anonymizers interact?) →HCA

Kimi with MLA alone handles local precision but loses global vision beyond 60K. GLM with DSA improves global vision but remains single-level. DeepSeek combines both explicitly.

My governance system loads ~30K tokens of rules and backlog at startup. With a stable window up to 128K, DeepSeek has ~100K tokens of margin for session exchanges. This is 3 to 4 times more than what Kimi can handle without degradation.

_ The 128K window of perfect stability corresponds exactly to my needs: 30K EAGER + 70K exchanges = a productive session of 20-30 messages without ever leaving the green zone. _

Yes, DeepSeek-V4-Pro is slower than Kimi (11s vs 8s). But the total time for a task is much lower because I don’t spend 20 minutes correcting the agent’s hallucinations.

The developer doesn’t measure response latency. They measure the time between "I ask the question" and "the code is in my repo and it works". On this metric, DeepSeek-V4-Pro is the fastest of the three.