⚡ In één zin
Moonshot heeft Kimi K3-256K uitgebracht: dezelfde hersenen als de volledige K3, minus video-invoer, met de context-window hard gecapped op 256K. Op papier leest dat als een downgrade. Maar zodra de developer-community de rekening had gemaakt, was het oordeel opmerkelijk unaniem — dit is de pragmatische keuze, want lange context is op zichzelf de grootste kostenmoordenaar die in je factuur schuilt.
Voor het overgrote deel van je coding-werk zit de hoofdmoot van de kosten niet in invoer of uitvoer — die zit in context. Rek je window van 50K op richting een miljoen, dan springt je gemiddelde token-verbruik een volledige orde van grootte. Tenzij cache spotgoedkoop is, is dat een Token-moordenaar. Door context op config-niveau te knevelen, schakelt Kimi namens jou de duurste knop uit.
💸 Waarom lange context je zo duur staat
Een feit dat developers steeds weer pijnlijk leren: bij coding-taken, zolang cache niet onder controle is, zit de hoofdmoot van wat je betaalt in het context-gedeelte van je tokens. Hoe groter de window, hoe meer elke turn eigenlijk alleen maar een almaar grotere berg heen en weer sjouwt.
Maar er zit een addertje onder het gras — lange context is pas "begrensd duur" wanneer cache-hit-prijsstelling laag genoeg is. Op dit moment zijn DeepSeek en MiMo de enige twee leveranciers die cache-prijzen écht hebben omlaag gekregen, dus hun miljoen-token-windows zijn de enige die als "betaalbaar" door de beugel mogen. Bij elke andere aanbieder is long-context-facturering ronduit belachelijk; de rationele default blijft altijd korte context.
De rekenkunde is meedogenloos. Een 1M-context komt in de praktijk gemiddeld uit op zo'n 500K, en naast een 50K-context is dat een 10× verschil in uitgave.
Maak het een gewoonte om rond 100K te compacten en je gemiddelde context blijft hangen rond 50K. Laat je het oplopen tot 990K en wacht je op de auto-compact van het systeem, dan ligt je gemiddelde op 500K. Zelfde "long-context-model", maar de tweede gewoente is 10× zo duur als de eerste. Zelfs binnen de 256K-tier kost een gesprek dat doorloopt tot 200K 4× je 50K-basislijn.
Dit verandert allemaal pas wanneer cache-hit-prijsstelling écht goedkoop is. De meeste mainstream-modellen houden cache-prijzen ook hoog, dus de dominante kostenpost blijft op context staan — en lange context drijft je factuur altijd omhoog. Context actief beperken zorgt ervoor dat je agent-harness de grootte automatisch beheert, en dát is de move die de uitgave écht snijdt.
🧠 De meeste mensen hebben geen context-management-reflex
Het dieperliggende probleem is gewoonte. Heel veel mensen hebben nul instinct om context actief te beheren — ze besteden het volledig uit aan de harness (de agent-softwarelaag) en diens auto-compact. Erger nog: ze kiezen het duurste model, draaien één gesprek helemaal leeg, en triggeren comprimering pas wanneer het ding barst bij 1M.
Onder dat patroon is "quota verbrand in een paar turns" vrijwel gegarandeerd. De spot die je in Kimi's Feishu-groepen ziet — "weinig verbruik, na een paar turns op" — is bijna zeker gekoppeld aan precies dit gebruikspatroon. De officiële mededeling in de groep luidde: "90% van de gebruiksscenario's overschrijdt 256K context niet" — wat je ook de andere kant op kunt lezen: er loopt nog zo'n 10% gebruikers rond die K3 staan fijn te stampen op lange context.
En dan is er de regel die in de K3-docs verstopt zit: "we raden aan een nieuw gesprek te starten voordat je naar K3 overschakelt." Dat was bedoeld als vriendelijk advies. Heel veel mensen hebben het totaal niet begrepen — ze namen een gesprek dat al was opgestapeld tot 200K+, schakelden het over naar K3, en duwden het helemaal door naar de 1M-limiet voordat auto-compact ingreep. Geen enkel abonnement overleeft dat. Die doc-regel leest eerder als een preventieve PR-blusactie dan als iets anders.
Toen GPT 5.6 Sol in Codex de default context-window optilde van 272K naar 372K, kreeg het meteen kritiek omdat "tokens niet lang meegingen". Tibo moest nog uitleg posten dat het verschil van Auto Compact tussen de twee tiers niet eens zo groot was, maar de druk hield stand en ze hebben de default stilletjes teruggedraaid. Context default maximaal zetten is ontwerp waar niemand je voor bedankt.
🔍 "Mijn cache-hit-rate is 98%" is eigenlijk een waarschuwing
In de community zie je mensen opscheppen over cache-hit-rates van 98% of 99%, alsof het bewijst dat ze zuinig bezig zijn. Die intuïtie staat vrijwel zeker op zijn kop.
Op harness-niveau variëren cache-hit-rates niet zoveel tussen leveranciers. Een abnormaal hoge hit-rate betekent meestal precies één ding: je leunt zwaar op lange context — en lange context is het dure stuk. "Hoge hit-rate", andersom gelezen, is dus een afkorting voor "ik geef het meest uit, precies daar waar het het meest kost."
Blijft staan dat niet elk scenario lange context nodig heeft. Leer context actief te beheersen en die prijzige modellen worden net gebruikbaar. Ben je het type dat één gesprek helemaal leegdraait en wacht op de 1M auto-compact, dan gaat — buiten DeepSeek en MiMo om — elk ander model waarschijnlijk je budget opblazen.
🏷️ Wordt de 256K-versie goedkoper? Vast niet
Heel wat mensen gokken erop of dit nieuwe model-ID tegen een lagere prijs komt. Vast niet — zelfde prijs. De officiële prijsfactor wordt vooral aangejaagd door long-context-invoer en cache-hit-overhead, niet doordat het model zelf goedkoper is geworden.
In gemiddelde-termen komt het verschil uit rond 3×. Het is alleen zo dat de meeste gesprekken nooit in de buurt van 1M komen, dus de officiële lijn geeft een conservatief "geschat 2×."
Onder de 256K-cap ligt de gemiddelde context-lengte rond 150K; onder de 1M-cap ligt het gemiddelde dichter bij 600K — en op cache-prijsstelling alleen al staat een 4× verschil. Eén prompt gemiddeld zo'n 8 bericht-turns; reken op 4K invoer en 600 tokens uitvoer per turn, en het daadwerkelijke aandeel invoer/uitvoer in je factuur is behoorlijk klein.
De winst in price-for-performance komt dus voort uit de handeling zelf — "lange context op model-config-niveau afkappen" — niet uit een prijsverlaging.
Daarom heeft Kimi de moeite genomen om een aparte versie van het model uit te brengen en lange context op config-niveau door te knippen. Dat is de enige move die de prijs-prestatie van het werk dat gebruikers écht doen, opschuift.
📊 In het wild: ruwweg een derde van het quota van de volledige versie
Enkele tests en stukjes trivia uit de comment-threads die de moeite waard zijn:
- Leuk weetje: zowel Codex als Cursor draaien op 1M-modellen, maar de context die je effectief kunt gebruiken is slechts 2–300K.
- Hoeveel verlies je écht: iemand draaide dezelfde taak en de 256K-build verbruikte zo'n 1/3 van het quota van de volledige versie — want grote context drijft op zichzelf het token-verbruik op. Gemeten tegen een gelijkwaardige voltooiingsstandaard kost dezelfde taak zo'n 40% van wat hij vroeger kostte.
- Langlopende taken: een taak van één tot twee uur in kimi cli verbrandde 5.53% van het weekquota; voorheen was dat minstens 10%+ per uur.
- Sneurt de kwaliteit: ja — je doet wat rework na review, waar de volledige versie vrijwel nooit rework nodig heeft.
- Rekenkracht op video en 1M: video-invoer en de 1M-window schrappen halveert de rekenkracht-eis minimaal.
Voor iedereen op het 199-abonnement was het quota al ernstig ontoereikend — de getrimde versie geeft je wat ademruimte. En het kernpunt: de 1M-versie van K3 MAX blijft beschikbaar, in tegenstelling tot ChatGPT, waar 1M achter API-facturering zit.
Op het goedkope tier na krijg je er dus nog een optie bij (die meteen ook de officiële rekenlast vermindert). Alles meevaller, geen keerzijde.
🎯 De kern
Voor het gros van de mensen is lange context een Token-moordenaar — buiten DeepSeek en MiMo, met hun rotslage cache-prijzen, is elk ander model stilletjes je saldo aan het leegtrekken.
Kimi K3-256K legt een cap op config-niveau en beheert namens de gebruiker de uitgave-houding. Voor een team wiens rekenkracht altijd krap staat, is dat een behoorlijke zet. Wat écht duur is, was nooit het model — het is de "oneindigheid" waarvan je dacht dat je hem kon betalen.
Gebaseerd op publieke discussie in de developer-community en eigen tests rond de release van Kimi K3-256K. Cijfers en meningen komen uit community-feedback en dienen enkel ter referentie; voor de feitelijke facturering volg je de officiële bronnen van Moonshot.