DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1: Drie LLMs onderworpen aan de test van lange‑context vibe coding
Gepubliceerd op 28 April 2026
- Context: geen testbank, een bouwplaats
- Mijn testomgeving
- Het evaluatierooster
- Ronde 1 : Kimi K2.6 — De valse start
- Round 2 : GLM-5.1 — De Eerzame Strijder
- Ronde 3 : DeepSeek-V4-Pro — De Oorlogsmachine
- De face-to-face: vergelijkende metrieken
- Waarom DeepSeek-V4-Pro wint in softwareontwikkeling
- Geleerde lessen : Hoe kies je jouw LLM voor Vibe Coding
- En wat is er met de Agent Governance in dit alles?
- Technische bronnen
- Conclusie: De keuze van de ambachtsman
De oorlog van de LLMs speelt zich ook af in de terminal van een ontwikkelaar. Niet op steriele academische benchmarks. In het echte leven: een prompt van 30 000 tokens, een agent‑governance in AsciiDoc, Gradle‑Kotlin‑DSL‑plugins om te debuggen en sessies die drie weken achter elkaar plaatsvinden. Ik heb voor jou DeepSeek-V4-Pro, Kimi K2.6 en GLM-5.1 getest. Hier is het vonnis, ondersteund door technische bewijzen.
Context: geen testbank, een bouwplaats
Drie weken geleden werkte ik aan`codebase-gradle`, Mijn meta-build systeem dat de YAML-configuratie van vier projecten centraliseert: een README PlantUML-generator, een AsciiDoc-slidesbouwer, een statische JBake-site en een LLM-chatbot. De Opencode-agent, bestuurd door mijn methodologie voor agentenbestanden in AsciiDoc, laadde ~30K tokens EAGER-context bij elke sessiestart — absolute regels, backlog, geschiedenis van de laatste 10 sessies.
Het is op dit terrein dat ik drie modellen heb geconfronteerd:
-
Kimi K2.6(Moonshot AI, 1T params / 32B geactiveerd, 256K maximale context, MLA) - GLM-5.1(Zhipu AI/Tsinghua, 744B params / DSA, 200K context max) - DeepSeek-V4-Pro(DeepSeek, 1.6T params / 49B actief, 1M maximale context, CSA+HCA)
Allemaal geserveerd via Ollama op een cloudserver, allemaal in denkmodus (fase van reflectie geactiveerd). De uitdaging: correcte code produceren, de consistentie behouden tijdens lange sessies, en niet hallucineren wanneer de context de 80K tokens overschrijdt.
Mijn testomgeving
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 220
title Testomgeving — Sessies Opencode × 3 LLMs
left to right direction
package "🖥️ Terminal Ontwikkelaar" #E8F5E9 {
rectangle "AGENT.adoc\n(regels, backlog)" as AG
rectangle "PROMPT_REPRISE\n(missie)" as PR
rectangle "INDEX.adoc\n(roadmap)" as IDX
}
package "☁️ Ollama Cloud" #BBDEFB {
rectangle "DeepSeek-V4-Pro\n1.6T / CSA+HCA" as DV4
rectangle "Kimi K2.6\n1T / MLA" as KIMI
rectangle "GLM-5.1\n744B / MLA+DSA" as GLMG
}
package "⚙️ Codebase Gradle" #FFF9C4 {
folder "buildSrc/" {
file "codebase.kt"
file "readme.kt"
file "site.kt"
file "slider.kt"
file "snapshot.kt"
}
file "build.gradle.kts\n(947 regels)"
file "embeds.yml"
}
AG --> DV4 : Sessies 1-8 ✅
AG --> KIMI : Sessies 9-10 ⚠️
AG --> GLMG : Sessies 11-13 ⚠️
DV4 --> "Codebase" : "TDD, refactoring,\nsnapshot"
KIMI --> "Codebase" : "Degradatie\nvanaf 60K tokens"
note bottom of GLMG
Beter dan Kimi
maar latentie +
DSA minder robuust
dan CSA+HCA
end note
@enduml
Elke sessie begon met ongeveer 30K tokens EAGER-context:`AGENT.adoc`(287 regels),PROMPT_REPRISE.adoc(51 regels),.agents/INDEX.adoc(218 regels),LAZY_EAGER_ESSENTIALS.adoc(50 regels). De context groeide snel met de uitwisselingen — een typische sessie van 10 berichten voegde 15-20K tokens toe aan de cumulatieve prompt.
Het evaluatierooster
Ik heb elk model geëvalueerd op vier kritieke assen voor geassisteerde softwareontwikkeling:
| as | concreet criterium |
|---|---|
Coherentie lange context |
Herinnert de agent zich de afspraken die 40 berichten geleden zijn besloten? |
Kwaliteit van de geproduceerde code |
Compileert de code in één keer? Houdt hij zich aan de bestaande patronen? |
architectonische redenering |
Begrijpt de agent de relaties tussen modules zonder dat ik het hem opnieuw moet uitleggen? |
Weerstand tegen hallucinaties |
Vanaf hoeveel tokens begint de agent niet‑bestaande API’s of klassen te verzinnen? |
En een synthetische huisgemaakte metriek: hetherstelcoëfficiënt(hoeveel tijd ik besteed aan het corrigeren van de agent in plaats van met hem te coderen).
Ronde 1 : Kimi K2.6 — De valse start
Kimi K2.6 was mijn eerste keuze. Zijn benchmarks op SWE-Bench Verified (80.2) en Terminal-Bench 2.0 (66.7) zijn uitstekend. Zijn MLA-architectuur belooft een goede efficiëntie bij lange sequenties.
Sessie 9: de opleving
Eerste sessie met Kimi. Taak: de methode implementeren`resolveActiveKey()in`codebase.kt— een functie voor API-sleuteloplossing met CLI-fallback. De context is 30K tokens, Kimi denkt snel, produceert schone code met sleutelverloopbeheer.
fun resolveActiveKey(
cfg: CodebaseConfiguration,
logger: Logger,
cliProvider: String? = null,
cliAccount: String? = null,
cliKey: String? = null
): NamedApiKey? {
// Résolution provider → compte → clé avec CLI override
// Kimi a parfaitement compris la chaîne de priorité
}De code compileert. De 7 testgevallen slagen. Ik ben optimistisch.
Sessie 10 : de stille zinken
Tweede sessie. De context loopt op tot ~90K tokens met de uitwisselingen. Ik vraag aan Kimi om een AsciiDoc‑snapshotmechanisme toe te voegen dat de geheimen anonimiseert voordat ze worden geschreven.
Daar gaat het mis. Kimi begint klassen te verzinnen die niet bestaan. Hij stelt mij voor.AnonymizedObjectMapper— een fictieve klas. Hij verwart`ReadmeYmlAnonymizer` et CodebaseYmlAnonymizer. Hij suggereert dat ik importeer`com.fasterxml.jackson.anonymize.*`— een pakket dat nooit heeft bestaan.
Erger: in zijn reflectiefase zie ik dat hij redeneringen opbouwt op valse premissen. Hij "herinnert zich" dat`GitConfig`heeft een veld`anonymizedToken`— nee, het is`resolvedToken()Hij toeschrijft aan`SiteYmlAnonymizer`een methode`maskSupabaseCredentials()— die niet bestaat.
_ Het was geen fout. Het was een progressieve ontbinding van de coherentie. Alsof elk toegevoegd token aan de context de herinnering aan de eerste 30 000 een beetje meer verdunnde. _
Ik stop Kimi na twee sessies. De diagnose is duidelijk: de MLA comprimeert de KV-cache goed, maar zonder een fijnkorrelige spars selectiemechanisme verdunt de aandacht mechanisch verder dan 60K tokens. Elk token "ziet" steeds minder goed de verre context — en begint de gaten op te vullen met ruis.
Round 2 : GLM-5.1 — De Eerzame Strijder
GLM-5.1 komt met een andere architectuur: MLA voor het basismodel, gevolgd door een voortgezette pre-training met DSA (DeepSeek Sparse Attention) — een lichte indexer die dynamisch de relevante top-2048 tokens selecteert uit de gehele geschiedenis.
Architectuur: DSA tegen puur MLA
Het verschil is fundamenteel. Waar Kimi de historie comprimeert in een unieke latente ruimte (en geleidelijk het vermogen verliest om relevante informatie te onderscheiden), voegt GLM een post‑trainingsindexer toe die een expliciete sparse selectie uitvoert.
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
title Attention-architecturen — MLA vs MLA+DSA
left to right direction
rectangle "**Kimi K2.6 — Pure MLA**" as MLA #FFCDD2 {
rectangle "KV Cache\nvolledig" as KV1
rectangle "Latente\ncompressie" as CL1
rectangle "Decodering\nin latente ruimte" as DL1
KV1 --> CL1
CL1 --> DL1
note bottom of DL1
⚠️ Boven de 60K tokens:
verlies van discriminatievermogen
end note
}
rectangle "**GLM-5.1 — MLA + DSA**" as DSA #C8E6C9 {
rectangle "KV Cache\nvolledig" as KV2
rectangle "Latente\ncompressie (MLA)" as CL2
rectangle "Lichte indexeerder\n(DSA, top-k=2048)" as IL
rectangle "Decodering\nop geselecteerde tokens" as DL2
KV2 --> CL2
CL2 --> IL
IL --> DL2
note bottom of DL2
✅ "Lossless by construction"
Expliciete selectie
van relevante tokens
end note
}
MLA --> DSA : "Winst: sparse selectie\ndie verdunning voorkomt"
@enduml
Het technische rapport zegt het expliciet: DSA is "lossless by construction" — in tegenstelling tot alternatieven zoals SWA (pattern search), Gated DeltaNet of SimpleGDN die tot wel 5,69 punten verliezen op RULER@128K.
Sessies 11-13 : vast maar frustrerend
GLM-5.1 houdt de afstand beter vol. Tijdens sessie 11 (~60K tokens) blijft het coherent. Het produceert een`SnapshotManager`functioneel met correct beheer van de vier anonimiseurs.
Maar latentie is een probleem. De reflectiefases van DSA zijn zwaarder dan zuiver MLA — de indexer moet de geschiedenis bij elke stap herzien. Een antwoord dat 8 seconden duurde met Kimi, duurt nu 15 seconden met GLM. Bij een sessie van 30 berichten merk je dat.
En dan zijn er de subtiele fouten. GLM waant zich niet zoals Kimi — maar hij maakt fouten bij het benoemen. Hij noemt`toAnonymizedYaml()de methode die zou moeten heten`anonymize(). Hij keert om`loadReadmeConfiguration()` et loadCodebaseConfiguration()`in het`renderFileSection(). Het zijn geen hallucinaties, het zijn oppervlakkige verwarringen — maar in productie kan een oppervlakkige verwarring een build kapotmaken.
Ik heb drie sessies gehouden met GLM. Hij is beter dan Kimi, zonder twijfel. Maar drie sessies handmatige correctie op naamgevingsdetails, dat is vermoeiend.
Ronde 3 : DeepSeek-V4-Pro — De Oorlogsmachine
DeepSeek-V4-Pro komt met de meest ambitieuze architectuur van de drie: een hybride systeem dat twee complementaire aandachtmechanismen combineert.
Architectuur: CSA + HCA, de dubbele lijn
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 180
title DeepSeek-V4-Pro — Architecture Hybride CSA + HCA
left to right direction
rectangle "KV Cache\n1M tokens" as KV #E3F2FD
rectangle "CSA\nCompressed Sparse Attention" as CSA #C8E6C9 {
rectangle "Compression\nm tokens → 1" as CC
rectangle "Sparse Attention\n(DSA, top-k)" as SA
CC --> SA
note bottom of SA
Fijne lokale aandacht + sparse selectie
end note
}
rectangle "HCA\nHeavily Compressed Attention" as HCA #BBDEFB {
rectangle "Compression extrême\nm' >> m → 1" as ECC
rectangle "Attention dense\nresidueel" as EDA
ECC --> EDA
note bottom of EDA
Globale context + langeafstandsverbindingen
end note
}
rectangle "Fusion\nhybride" as FUSION #FFF9C4
rectangle "Décodage\ncoherent" as DEC #FFE0B2
KV --> CSA : Lokale precisie
KV --> HCA : Visie globaal
CSA --> FUSION
HCA --> FUSION
FUSION --> DEC
@enduml
Twee niveaus van compressie, twee granulariteiten van aandacht :
-
CSA: compreseert de KV-cache alle`m`tokens, past het een spars attention (DeepSeek Sparse Attention) toe — alleen de top-k van de gecomprimeerde invoer wordt geraadpleegd. Nauwkeurig, lokaal, efficiënt. - HCA: extreme compressie (factor`m'`veel groter dan`m`), maar let op dichte aandacht voor het gecomprimeerde residu — behoud de globale verbindingen zonder kwadratische explosie.
Resultaat: bij 1M tokens, DeepSeek-V4-Pro verbruikt alleen27% van de FLOPs van inferentie et 10% van de grootte van de KV cachein vergelijking met DeepSeek-V3.2. Het vorige model.
En vooral, het technische rapport (Figuur 9) maakt bekend : "Retrieval performance remains highly stable within a 128K context window."
Sessies 1-8: de verlichting
Ik heb acht sessies doorgebracht met DeepSeek-V4-Pro op`codebase-gradle`. Acht sessies zonder één enkele hallucinatie, zonder één enkele uitgevonden klasse, zonder één enkele naamverwarring.
Sessie 1: implementatie van`CodebaseYmlConfig` et CodebaseYmlAnonymizer. 350 regels Kotlin, inline tests, alles compileert. Sessie 4: toevoeging van`SnapshotManager`met boomweergave, bestandsverzameling, AsciiDoc-weergave per bestand. 279 regels, geen fouten. Sessie 7: foutopsporing van de`renderFileSection()`Die vier verschillende types van anonimisators moest beheren zonder ambiguïteit in de oplossing. Opgelost in drie berichten.
De latentie is hoger dan bij Kimi — ongeveer 10-12 seconden per antwoord in de think-modus. Maar de correctiegraad is bijna nihil. Ik besteed geen tijd aan het herstellen van de fouten van de agent. Ik code met hem.
De doorslaggevende test: refactoring van 100K tokens
Tijdens sessie 8 overschrijdt de cumulatieve context de 100K tokens. Ik vraag een zwaar refactoring : extraheren de vier inline verificatietaken du`build.gradle.kts`naar JUnit5-testbestanden in`buildSrc/src/test/`.
De agent stelt een plan voor in drie fasen:
-
Maak de testklassen aan met migratie van de bestaande gevallen
-
Voeg de afhankelijkheden JUnit5 en Kotest toe in`buildSrc/build.gradle.kts`
-
Verwijderen de inline code van`build.gradle.kts`
Het plan is correct. De uitvoering is netjes. Het identificeert zelfs een edge case dat ik gemist had: gedupliceerde Jackson-afhankelijkheden tussen`buildscript {}` et `buildSrc/build.gradle.kts`die tijdens de migratie verenigd moeten worden.
100K tokens context, en de agent herinnert zich dat`CodebaseYmlAnonymizer.TOKEN_MASK`is`"*"`, dat`GitConfig.resolvedToken()is een extension function gedefinieerd in`readme.kt, en dat`SnapshotManager.PRUNED_DIRS`uitsluit`build`, .gradle et .git.
Dat is het verschil.
De face-to-face: vergelijkende metrieken
| Criterium | Kimi K2.6 | GLM-5.1 | DeepSeek-V4-Pro |
|---|---|---|---|
Context max |
256K |
200K |
1M |
Aandachtmechanisme |
MLA zuiver |
MLA + DSA |
CSA + HCA hybride |
Totale parameters |
1T |
744B |
1,6 t |
Ingeschakelde instellingen |
32B |
niet gepubliceerd |
49B |
Waargenomen degradatiedrempel |
(empty) |
(blank) |
~128K tokens |
gedrag buiten |
Massieve hallucinaties |
Oppervlakkige verwarringen |
Langzame progressieve degradatie |
Stabiliteit NIAH |
niet gepubliceerd |
100% @128K (DSA) |
stabiel tot 128K (Figuur 9) |
MRCR @128K |
niet gepubliceerd |
niet gepubliceerd |
superieur dan Gemini 3.1 Pro |
Sessies gehouden voordat het werd opgegeven |
2 |
3 |
8 (en gaat verder) |
Correctietijd / code-tijd |
60% |
30% |
<5% |
Gemiddelde latentie (denkmodus) |
8 s |
15 s |
11 s |
Vertrouwenscoefficient* |
2/10 |
6/10 |
9/10 |
*Vertrouwenscoëfficiënt = subjectieve maatstaf voor mijn vermogen om de code van de agent en de commit over te nemen zonder regel voor regel controle._
@startuml skinparam backgroundColor #FEFEFE skinparam defaultTextAlignment center title Radar Vergelijkend — 3 LLMs in Ondersteunde softwareontwikkeling legend right |= Couleur |= Modèle | | <#FF5252> | Kimi K2.6 | | <#FFC107> | GLM-5.1 | | <#4CAF50> | DeepSeek-V4-Pro | endlegend rectangle " " as space #FFFFFF rectangle "Consistentie\n80K+ tokens" as coh #F5F5F5 rectangle "Kwaliteit\ncode" as qual #F5F5F5 rectangle "Redeneercapaciteit\narchitectonisch" as arch #F5F5F5 rectangle "Weerstand\nhallucinaties" as hall #F5F5F5 rectangle "Snelheid\n(ontwikkelaars ervaring)" as speed #F5F5F5 rectangle "Kennis\nGradle/Kotlin" as kg #F5F5F5 rectangle "Verhouding van\ncorrectie" as corr #F5F5F5 coh --> qual qual --> arch arch --> hall hall --> speed speed --> kg kg --> corr note top of coh Kimi ████░░░░░░ 4/10 GLM ██████░░░░ 6/10 DeepSeek █████████░ 9/10 end note note top of qual Kimi ███████░░░ 7/10 (onder 60K) GLM ████████░░ 8/10 DeepSeek █████████░ 9/10 end note note top of arch Kimi █████░░░░░ 5/10 GLM ███████░░░ 7/10 DeepSeek █████████░ 9/10 end note note top of hall Kimi ██████░░░░ 6/10 → ██░░░░░░░░ 2/10 (> 60K) GLM ███████░░░ 7/10 DeepSeek █████████░ 9/10 end note note top of speed Kimi █████████░ 9/10 GLM ██████░░░░ 6/10 DeepSeek █████░░░░░ 5/10 end note note top of kg Kimi ███████░░░ 7/10 GLM ███████░░░ 7/10 DeepSeek █████████░ 9/10 end note note top of corr Kimi ██░░░░░░░░ 2/10 (veel correcties) GLM █████░░░░░ 5/10 DeepSeek ██████████ 10/10 (bijna niets te corrigeren) end note @enduml
Waarom DeepSeek-V4-Pro wint in softwareontwikkeling
De superioriteit van DeepSeek-V4-Pro is niet te wijten aan één enkele factor — het is een convergentie:
De CSA+HCA-architectuur is afgestemd op de code
Ondersteunde softwareontwikkeling is een extreme gebruiksgeval voor de aandacht voor langere context. U heeft nodig: - Lokale precisie (deze klasse erft van wat ? deze methode is waar gedefinieerd ?) →CSA - Algemeen overzicht (waarom bestaat deze module? hoe interageren de vier anonimiseerder? ) →HCA
Kimi met MLA alleen behandelt de lokale nauwkeurigheid maar verliest het globale zicht buiten 60K. GLM met DSA verbetert het globale zicht maar blijft mono-niveau. DeepSeek combineert beide expliciet.
2. De context EAGER is zijn comfortzone
Mijn gouvernance-systeem laadt bij het opstarten ongeveer 30K tokens aan regels en backlog. Met een stabiele venster tot 128K, heeft DeepSeek ongeveer 100K tokens marge voor de sessie-uitwisselingen. Dit is 3 tot 4 keer meer dan wat Kimi kan verwerken zonder degradatie.
_ Het venster van 128K perfecte stabiliteit komt exact overeen met mijn behoeften: 30K EAGER + 70K uitwisselingen = een productieve sessie van 20-30 berichten zonder ooit de groene zone te verlaten. _
3. De kwaliteit/latentieverhouding is optimaal voor de flow
Ja, DeepSeek-V4-Pro is langzamer dan Kimi (11s vs 8s). Maar de totale tijd van een taak is aanzienlijk lager omdat ik geen 20 minuten besteed aan het corrigeren van de hallucinaties van de agent.
De ontwikkelaar meet de latentie van een antwoord niet. Hij meet de tijd tussen "je pose la question" et "le code est dans mon repo et il fonctionne". Op deze maatstaf is DeepSeek-V4-Pro het snelste van de drie.
Geleerde lessen : Hoe kies je jouw LLM voor Vibe Coding
Voorbij de incidentele ranking heeft deze ervaring mij geleerd om een LLM te evalueren voor ondersteunde softwareontwikkeling op criteria die in geen enkele benchmark voorkomen:
-
Bekijk de architectuur, niet de aangekondigde contextgrootte— Een model dat 256K context aankondigt maar slechts een MLA heeft, eindigt zoals Kimi: theoretisch in staat, praktisch onbruikbaar boven de 60K.
-
Test op JOUW context, niet op een generieke benchmark— Mijn initiële prompt van 30K tokens AsciiDoc met absolute regels en backlog heeft niets te maken met de vragen van HLE of AIME.
-
Latency is niet de vijand als de kwaliteit meegaat— Een langzaam model dat juiste code produceert is sneller dan een snel model dat onjuiste code produceert.
-
Pas op voor modellen zonder openbaar technisch rapport— Als het team zijn attention-architectuur niet documenteert, betekent dat dat het geen vertrouwen heeft in zijn prestaties in lange context.
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 260
title Beslissingsboom — Kies zijn LLM voor de ondersteunde ontwikkeling
start
:Begincontext\n> 20K tokens?;
if (Oui) then
:Aandachtsarchitectuur\nhybride of multi-niveau ?;
if (CSA+HCA) then
:DeepSeek-V4-Pro
Fenetre stable 128K
Ideal pour gouvernance EAGER;
stop
elseif (MLA + DSA) then
:GLM-5.1
Correct jusqu'a ~120K
Latence elevee;
stop
else (MLA seul)
:Kimi K2.6 (sessions courtes)
ou eviter pour long contexte
Chercher un modele avec
sparse attention;
stop
endif
else (Contexte < 20K)
:N'importe lequel fonctionne.
Privilegier la latence.;
stop
endif
@enduml
En wat is er met de Agent Governance in dit alles?
Dit experiment bevestigt een punt dat ik sinds mijn artikel over de gouvernance Eager/Lazy verdedig:de kwaliteit van het LLM en de kwaliteit van de bestuur zijn multiplicatief, niet additief.
Met Kimi K2.6 was mijn bestuur onberispelijk — maar het model verdunde de informatie. Resultaat: perfect bestuur × hallucinatie = nul.
Met DeepSeek-V4-Pro vormt de governance EAGER (30K tokens aan regels) + LAZY (sessiearchieven, technische referenties) + Hot/Warm/Cold (roterende backup) een ecosysteem waarin elke laag de ander versterkt. De agent heeft de regels voor zich (EAGER), kan de historie raadplegen (LAZY), en de context verzadigt nooit (rotatie van backups).
_ Een goed LLM zonder bestuur, is een motor van Ferrari zonder stuur. Een goede bestuur zonder goed LLM, is een stuur zonder motor. DeepSeek-V4-Pro + mijn bestuur agent = de eerste keer dat ik het gevoel heb te rijden. _
Het roterende back-upmechanisme (rotatie elke 10 sessies of >500 EAGER-lijnen) krijgt helemaal zijn zin met een model dat 128K context kan vasthouden : de sliding window van 10 actieve sessies houdt de context vers zonder ooit de degradatiezone te overschrijden.
Technische bronnen
Ik heb mijn empirische ervaring gekruist met de officiële technische rapporten om mijn observaties te valideren:
-
DeepSeek-V4 Technical Report — PDF opgehaald sindshttps://huggingface.co/deepseek-ai/DeepSeek-V4-Flash[HuggingFace]. Figuur 9: "Retrieval performance remains highly stable within a 128K context window. While a performance degradation becomes visible beyond the 128K mark, the model’s retrieval capabilities at 1M tokens remain remarkably strong." Architectuur CSA+HCA gedocumenteerd sectie 2.3.
-
GLM-5 Technisch Rapport —https://arxiv.org/abs/2602.15763[arXiv:2602.15763]. DSA wordt geïntroduceerd via voortgezette pre‑training, "lossless by construction". Maximale context van 202.752 tokens. Tabellen 3/5/6 documenteren de prestaties van de lange context versus alternatieven (SWA, Gated DeltaNet, SimpleGDN).
-
Kimi K2.6 Model Card —https://huggingface.co/moonshotai/Kimi-K2.6[HuggingFace]. MLA, maximale 256K context. Discard-all strategie boven de drempel op agentische taken (bevestigend impliciet de praktische limiet van MLA in lange context).
-
Kimi K2 Technisch rapport —https://arxiv.org/abs/2507.20534[arXiv:2507.20534]. Architectuur MoE, MuonClip-optimizer, agentische prestaties (HLE, BrowseComp, Terminal-Bench).
Het meest onthullende punt: in hun eigen evaluatie past Moonshot een strategie van discard-all (verwijdering van de oude context) toe zodra de contextvenster wordt overschreden. Dit bevestigt precies wat ik heb waargenomen: de MLA alleen kan de samenhang niet behouden over het volledige venster van 256K. De architectuur kan niet volgen.
Conclusie: De keuze van de ambachtsman
Na drie weken en dertien sessies van echte ontwikkeling is het verdict zonder beroep:
| Kimi K2.6 | GLM-5.1 | DeepSeek-V4-Pro |
|---|---|---|
Excellent onder 60K |
Stevig tot 120K |
Heerst overal |
Niet bruikbaar buiten |
Oppervlakkige confusies |
Stabiel tot 128K |
2 sessies, verlaten |
3 sessies, verlaten |
8 sessies, aangenomen |
DeepSeek-V4-Pro is mijn standaard LLM voor alle Opencode-ondersteunde softwareontwikkelingssessies. Niet omdat het het nieuwste is. Niet omdat het de beste academische benchmarks heeft. Maar omdat in de echte wereld van een ontwikkelaar die Gradle Kotlin DSL-plugins pusht met een agent-context van 30K tokens, het de enige is die me niet in de steek laat wanneer de context langer wordt.
De CSA+HCA is een game changer architectonisch. De dubbele-niveau compressie + sparsificatie is geen implementatiedetail — het is wat het verschil maakt tussen een code-assistent en een betrouwbare teamgenoot.
(Empty) Ik heb gekozen voor DeepSeek-V4-Pro omdat het de enige van de drie is die mijn agent-governance transformeert van een defensieve beperking ("hoe voorkom ik dat het agent vergeet?") tot een offensief voordeel ("wat kunnen we nu bouwen nu het agent zich alles herinnert?"). __
Dit artikel is het resultaat van 13 sessies van werkelijke ontwikkeling voor het project`codebase-gradle`, gedocumenteerd in`.agents/sessions/`volgens mijn governance-methodologie voor agents Eager/Lazy/Hot/Warm/Cold. De genoemde technische bronnen zijn publiek toegankelijk op HuggingFace en arXiv.