DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1: Three LLMs Tested on Long-Context Vibe Coding

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

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

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

That’s where it derails. Kimi starts to invent classes that don’t exist. He offers me`AnonymizedObjectMapper`— a fictitious class. He confuses`ReadmeYmlAnonymizer` et CodebaseYmlAnonymizer. He suggests that I import`com.fasterxml.jackson.anonymize.*`— a package that never existed.

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

__ It wasn’t a bug. It was a gradual dissolution of coherence. As if each token added to the context diluted a little more the memory of the first 30,000. </think>

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 dilutes mechanically beyond 60K tokens. Each token "sees" the distant context less and less well — and starts filling the gaps with noise.

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

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

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

But latency is a problem. DSA reasoning phases are heavier than pure MLA — the indexer must rescan the history at each step. A response that took 8 seconds with Kimi takes 15 with GLM. In a 30‑message session, it’s felt.

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

I held three sessions with GLM. It is better than Kimi, without a doubt. But three sessions of manual correction on naming details are exhausting.

Two levels of compression, two attention granularities:

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

And most importantly, the technical report (Figure 9) states: "_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, all compiles. Session 4 : adding the`SnapshotManager`with tree view, file collection, AsciiDoc rendering per file. 279 lines, zero error. Session 7: debug of the`renderFileSection()`who had to handle four different types of anonymisers without resolution ambiguity. Resolved in three messages.

The latency is higher than Kimi — about 10-12 seconds per response in thinking mode. But the correction rate is almost zero. I don’t spend my time fixing the agent’s errors. I code with him.

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

The agent proposes a three-phase plan:

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`which must be unified during the 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’s 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 exactly matches my needs: 30K of EAGER + 70K of 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 does not measure the latency of a response. He measures 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.