Kimi K3 i praksis: hands-on erfaringer og en sammenligning med Claude Code

Sådan gik forfatterens eksperiment#

Kimi K3 blev lanceret den 16. juli 2026. Den har 2,8 billioner parametre, et kontekstvindue på en million tokens, åbne vægte og førstepladsen i en blind frontend-sammenligning. Jeg har samlet alle detaljerne om arkitekturen, benchmarks og priser i den fulde anmeldelse af Kimi K3 sammenlignet med Claude Code, så jeg gentager dem ikke her.

Til sidst i den anmeldelse skrev jeg: Risikoen er at miste en dag på opsætning; gevinsten er en regning, der falder fra den anden uge og frem. Jeg afprøvede eksperimentet på mine egne opgaver.

De første timer er virkelig spændende. Modellen tager ivrigt fat på en opgave, laver sammenhængende frontendarbejde og tøver ikke over store filer. Derfor skrev jeg i kanalen, at jeg var behageligt overrasket. Problemerne viste sig i lange sessioner, med flere agenter, gennem gentagne redigeringsrunder og om aftenen ved terminalen.

Til sidst rullede jeg tilbage. Her er, hvad der førte til den beslutning, med tal og links til primærkilder, så du selv kan kontrollere det hele.

Hvorfor viser benchmarks, at Kimi K3 slår Claude?#

Her er de benchmarks, hvor Kimi K3 slår Claude Fable 5:

llm-stats har samlet benchmarksene; hver række sammenligner med Claude Fable 5.

Tallene er reelle. På tværs af alle 35 benchmarks i den samme sammenstilling vinder Claude Fable 5 22, Kimi K3 vinder tolv, og én ender uafgjort.

Mere interessant er det, hvor Kimi K3 kommer til kort. Dens efterslæb på kodningsbenchmarks er beskedent, 4–5 point. Den halter bagefter inden for viden og ræsonnering: På HLE kommer Claude næsten 10 point foran. Det er præcis dér, en lang opgave rammer en mur: Først skal man forstå, og først derefter kan man skrive.

Moonshot udtrykker det sådan i hovedafsnittet af sit lanceringsindlæg:

Hvorfor føles Kimi K3 dobbelt så langsom i praksis?#

Sammenligningen bruger Claude Opus 4.8, den Claude-version med en komplet hastighedsmåling.

Kimi K3 svarer hurtigere, så den føles subjektivt hurtigere i en kort chat. På arbejdet bruger man tiden på noget andet: Hvor langsomt hele svaret kommer. Her taber den med næsten halvdelen, og ved et langt svar løber forskellen op i minutter.

Kimi Code reklamerer med 180–260 tokens i sekundet, og det tal virker overbevisende sammenlignet med mine 34.7. Det henviser til den forrige generations hastighedsvariant, K2.7 Code HighSpeed. Kimi K3 har slet ikke sådan en variant, og det uafhængige benchmark måler Kimi K3 selv.

En session, der bryder sammen ved den syvende fejl og brænder tokens af på gentagne kald, er en fejl i kontekstteknikken; modelvalget er sekundært her. Hele opsætningen hviler på tre søjler: AI-klon + Second Brain + Context Engineering. Det er de tre søjler, som AI ikke kan undvære uden at hallucinere.

Hvor bliver tokens af, hvis ræsonnering ikke kan slås fra?#

Du kan sænke indsatsniveauet; dokumentationen angiver tre: lavt, højt og maksimalt. Men ræsonnering kan ikke slås helt fra: Det står udtrykkeligt, at ræsonnering og lagring af dens historik altid er aktiveret for Kimi K3. Ved direkte API-kald er det maksimale niveau valgt som standard, og de fleste wrapperprogrammer ændrer det ikke.

Hver tur tilføjer tusindvis af outputtokens til $15 pr. million. Desuden kræver Moonshot, at du returnerer hele assistentens meddelelse, inklusive dens ræsonneringshistorik, og de outputtokens bliver til inputtokens igen i næste tur.

Så du betaler to gange for den samme ræsonnering: først, når modellen skriver den, og derefter, når du sender den tilbage til modellen.

På det samlede indeks bruger Kimi K3 21% færre outputtokens end forgængeren K2.6. Modellen er blevet mere økonomisk sammenlignet med sin egen tidligere version. Claude bruger stadig mindre på de samme opgaver.

Prompten “hi” faktureres som 86 tokens. Under overfladen findes en skjult systemprompt på omkring 85 tokens, og du betaler for den ved hver forespørgsel.

Jeg har en separat anmeldelse af, hvordan du beregner dit forbrug og finder din resterende saldo: hvor mange tokens Claude Pro og Max giver dig. Beregningslogikken er den samme dér; kun priserne ændres.

Hvad sker der, når modellen går i stå i sin ræsonnering?#

Det ser sådan ud. Modellen begynder at tænke, men i stedet for at udvikle tanken glider teksten over i gentagelser: Det samme ord, derefter stavelsesfragmenter, i det uendelige. Opgaven går i stå, mens tokenmåleren bliver ved med at køre.

En rapport fra 28. juli i Moonshots kendte problemer beskriver, hvordan Kimi K3 forsøger at læse den samme fil seks gange i træk, får afvisningen “no-op call, file hasn’t changed since the previous read” syv gange og derefter afslutter turen, som om intet var sket. I Kimi CLI-issuesporingen opremser forfatteren fire varianter af den samme type fastlåsning – læsning, erstatning, test og analyse – og opsummerer det i én sætning:

Moonshot angiver årsagen direkte. Modellen blev trænet i en tilstand, der bevarer ræsonneringshistorikken, og den skal have hele sin tidligere ræsonnering tilbage. Hvis historikken kommer ufuldstændigt frem, forsøger modellen at genskabe svaret, producerer det samme værktøjskald og starter endnu en løkke.

Forfatteren til en analyse i en tredjepartsforespørgselsrouter stiller samme diagnose: Kimi er så streng, at den afviser forespørgsler med ufuldstændig ræsonneringshistorik. En ekstern wrapper kender ikke til denne strenghed og afkorter historikken.

Hvorfor falder en opsætning med flere agenter fra hinanden med Kimi K3?#

Moonshots officielle dokumentation siger det ligeud: Deres API understøtter endnu ikke WebFetch. Med andre ord kan Claude Code, som normalt går online for at hente en side, ikke gøre det med Kimi K3. Løsningen er at indsætte indholdet manuelt eller forbinde et tredjepartsværktøj.

Claude Code kan indlæse værktøjer efter behov og indsætter en serviceblok af typen tool_reference i historikken. Kimi accepterer ikke denne type og returnerer en 400-fejl. Det sker uden nogen forklaring, hverken af feltet eller årsagen:

{"error":{"type":"invalid_request_error","message":"Invalid request Error"},"type":"error"}

Til sammenligning ser den samme fejl sådan ud på Anthropics oprindelige API, hvor serveren i det mindste angiver feltet og opremser de accepterede typer:

messages.166.content.0.tool_result.content.0: Input tag 'tool_reference' found
using 'type' does not match any of the expected tags: 'document', 'image',
'search_result', 'text'

Forskellen betyder noget. Den første meddelelse er umulig at diagnosticere: Hverken klienten eller personen bag den kan se, hvilken blok der blev afvist. Det er præcis det, forfatterne til rapporterne klager over. Udviklere af udbyderskiftere foreslår allerede, at indlæsning af værktøjer efter behov deaktiveres som standard for Kimi, eller at Moonshot API markeres som ikke-understøttende for disse blokke.

Konsekvensen beskrives i en separat rapport, oprettet den 17. juli og stadig ubesvaret. Forfatteren stødte på denne fejl syv gange i én session. Sessionen overlevede de første seks; den syvende afsluttede den for altid: Derefter fik selv den almindelige tekst “continue” den til at gå ned. Forfatteren bemærker særskilt, at kontekstgrænsen slet ikke var tæt på, så forklaringen “historikken var for lang” holder ikke.

Her er en oversigt over de bloktyper, Moonshot API accepterer og afviser:

Ordet “kompatibel” beskriver her kun forespørgselsformatet. Alt andet er forskelligt: Hvilke bloktyper der accepteres, hvad historikken skal indeholde, og hvilke værktøjer der overhovedet er tilgængelige.

Hvad følger ikke med Kimi K3?#

Afsnittet om begrænsninger i lanceringsindlægget siger det ordret:

Modellens udvikler siger: Brug vores klient; vi garanterer ikke for, hvordan en andens fungerer.

Det andet punkt i samme afsnit forklarer endnu en ting, jeg havde tilskrevet modellens stædighed:

Min CLAUDE.md blev skrevet til den modsatte vane: Spørg, vis en plan, og vent på bekræftelse. Instruktionerne er stadig dér, men nu læses de af en model med et andet temperament.

Hvis du vil bruge én regelfil til flere agenter, har jeg beskrevet den opsætning særskilt: én instruktionsfil til Claude Code, Codex og Cursor.

Hvad kostede Kimi K3 egentlig?#

Først priserne, som er en fordel for Kimi K3:

Kimis priser stammer fra dokumentationen om kontekstcaching; kolonnen til højre viser priserne på Claude Opus 5 pr. 30. juli 2026.

Kimis cache er automatisk, kan ikke deaktiveres og identificeres ved hashen i begyndelsen af forespørgslen. Enhver redigering af systemprompten eller værktøjslisten rydder meddelelsescachen fuldstændigt.

Her er, hvad Claude Code gør i løbet af en almindelig arbejdsdag:

1. Tilslutter og frakobler eksterne værktøjer, efterhånden som opgaven skrider frem.
2. Indlæser værktøjer efter behov.
3. Starter underagenter med et andet sæt værktøjer.
4. Føjer instruktionsfilen til systemprompten.
5. Genopbygger historikken, når konteksten komprimeres.

Hvert punkt på denne liste nulstiller begyndelsen af forespørgslen og dermed cachen. Inputtokens koster igen $3 pr. million i stedet for 30 cent – ti gange mere. Dertil kommer konstant ræsonnering til $15 pr. million outputtokens, og de samme tokens kommer tilbage som input i næste tur. Sådan kan en model med en lav listepris give en uventet regning.

Ifølge OpenCodes samlede data koster en gennemsnitlig Kimi K3-session $1.86 på tværs af næsten 280,000 aktive sessioner og bruger i gennemsnit 3.1 millioner tokens. Det tal forudsætter, at 93% af inputtokens rammer cachen. Ændr begyndelsen af forespørgslen, og tallet gælder ikke længere for dig.

Kimi-abonnementer koster $19, $39, $99 og $199. Kvoten kommer fra en fælles pulje for hele medlemskabet, nulstilles ugentligt uden overførsel af ubrugte mængder og bruger et rullende femtimersvindue. Anmeldelsen af abonnementerne beskriver det sådan: Fire terminaler, der kører Kimi K3 med konstant ræsonnering, bruger hurtigt et femtimersvindue op.

Kodekvoten i abonnementet til $99 svarer til Anthropics abonnement til $200, hvilket går imod min egen holdning. Kimi er billigere pr. token, men det kan man ikke længere se på aftenens regning.

Hvor er Kimi K3 objektivt god?#

1. Frontend. Førsteplads i en blind sammenligning udført af aktive udviklere. Den laver layout pænt og med en god æstetisk sans.
2. Omfang. Et kontekstvindue på en million tokens, og lange filer skræmmer den ikke. Analyse og kortlægning af et stort kodearkiv er lige dens type opgave.
3. Første svar. Tiden til første token er halvdelen af Claudes. Det er mærkbart og rart i en kort samtale.
4. Pris pr. token. Omkring 60% af prisen på Claude Opus 5. Hvis begyndelsen af forespørgslen ikke ændrer sig, giver det reelle besparelser ved store, gentagne arbejdsbelastninger.
5. Åbne vægte. Modellen er ikke låst til én udbyder.

Der er dog et forbehold ved det sidste punkt. Det er urealistisk at køre en model som denne derhjemme: Selv i komprimeret form fylder vægtene terabytes. Her betyder åbenhed uafhængighed af en enkelt udbyder.

Sådan kan du selv teste alt dette på én aften#

1. Sæt adgangen op ved hjælp af instruktionerne. Jeg beskrev de tre miljøvariabler og modelspecifikke udskiftninger i anmeldelsen af Kimi K3 sammenlignet med Claude Code. Kontrollér opsætningen med kommandoen /status: Kimi vises ikke i menuen til valg af model, fordi den har en indbygget liste over aliasser, og den behøver du ikke at røre ved.
2. Fjern den gamle nøgle. Hvis du tidligere havde ANTHROPIC_API_KEY sat, skal du fjerne den. Sammen med ANTHROPIC_AUTH_TOKEN skaber den en konflikt, så du får en uautoriseret-fejl uden grund.
3. Slå straks indlæsning af værktøjer efter behov fra. Gør det før første kørsel, ikke efter at den første session går ned.
4. Skift ikke model midt i opgaven. Hvis du startede på Kimi K3, så afslut på Kimi K3. Det omvendte gælder også. Det er et direkte krav fra Moonshot; jeg citerede det ovenfor.
5. Brug en rigtig opgave fra dit eget arbejde. En, du arbejdede på i går, med alt rodet og de uafsluttede tråde. Et slangespil vil ikke vise forskellen: Den viser sig først over længere tid.
6. Skriv to tal ned. Hvor mange minutter det tog, og hvor mange penge du brugte den aften. Sammenlign med en normal aften med Claude.
7. Hold styr på inaktiv tid separat. Når agenten hænger, læser den samme fil i en løkke eller svarer med en fejl, er det også en del af omkostningen.

Hvis aftenens regning bliver højere end forventet, skyldes det næsten altid cachen: Tæl, hvor mange gange begyndelsen af forespørgslen blev nulstillet den aften. Prisen pr. token har ikke meget med det at gøre.

Hvad jeg endte med at beholde#

Læsere af kanalen, som testede modellen sammen med mig, nåede uafhængigt frem til samme opsætning: De beder Kimi K3 undersøge kodearkivet og give en anden vurdering, mens de overlader hovedarbejdet til deres velkendte agent. Opsætningen fungerer, fordi den ikke kræver, at man skifter wrapper eller ødelægger det, der allerede virker.

Man kan sige det sådan: En hel opgave gives til Kimi K3; en lang kæde med værktøjer og underagenter gives til Claude Code. Jo flere skift mellem værktøjer en opgave kræver, desto mere koster den med Kimi K3, og desto større er risikoen for en ødelagt session.

Jeg har en separat anmeldelse af, hvordan man fordeler roller mellem to agenter uden at blande dem sammen: tre måder at arbejde med to agenter på.

Benchmarks besvarer spørgsmålet “hvem er stærkest under laboratorieforhold?” Aftenens regning og din liste over afsluttet arbejde besvarer spørgsmålet “hvem er stærkest for dig?” Når de to svar er forskellige, så stol på det andet: Det har du selv regnet ud, ikke marketingafdelingen.

Efter at have set på alt dette besluttede jeg mig: Uanset hvad folk siger om nye modeller, er en leder stadig en leder. Claude Code forbliver min hovedmotor.

Den komplette opsætning til vibe coding: AI-klon + Second Brain + Context Engineering.