DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1 : Tri LLM-a na ispitu Vibe Coding dugog konteksta

Објављено 28 April 2026

Vreme za čitanje : 18 minutes

Rat LLM-ova se odvija i u terminalu programera. Ne na akademskim bezplodnim benchmarkovima. U stvarnom životu: prompt od 30 000 tokena, upravljanje agenta u AsciiDoc, Gradle Kotlin DSL pluginovi koje treba ispraviti i sesije koje se nastavljaju tri nedelje. Testirao sam za vas DeepSeek-V4-Pro, Kimi K2.6 i GLM-5.1. Evo veredicta, podržan tehničkim dokazima.

тик

[]

Kontekst: nije poligon za testiranje, već gradilište.

Prije tri tjedna, radio sam na`codebase-gradle`, moj meta-build sistem koji centralizuje YAML konfiguraciju četiri projekta: generator README-a PlantUML, gradivac slajdova AsciiDoc, statički sajt JBake i chatbot LLM. Agent Opencode, upravljajući mojom metodologijom datoteka agente u AsciiDoc-u, učitavao je ~30K tokena EAGER konteksta na početku svakog sesije — apsolutna pravila, backlog, istorija poslednjih 10 sesija.

Na ovom terenu sam se suočio sa tri modela:

  • Kimi K2.6(Moonshot AI, 1T parametara / 32B aktivirani, 256K maksimalni kontekst, MLA) - GLM-5.1(Zhipu AI/Tsinghua, 744B parametara / DSA, maksimalni kontekst 200K) - DeepSeek-V4-Pro(DeepSeek, 1.6T parametara / 49B aktiviranih, 1M kontekst max, CSA+HCA)

Svi servisi putem Ollama na cloud serveru, svi u modu razmišljanja (aktivirana faza refleksije). Izazov: da se producira ispravan kod, da se održava konzistentnost tokom dugih sesija, i da se ne halluciniše kada kontekst prelazi 80K tokena.

Moje testno okruženje

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 220

title Тест окружење — Сессии Opencode × 3 LLMs
left to right direction

package "🖥️ Terminal developera" #E8F5E9 {
  rectangle "AGENT.adoc\n(pravila, backlog)" as AG
  rectangle "PROMPT_REPRISE\n(misija)" as PR
  rectangle "INDEX.adoc
(plan razvoja)" as IDX
}

package "☁️ Ollama облако" #BBDEFB {
  rectangle "DeepSeek-V4-Pro\n1.6T / CSA+HCA" as DV4
  rectangle "Kimi K2.6\n1T / MLA" as KIMI
  rectangle "GLM-5.1
744B / MLA+DSA" as GLMG
}

package "⚙️ Osnova Gradle" #FFF9C4 {
  folder "buildSrc/" {
    file "codebase.kt"
    file "readme.kt"
    file "site.kt"
    file "slider.kt"
    file "snapshot.kt"
  }
  file "build.gradle.kts
(947 linije)"
  file "embeds.yml"
}

AG --> DV4 : Sessions 1-8 ✅
AG --> KIMI : Sessions 9-10 ⚠️
AG --> GLMG : Sessions 11-13 ⚠️

DV4 --> "osnova koda" : "TDD, refaktoring,
snapshot"
KIMI --> "osnova koda" : "Degradation
od 60K tokena"

note bottom of GLMG
  Meilleur que Kimi
  mais latence +
  DSA moins robuste
  que CSA+HCA
end note

@enduml

Svaka sesija je započela sa oko 30K tokena EAGER konteksta :`AGENT.adoc`(287 linija),PROMPT_REPRISE.adoc(51 linija),.agents/INDEX.adoc(218 linija),LAZY_EAGER_ESSENTIALS.adoc(50 linija). Kontekst se brzo povećavao sa razmenom — tipična sesija od 10 poruka dodavala je 15-20K tokena kumulativnom promptu.

Табела за оцене

Ocenio sam svaki model po četiri kritične ose za podržani razvoj softvera:

sekira

konkretan kriterijum

Kohezija dugog konteksta

Da li se agent sjeća konvencija koje su odlučene pre 40 poruka?

Kvalitet proizvedenog koda

Da li kod kompajlira od prvog puta? Da li poštuje posteće obrasci?

Arhitektonsko razmišljanje

Da li agent razumije odnose između modula bez da mu ih ponovo objasnim?

Опорност против халцинација

Од колико токена агент почето да измишља непостаojeће АПИ или класе?

И домаћа синтетичка метрика: оkoeficijent oporavka(koliko vremena provodim ispravljujući agenta umesto da kodiram s njim)

Krug 1 : Kimi K2.6 — Lažni Početak

Kimi K2.6 je bio moj prvi izbor. Njegovi benchmarki na SWE-Bench Verified (80.2) i Terminal-Bench 2.0 (66.7) su odlični. Njegova MLA arhitektura obećava dobru efikasnost na dugim sekvencama.

Sesija 9 : uspon

Прва сесија са Кими. Задатак: имплементирати метод`resolveActiveKey()u`codebase.kt— функција за решавање API кључа са резервном CLI. Контекст је 30K токена, Kimi brzо размишља, произвођа чисти код са управљањем истецом кључева.

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é
}

Код компајлира. Сви 7 тест случаја prolaze. Оптимистичан сам.

Сесија 10: тихо потопљење

Druga sesija. Kontekst raste na ~90K tokena sa razmenama. Tražim od Kimi da doda mekanizam snapshot AsciiDoc koji anonimizuje tajne pre pisanja.

Ovo je gde sve kreće po sravi. Kimi počinje da izmišlja klase koje ne postoje. On mi ponuđuje.AnonymizedObjectMapper— fiktivna klasa. On miješa`ReadmeYmlAnonymizer` et CodebaseYmlAnonymizer. Mi predlaže da uvezem.com.fasterxml.jackson.anonymize.*— paket koji nikada nije postojao.

Pire: u fazi njegove razmišljanja, vidim da gradi zaključke na lažnim pretpostavkama. Il "se seća" que`GitConfig`ima polje`anonymizedToken`— ne, to je`resolvedToken()On pripisuje`SiteYmlAnonymizer`jedna metoda`maskSupabaseCredentials()— koji ne postoji.

(blank) Није било грешка. Б је било постепно растворење саглашености. Као да је сваки додатни токен у контексту разјединио мало више меморије првих 30 000. __

Zaustavljam Kimi nakon dva sesija. Dijagnoza je jasna: MLA dobro kompresuje KV keš, ali bez mehanizma finog sparse selektovanja, pažnja se mehanički rjeđešava iznad 60K tokena. Svaki token "vidi" sve manje i manje dobro udaljeni kontekst — i počinje da popunjava rupe šumom.

Krug 2: GLM-5.1 — Počasni borac

GLM-5.1 dolazi sa različitom arkitekturom: MLA za bazni model, zatim continued pre-training sa DSA (DeepSeek Sparse Attention) — lagani indeksator koji dinamički bira najbolje relevantnih top-2048 tokena iz celog istorija.

Архитектура: DSA против чист MLA

Razlika je temeljna. Gde Kimi kompresuje istoriju u jedinstvenom latentnom prostoru (i postupno gubi sposobnost da razlikuje relevantne informacije), GLM dodaje post‑entrenacioni indekser koji vrši eksplicitnu sparse selekciju.

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title python
print("Архитектуре Attention — MLA vs MLA+DSA", end='')
left to right direction

rectangle "**Kimi K2.6 — MLA čist**" as MLA #FFCDD2 {
  rectangle "KV Cache
kompletan" as KV1
  rectangle "Компресија
латентна" as CL1
  rectangle "Dekodiranje\nna latentnom prostoru" as DL1
  KV1 --> CL1
  CL1 --> DL1
  note bottom of DL1
    ⚠️ Au-delà de 60K tokens :
    perte de discrimination
  end note
}

rectangle "GLM-5.1 — MLA + DSA" as DSA #C8E6C9 {
  rectangle "KV Cache
kompletan" as KV2
  rectangle "Latentna\nkompresija (MLA)" as CL2
  rectangle "Lahki indekser
(DSA, top-k=2048)" as IL
  rectangle "Декодирање
на избраних токенима" as DL2
  KV2 --> CL2
  CL2 --> IL
  IL --> DL2
  note bottom of DL2
    ✅ "Bez gubitka po konstrukciji"
    Sélection explicite
    des tokens pertinents
  end note
}

MLA --> DSA : "Dobit: sparse selekcija
koja sprečava rijedenje"

@enduml

Tehnički izveštaj jasno tvrdi: DSA je "lossless by construction" — suprotno tome od alternativa kao što su SWA (pattern search), Gated DeltaNet ili SimpleGDN koje gube do 5.69 pts na RULER@128K.

Sesije 11-13 : vrstan ali frustrujući

GLM-5.1 bolje drži udaljenost. Na sesiji 11 (~60K tokena), ostaje koherentan. proizvodi jedan`SnapshotManager`funkcionalno sa ispravnim upravljanjem četiri anonymizatora

Ali latencija je problem. Faze razmišljanja DSA su teže od čistog MLA — indekser mora da ponovo proskenira istoriju na svakom koraku. Odgovor koji je trajao 8 sekundi kod Kimija uzima 15 sekundi kod GLM. U sesiji od 30 poruka, to se osjeća.

I onda ima subtile greške. GLM ne halucinise kao Kimi — ali pravi greške u imenovanju. On naziva`toAnonymizedYaml()metoda koja bi trebalo da se zove`anonymize(). On inveruje`loadReadmeConfiguration()` et loadCodebaseConfiguration()`у`renderFileSection(). Ovo nisu halucinacije, to su površinske zbune — ali u proizvodnji, jedna površinska zbuna može razbiti build.

Održao sam tri sesije sa GLM. On je bolji od Kimija, bez sumnje. Ali tri sesije ručne korekcije detalja imenovanja, to mi je iznerviralo.

Krug 3: DeepSeek-V4-Pro — Mašina za rat

DeepSeek-V4-Pro dolazi sa najambicioznijom arhitekturom od tri: hibridni sistem koji kombinuje dva komplementarna mehanizma pažnje.

Arhitektura : CSA + HCA, dvostruka nit

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 180

title DeepSeek-V4-Pro — Hibridna arhitektura CSA + HCA
left to right direction

rectangle "KV keš
1M tokena" as KV #E3F2FD

rectangle "CSA
kompresirana sparsna pažnja" as CSA #C8E6C9 {
  rectangle "Kompresija
m tokeni → 1" as CC
  rectangle "Retka pažnja
(DSA, top-k)" as SA
  CC --> SA

  note bottom of SA
    Attention locale fine
    + sélection sparse
  end note
}

rectangle "HCA
Teško komprimirana pažnja" as HCA #BBDEFB {
  rectangle "ekstremna kompresija\nm' >> m → 1" as ECC
  rectangle "Внимание густо
резидуелна" as EDA
  ECC --> EDA

  note bottom of EDA
    Contexte global
    + connexions longue distance
  end note
}

rectangle "Hibridna fuzija" as FUSION #FFF9C4
rectangle "Dekodiranje
koherent" as DEC #FFE0B2

KV --> CSA : Précision locale
KV --> HCA : Vision globale

CSA --> FUSION
HCA --> FUSION
FUSION --> DEC

@enduml

Два нивоа компресии, две грануларности внимания :

  • CSAkompresuje KV keš sve`m`tokeni, zatim primenjuje sparsu pažnju (DeepSeek Sparse Attention) — samo top-k komprimiranih ulaza se konzultuje. Precizan, lokalan, efikasan. - HCA: ekstremna kompresija (faktor`m'`mnogo veći od`m`), ali gusta pažnja na kompresovanom reziduumu — čuva globalne veze bez kvadratnog eksplozije.

Резултат : при 1M токена, DeepSeek-V4-Pro потрошава само27% FLOPs zaključka et 10% veličine KV kešau odnosu na DeepSeek-V3.2. Prethodni model.

Savršeno važno, tehnički izveštaj (Slika 9) objavljuje : "Retrieval performance remains highly stable within a 128K context window."

Sednice 1-8: olaksica

Proveo sam osam sesija sa DeepSeek-V4-Pro na`codebase-gradle`. Osam sesija bez jedne halucinacije, bez jedne izmišljene klase, bez jedne zbunjenja u imenovanju.

Сесија 1 : реализација`CodebaseYmlConfig` et CodebaseYmlAnonymizer. 350 linija Kotlin, inline testovi, sve se kompajlira. Sessija 4: dodavanje`SnapshotManager`sa drvnim pregledom, prikupljanje fajlova, renderiranje AsciiDoc po fajlu. 279 linija, nula grešaka. Sesija 7: debugovanje`renderFileSection()`koji je trebalo da upravlja četiri različita tipa anonimizera bez ambiguiteta u rešavanju. Rešeno u tri poruke.

Latnija je viša nego kod Kimija — oko 10-12 sekundi po odgovoru u režimu razmišljanja. Međutim, stopa ispravke je skoro nula. Ne provodim vreme na popravljanje grešaka agenta. Kodiram avec njim.

Odlučni test : refaktoring na 100K tokena

Na sesiji 8, akumulativni kontekst prelazi 100K tokena. Zahtevam teški refaktoring: izvući četiri inline provere zadatka iz`build.gradle.kts`ка датотека тестова JUnit5 у`buildSrc/src/test/`.

Agent predlaže plan u tri faze:

  1. Kreirati testne klase sa migracijom postojećih slučajeva

  2. Dodajte zavisnosti JUnit5 i Kotest u`buildSrc/build.gradle.kts`

  3. Уклони инлајн код из`build.gradle.kts`

On čak identifikuje edge case koji sam propustio: duplikirane Jacksonove zavisnosti između`buildscript {}` et `buildSrc/build.gradle.kts`koje moraju biti ujedinjene tokom migracije

100K tokena konteksta, i agen se seća da`CodebaseYmlAnonymizer.TOKEN_MASK`je`"*"`, da`GitConfig.resolvedToken()je funkcija proširenja definisana u`readme.kt, и да`SnapshotManager.PRUNED_DIRS`isključe`build`, .gradle et .git.

To je to, razlika.

Lice u lice : Poredbene metrike

Kriterijum Kimi K2.6 GLM-5.1 DeepSeek-V4-Pro

Максимални контекст

256KB

200K

1M

Mehanizam pažnje

MLA čist

MLA + DSA

CSA + HCA hibrid

Ukupni parametri

1T

744B

1,6T

Uključeni parametri

32B

неопубликовано

49B

Opaženi prag degradacije

~60K tokens

~120K tokens

~128K tokens

Ponašanje izvan

Masivne halucinacije

površinske konfuzije

sporo progresivna degradacija

Стабилност NIAH

ne objavljeno

100% @128K (DSA)

stabilno do 128K (Slika 9)

MRCR @128K

неопубликован

неопубликован

viši od Gemini 3.1 Pro

Sesije održane pre napuštanja

2

3

8 (i nastavlja)

Vreme ispravke / vreme koda

60%

30%

<5%

Srednja latencija (mod razmišljanja)

8 s

15 s

11 s

koeficijent poverenja*

2/10

6/10

9/10

*Koeficijent poverenja = subjektivna mere moje sposobnosti da uzmem kod agenta i commit bez red po red pregleda.

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title Радар поређење — 3 LLMs у подржаном развоју софтвера
legend right
  |= Couleur |= Modèle |
  | <#FF5252> | Kimi K2.6 |
  | <#FFC107> | GLM-5.1 |
  | <#4CAF50> | DeepSeek-V4-Pro |
endlegend

rectangle " " as space #FFFFFF

rectangle "Кохеранција
80K+ tokens" as coh #F5F5F5
rectangle "kvalitet\nkod" as qual #F5F5F5
rectangle "размотрање\nархитектонски" as arch #F5F5F5
rectangle "Отпор
халуцинации" as hall #F5F5F5
rectangle "Brzina
(razvoj iskustvo)" as speed #F5F5F5
rectangle "Znanje
Gradle/Kotlin" as kg #F5F5F5
rectangle "Stopa\nkorekcije" 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 (sous 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 (beaucoup de corrections)
  GLM       █████░░░░░ 5/10
  DeepSeek  ██████████ 10/10 (presque rien à corriger)
end note

@enduml

Zašto DeepSeek-V4-Pro pobjeđuje u razvoju softvera

Преважанство DeepSeek-V4-Pro nije zbog samo jednog faktora — то је конвергенција:

Arhitektura CSA+HCA je prilagođena kodu

Podržani razvoj softvera je ekstremni slučaj upotrebe za dugokontekstnu pažnju. Treba vam : - Lokalna preciznost (Ova klasa nasleđuje šta ? Ova metoda je definisana gde ?) →CSA - Globalna vidra (zašto ovaj modul postoji? kako četiri anonimizatora međusobno interaguju?) →HCA

Kimi sa MLA jedini rukuje lokalnom preciznošću, ali gubi globalni vidic iznad 60K. GLM sa DSA poboljšava globalni vidic, ali ostaje jedno-nivoa. DeepSeek eksplicitno kombinuje oba.

2. Kontekst EAGER je njegova zona komfora

Moj sistem upravljanja učitava ~30K tokena pravila i backlog pri pokretanju. Sa stabilnim prozorom do 128K, DeepSeek ima ~100K tokena rezervi za razmenu sesije. To je 3 do 4 puta više od toga što Kimi može da obavi bez degradacije.

_ Prozor od 128K perfektne stabilnosti tačno odgovara mojim potrebama: 30K EAGER + 70K razmena = produktivna sesija od 20-30 poruka, nikad ne izlaze iz zelene zone. _

3. Odnos kvalitet/latencija je optimalan za tok

Да, DeepSeek-V4-Pro је спорији од Kimi (11s vs 8s). Но total време за задатак је много мање јер не провождам 20 минута исправљањем халцинуција агента.

Razvijalac ne meri latenciju odgovora. On meri vreme između "postavljam pitanje" i "kôd je u mom repozitoriju i radi". Na ovoj metrici, DeepSeek-V4-Pro je najbrži od tri.

Naučene lekcije: Kako izabrati svoj LLM za Vibe Coding

Osim trenutnog rangiranja, ovo iskustvo me je naučilo da ocenjujem LLM za razvoj softvera sa podrškom po kriterijumima koji se ne nalazu u nijednom benchmarku:

  1. Погледај архитектуру, не оглашену величину контекста— Model koji objavljuje 256K konteksta ali ima samo MLA završeće kao Kimi: teorijski sposoban, praktički neupotrebljivi iznad 60K.

  2. Тестирај на свом контексту, а не на генераличком бенчмарку— Moj početni prompt od 30K tokena AsciiDoc sa apsolutnim pravilima i backlogom nema veze sa pitanjima HLE ili AIME.

  3. Latencija nije neprijatelj ako kvalitet sledi— Sporo model koji proizvodi tačan kod je brži od brzog modela koji proizvodi pogrešan kod.

  4. Pazaj na modele bez javnog tehničkog izveštaja— Ako tim ne dokumentuje svoju arhitekturu pažnje, znači da nema poverenja u njenu održavanju u dugому контексту.

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 260

title Stablo odlučivanja — Izabrati svoj LLM za podršku pri razvoju
start

:Contexte initial\n> 20K tokens ?;

if (Oui) then
  :Architecture d'attention\nhybride ou 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

И агент за управљање у све то?

Ovo iskustvo potvrđuje tačku koju branim od mog članka o Eager/Lazy upravljanju :Kvalitet LLM-a i kvalitet upravljanja su množivi, a ne aditivni..

С Kimi K2.6, моје управљање беше беспречно — али је модел разтезао информацију. Резултат: управљање безгрешно × халцинација = нула.

Sa DeepSeek-V4-Pro, upravljanje EAGER (30K tokena pravila) + LAZY (arhiva sesija, tehničke reference) + Hot/Warm/Cold (rotaciono rezerviranje) formira ekosistem gde svaki sloj pojačava drugi. Agent ima pravila pred očima (EAGER), može pogledati istoriju (LAZY), a kontekst se nikada ne preteruje (rotaciono rezerviranje).

_ Dobar LLM bez upravljanja, то je motor Ferrari bez volanta. Dobro upravljanje bez dobrog LLM, то je volan bez motora. DeepSeek-V4-Pro + moj agent za upravljanje = prvi put da osećam da vozim. _

Rotacioni mehanizam backup-a (rotacija svakih 10 sesija ili >500 EAGER linija) ima pun smisla kod modela koji drži 128K konteksta: sliding window od 10 aktivnih sesija održava kontekst svežim, nikad ne prelazeći zonu degradacije.

tehnički izvori

Савлачио сам свои empirijsko iskustvo sa zvaničnim tehničkim izveштаjima, да бих потврдио моје наблюдање.

  1. DeepSeek-V4 Technical Report — PDF preuzeto izhttps://huggingface.co/deepseek-ai/DeepSeek-V4-Flash[HuggingFace]. Slika 9: "Uspeh preuzimanja ostaje izuzetno stabilan unutar prozora konteksta od 128K. Dok se smanjenje uspeha postaje vidljivo van 128K granice, sposobnosti modela preuzimanja pri 1M tokenova ostaju izuzetno jakte." Arhitektura CSA+HCA dokumentisana u odeljku 2.3.

  2. GLM-5 Tehnički izveštaj —https://arxiv.org/abs/2602.15763[arXiv:2602.15763]. DSA se uvodi kroz continued pre-training, "lossless by construction". Maksimalni kontekst 202,752 tokena. Tabele 3/5/6 dokumentiraju performanse dugog konteksta u odnosu na alternative (SWA, Gated DeltaNet, SimpleGDN).

  3. Kimi K2.6 Model Card —https://huggingface.co/moonshotai/Kimi-K2.6[HuggingFace]. MLA, 256K maksimalni kontekst. Strategija discard-all iznad praga na agentičnim zadacima (implicitno potvrđujući praktičnu granicu MLA u dugoročnom kontekstu).

  4. Kimi K2 Технички извештај —https://arxiv.org/abs/2507.20534[arXiv:2507.20534]. Архитектура MoE, оптимизатор MuonClip, агенске перформансе (HLE, BrowseComp, Terminal-Bench).

Najotkrivniji stav: u njihovoj sopstvenoj proceni, Moonshot primenjuje strategiju discard-all (brisanje starog konteksta) odmah kada se kontekstni prozor prekorači. Ovo potvrđuje tačno ono što sam primetio: MLA sam ne može da održi konzistenciju kroz ceo prozor od 256K. Arhitektura ne sledi.

Zaključak: Izbor majstora

Posle tri nedelje i trinaest sesija stvarnog razvoja, verdict je neizboran:

Kimi K2.6

GLM-5.1

DeepSeek-V4-Pro

Odlično ispod 60K

Čvrsto do 120K

Vlada svuda

Neupotrebljiv izvan

површинске конфузии

Stabilan do 128K

2 sesije, ostavljeno

3 сења, опусћене

8 сесије, прихваћен

DeepSeek-V4-Pro je postao moj podrazumevani LLM za sve sesije razvoja softvera pomognute Opencode-om. Ne zato što je najnoviji. Ne zato što ima najbolje akademski benchmark. Jer u stvarnom životu razvojera koji šalje Gradle Kotlin DSL plugine sa kontekstom agenta od 30K tokena, on je jedini koji me ne varava kada se kontekst produži.

CSA+HCA je game changer arhitekturni. Dvostepena kompresija + sparsifikacija nije detalj implementacije — to je što pravi razliku između kodskog asistenta i pouzdanog člana tima.

_ Izabrao sam DeepSeek-V4-Pro jer je jedini od tri koji menja moje upravljanje agentom iz defensivnog ograničenja ("Kako sprečiti da agent zaboravi?") u ofanzivnu prednost ("Šta možemo sada izgraditi jer agent svašta pamti?"). _

Оvaj članak је плод 13 реалних сесија развоја на пројекту`codebase-gradle`, dokumentovano u`.agents/sessions/`po mojoj metodologiji upravljanja agent Eager/Lazy/Hot/Warm/Cold. Navedeni tehnički izvori su javno dostupni na HuggingFace i arXiv.

Повезани чланци

HyperFrames-Gradle : Претвори AsciiDoc у MP4 видео
31 May 2026
Audit moje potrošnje LLM : SQLite, OpenCode, Ollama Cloud, i Zašto Moj Pro Abonament razbijava svetski tržište
18 May 2026
Архитектура « Plugin nezavisni + koren potrošač » : Зашто моје builds Gradle се дублирају
14 May 2026
Knowledge Graph kao motor preporuke: kako sam ubio « povezani članci » hronološki
12 May 2026