⚡ Oppsummering
Moonshot (Kimi) har sluppet Kimi K3-256K: samme evner som fullversjonen av K3, videodata er fjernet, og kontekstvinduet er låst til 256K. Ved første øyekast ser det ut som en «leddelt» utgave, men etter at utviklermiljøet regnet seg gjennom regnestykket, er konklusjonen slående entydig — dette er det fornuftige valget, fordi lang kontekst i seg selv er den største kostnadsdraperen.
For det store flertallet av kodeoppgaver sitter hovedkostnaden ikke i inn- og utdata, men i konteksten. Dra konteksten fra 50K opp mot millionklassen, og gjennomsnittlig token-forbruk øker med et helt ti-tall — med mindre cache er ekstremt billig, er dette en utvetydig token-snikmorder. At Kimi kapper lang kontekst allerede på konfigurasjonslaget, tilsvarer at noen skrur av den dyreste bryteren for deg.
💸 Hvorfor lang kontekst er så dyrt
Ett forhold er stadig bekreftet: i kodeoppgaver, så lenge cache-prisen ikke er presset ned, ligger hovedkostnaden for hele sesjonen i den kontekst-biten av token-strømmen. Jo større du gjør vinduet, jo mer frakter du en stadig voksende fjellhaug frem og tilbake i hver runde.
Men dette har en forutsetning — lang kontekst er bare «begrenset dyr» når cache-treff er billig nok. Akkurat nå er det bare DeepSeek og MiMo som faktisk har presset cache-prisen ned. Det er derfor bare deres millionkontekst kan kalles «overkommelig». Hos de øvrige er prisingen av lang kontekst rett og slett absurd, og det fornuftige valget er alltid kort kontekst.
Et enkelt regnestykke: 1M kontekst ligger i snitt på rundt 500K, og sammenlignet med 50K kontekst er kostnaden hele 10 ganger høyere.
Vane med å pakke sammen rundt 100K holder gjennomsnittskonteksten nede på 50K; vane med å stable opp til 990K og la systemet autokompaktere, gir et snitt på 500K. Samme «langkontekst-modell», men sistnevnte koster 10 ganger så mye som førstnevnte. Selv innenfor 256K-kategorien: én samtale som løper til 200K, koster 4 ganger 50K-baselinjen.
Alt dette gjelder ikke når [cache-treff er billig]. Problemet er at cache-prisen hos de fleste hovedstrømsmodeller også er høy, så hovedkostnaden forblir kontekst, og lang kontekst vil uvegerlig drive brukskostnaden opp. Å begrense konteksten aktivt lar Agent/Harness-programvaren holde kontekststørrelsen under kontroll og kutte kostnaden kraftig.
🧠 De fleste har ikke noe begrep om «kontekst-administrasjon»
Det dypere problemet er brukeradferd. Svært mange mangler bevissthet om å «administrere kontekst aktivt» og overlater seg helt til Harness-lagets (Agent-programvaren) autokompaktering — og velger gjerne den dyreste modellen, for så å kjøre én eneste samtale i bordet helt til den fyller 1M før komprimering utløses.
Med en slik bruk er «kvoten er oppbrukt etter noen runder» nesten uunngåelig. At Kimis Feishu-gruppe blir gjort narr av for «lavt forbruk, borte etter noen få runder», henger sannsynligvis direkte sammen med akkurat dette mønsteret. Gruppens offisielle kunngjøring sa at «90 % av bruksfall ikke overstiger 256K kontekst» — snudd på hodet: hele 10 % kjører altså fortsatt K3 med lang kontekst i det varmeste laget.
Enda morsommere er den setningen i K3-dokumentasjonen: «vi anbefaler at du starter en ny sesjon før du bytter til K3». Egentlig et vennlig råd, men mange lot til å ikke fange det i det hele tatt: de tok en gammel sesjon som allerede lå på 200K+, byttet direkte til K3 og presset den helt mot 1M-grensen før autokompaktering — denne bruken vil knekke hvilket som helst abonnement. Den offisielle formuleringen virker mest som et forsøk på å ligge i forkant av en PR-krise.
Tidligere økte GPT 5.6 Sol standard Context Window i Codex fra 272K til 372K, og ble umiddelbart bebreidet av mange for at «token ikke varer». Tibo la til og med ut et innlegg for å forklare at Auto Compact ikke gir så stor forskjell mellom de to nivåene, men til slutt holdt det ikke — grensen ble stille tilbakestilt til standard. Å maksere konteksten som standard er en utakknemlig design.
🔍 «Jeg har 98 % cache-treff» er faktisk et faresignal
I miljøet skryter folk jevnlig av cache-treff på 98 % og 99 %, og føler at de bruker modellen sparsomt. Den intuisjonen er sannsynligvis feil vending.
Cache-treff i Harness-laget varierer knapt mellom leverandørene. Et unormalt høyt treff betyr ofte at du bruker lang kontekst tungt — og lang kontekst er akkurat den dyreste biten. Så et «høyt treff» kan like gjerne oversettes til «jeg bruker mest akkurat der det er dyrest».
Når alt kommer til alt, trenger ikke alle scenarioer lang kontekst. Lær deg å kontrollere konteksten aktivt, så blir de høyt prisede modellene så vidt brukbare; hvis du er typen som «kjører én samtale i bordet og venter på at konteksten fyller 1M før autokompaktering», vil alle modeller unntatt DeepSeek og MiMo sannsynligvis spreng budsjettet ditt.
🏷️ Blir 256K-versjonen billigere? Antagelig ikke
Mange gjetter på om denne nye modell-ID-en vil bli billigere. Svært sannsynlig ikke — prisen ligger der den lå. Den offisielle prismultiplikatoren kommer i hovedsak fra inn-data for lang kontekst og kostnaden ved cache-treff, ikke fra at selve modellen har fått priskutt.
Sett opp mot hverandres gjennomsnitt åpner det seg et gap på rundt 3 ganger. Men de færreste får en enkelt sesjon helt opp mot 1M, og derfor holder produsenten seg til et konservativt «estimert 2 ganger».
Med 256K-grensen ligger gjennomsnittlig kontekstlengde på rundt 150K; med 1M-grensen ligger snittet på om lag 600K — alene på cache-pris gir det et gap på 4 ganger. Én prompt består i snitt av rundt 8 meldingsrunder; hvis vi antar 4K inn-data og 600 token ut-data per runde, er den reelle andelen inn-/ut-data-kostnad faktisk lav.
Forbedringen i pris-nytte kommer altså fra selve handlingen å kappe lang kontekst på modellens konfigurasjonslag — ikke fra et priskutt.
Nettopp derfor lanserer Kimi en separat versjon av modellen, som kapper lang kontekst allerede på konfigurasjonslaget — det er den eneste måten å faktisk løfte pris-nytte for brukernes virkelige oppgaver.
📊 I praksis: kvoteforbruket ligger på omtrent en tredjedel av fullversjonen
Noen få observasjoner og kuriositeter fra kommentarfeltet er verdt å ta med:
- Kuriositet: Både Codex og Cursor kobler til 1M-modeller, men den faktisk brukbare konteksten er bare 2–300K.
- Hva koster den kappede versjonen: En tester kjørte samme oppgave og fant at denne 256K-versjonen bruker omtrent 1/3 av kvoten til fullversjonen — fordi stor kontekst i seg selv øker token-forbruket; målt etter samme ferdigstillelsesstandard ligger forbruket på samme oppgave på rundt 40 % av før.
- Lange kjøringer: En lang oppgave på én til to timer i kimi cli ga et ukentlig kvoteforbruk på 5,53 %; tidligere lå det typisk på 10 %+ per time.
- Betyr det noe for kvaliteten: Ja — etter review kreves noe reparasjon/etterarbeid, mens fullversjonen nesten ikke krever rework.
- Regnekraft for video og 1M: Å fjerne video-inndata og 1M-kontekst minst halverer regnekraftbehovet.
For brukere på 199-abonnementet er kvoten i utgangspunktet altfor knapp; med den kappede versjonen kan du i det minste slippe litt løs. Og det avgjørende — 1M-versjonen av K3 MAX er fortsatt tilgjengelig, i motsetning til ChatGPT, hvor du ikke får brukt 1M uten API-fakturering.
Med andre ord: i tillegg til lavkostsegmentet får du ett valg til (og produsentens regnekraftforbruk går samtidig ned) — utelukkende til det bedre.
🎯 Oppsummert på én setning
For de aller fleste er lang kontekst en token-snikmorder — med unntak av DeepSeek og MiMo, som har ekstremt lav cache, tapper de andre stille og rolig saldoen din.
Med Kimi K3-256K får brukeren kontroll på forbruksmønsteret gjennom et tak på konfigurasjonslaget. For et team der regnekraften alltid er trang, er dette et ryddig trekk. Det som egentlig er dyrt, er aldri modellen — det er det «ubegrensede» du trodde du hadde råd til.
Denne artikkelen bygger på offentlig utviklerdiskusjon og tester rundt lanseringen av Kimi K3-256K. Tall og standpunkter kommer fra fellesskapet og er kun veiledende — endelig fakturering følger Moonshots offisielle priser.