Kimi K3 a gyakorlatban: tapasztalatok és összehasonlítás a Claude Code-dal

Így sikerült a szerző kísérlete#

A Kimi K3 2026. július 16-án indult. 2,8 billió paramétere van, egymillió tokenes kontextusablaka, nyílt súlyai, és első helyezést ért el egy vak frontend-összehasonlításban. Az architektúrájáról, benchmarkjairól és árairól minden részletet összegyűjtöttem a Kimi K3 és Claude Code teljes összehasonlító értékelésében, ezért itt nem ismétlem meg őket.

Az értékelés végén ezt írtam: a kockázat az, hogy egy nap elmegy a beállításra; a várható előny pedig az, hogy a második héttől csökken a számla. A kísérletet a saját feladataimon végeztem el.

Az első néhány óra valóban izgalmas. A modell lelkesen felveszi a feladatot, összefüggő frontendmunkát készít, és nem riad vissza a nagy fájloktól. Ezért írtam a csatornában, hogy kellemesen meglepődtem. A problémák a hosszú munkamenetekben, több ügynökkel, az ismétlődő szerkesztési körök során és este, a terminálnál jelentkeztek.

Végül visszaálltam az előző megoldásra. Íme, mi vezetett ehhez a döntéshez, számokkal és elsődleges forrásokra mutató hivatkozásokkal, hogy mindent magad is ellenőrizhess.

Miért mutatják a benchmarkok, hogy a Kimi K3 felülmúlja Claude-ot?#

Íme a benchmarkok, amelyekben a Kimi K3 felülmúlja Claude Fable 5-öt:

Az llm-stats állította össze a benchmarkokat; minden sor Claude Fable 5-tel való összehasonlítást mutat.

A számok valósak. Ugyanennek az összesítésnek mind a 35 benchmarkjában Claude Fable 5 22-t nyer, Kimi K3 tizenkettőt, és egy döntetlen születik.

Érdekesebb, hogy miben marad el a Kimi K3. A kódolási benchmarkokon mért hátránya mérsékelt, 4–5 pont. Tudásban és következtetésben gyengébben teljesít: a HLE-n Claude csaknem 10 ponttal vezet. Pontosan ez az, amikor egy hosszú feladat elakad: először meg kell érteni, és csak utána lehet írni.

A Moonshot így fogalmaz a kiadási bejegyzés fő részében:

Miért tűnik a Kimi K3 a gyakorlatban kétszer olyan lassúnak?#

Az összehasonlítás a Claude Opus 4.8-at használja, ez az a Claude-verzió, amelyről teljes sebességmérés készült.

A Kimi K3 hamarabb válaszol, ezért szubjektíven gyorsabbnak tűnik egy rövid beszélgetésben. Munka közben viszont másra megy el az idő: arra, hogy milyen lassan érkezik meg a teljes válasz. Ebben majdnem a felével marad el, hosszú válasznál pedig a különbség percekké adódik össze.

A Kimi Code másodpercenként 180–260 tokent hirdet, és ez a szám meggyőzőnek tűnik a saját 34.7-es értékem mellett. Ez az előző generáció sebességre optimalizált buildjére, a K2.7 Code HighSpeedre vonatkozik. A Kimi K3-nak egyáltalán nincs ilyen buildje, a független benchmark pedig magát a Kimi K3-at méri.

Az a munkamenet, amely a hetedik hibánál megszakad, és ismételt hívásokkal égeti a tokeneket, kontextusmérnöki hiba; itt másodlagos a modellválasztás.

Hová tűnnek a tokenek, ha a következtetést nem lehet kikapcsolni?#

Lejjebb veheted az erőfeszítési szintet; a dokumentáció három szintet sorol fel: alacsony, magas és maximális. A következtetést azonban nem lehet teljesen kikapcsolni: a dokumentáció kifejezetten kimondja, hogy a Kimi K3 esetében a következtetés és az előzmények tárolása mindig engedélyezve van. Közvetlen API-hívásnál alapértelmezés szerint a maximális szint van beállítva, és a legtöbb wrapperprogram nem módosítja ezt.

Minden forduló több ezer kimeneti tokent ad hozzá, milliónként $15 áron. Ráadásul a Moonshot megköveteli, hogy az asszisztens teljes üzenetét visszaküldd, beleértve a következtetési előzményeket is, ezek a kimeneti tokenek pedig a következő fordulóban újra bemeneti tokenekké válnak.

Vagyis kétszer fizetsz ugyanazért a következtetésért: először, amikor a modell megírja, majd amikor visszaküldöd a modellnek.

Az összesített indexen a Kimi K3 21%-kal kevesebb kimeneti tokent használ az elődjénél, a K2.6-nál. A modell a saját korábbi változatához képest takarékosabb lett. Claude ugyanazokon a feladatokon továbbra is kevesebbet használ.

A „hi” promptot 86 tokenként számlázzák. A háttérben egy körülbelül 85 tokenes rejtett rendszerprompt található, amelyért minden kérésnél fizetsz.

Külön értékelésem van arról, hogyan számold ki a használatodat, és hol ellenőrizheted a fennmaradó egyenlegedet: mennyi tokent ad a Claude Pro és Max. A számítási logika ugyanaz; csak az árak változnak.

Mi történik, ha a modell következtetés közben elakad?#

Így néz ki. A modell gondolkodni kezd, de ahelyett, hogy továbbfejlesztené a gondolatmenetét, a szöveg ismétlésbe csúszik: ugyanaz a szó, aztán szótagtöredékek, vég nélkül. A feladat megáll, miközben a tok számlálója tovább pörög.

A Moonshot ismert problémái között július 28-án megjelent beszámoló leírja, ahogy a Kimi K3 egymás után hatszor próbálja beolvasni ugyanazt a fájlt, hétszer kapja meg az „üres műveleti hívás, a fájl az előző olvasás óta nem változott” elutasítást, majd úgy zárja le a fordulót, mintha semmi sem történt volna. A Kimi CLI hibakövetőben a szerző ugyanilyen elakadás négy változatát sorolja fel—olvasás, csere, tesztelés és elemzés—, majd egyetlen mondatban foglalja össze:

A Moonshot közvetlenül megnevezi az okot. A modellt olyan módban tanították, amely megőrzi a következtetési előzményeket, ezért a korábbi következtetéseit teljes egészében vissza kell kapnia. Ha az előzmény hiányosan érkezik meg, a modell megpróbálja újra felépíteni a választ, ugyanazt az eszközhívást állítja elő, és újabb hurokba kezd.

Egy harmadik féltől származó kérésirányító elemzésének szerzője ugyanerre jut: a Kimi annyira szigorú, hogy elutasítja a hiányos következtetési előzményű kéréseket. Egy külső wrapper nem tud erről a szigorúságról, és megcsonkítja az előzményeket.

Miért esik szét a többügynökös beállítás a Kimi K3-mal?#

A hivatalos Moonshot-dokumentáció világosan kimondja: az API-juk még nem támogatja a WebFetch-et. Más szóval a Claude Code, amely rendszerint felkeres egy oldalt az interneten, ezt a Kimi K3-mal nem tudja megtenni. Megoldásként kézzel beillesztheted a tartalmat, vagy csatlakoztathatsz egy harmadik féltől származó eszközt.

A Claude Code igény szerint tudja betölteni az eszközöket, és tool_reference típusú szolgáltatásblokkot helyez az előzményekbe. A Kimi nem fogadja el ezt a típust, és 400-as hibát küld vissza. Ezt csendben teszi, sem a mezőt, sem az okot nem nevezi meg:

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

Összehasonlításképpen, így néz ki ugyanez a hiba az Anthropic natív API-ján, ahol a szerver legalább megnevezi a mezőt és felsorolja az elfogadott típusokat:

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'

Ez a különbség számít. Az első üzenetből lehetetlen kideríteni a hiba okát: sem a kliens, sem a mögötte álló személy nem tudja megmondani, melyik blokkot utasította el a rendszer. Pontosan erre panaszkodnak a beszámolók szerzői. A szolgáltatóváltó eszközök fejlesztői már azt javasolják, hogy a Kimi esetében alapértelmezés szerint kapcsolják ki a halasztott eszközbetöltést, vagy jelöljék a Moonshot API-t úgy, hogy nem fogadja el ezeket a blokkokat.

A következményt egy külön beszámoló írja le, amelyet július 17-én nyitottak meg, és még mindig nem válaszoltak rá. A szerző egy munkamenetben hétszer találkozott ezzel a hibával. Az első hat után a munkamenet még működött; a hetedik végleg leállította: utána még az egyszerű „continue” szöveg beírása is összeomlást okozott. A szerző külön megjegyzi, hogy messze nem érte el a kontextuskorlátot, tehát az „előzmény túl hosszú volt” magyarázat nem állja meg a helyét.

Íme a Moonshot API által elfogadott és elutasított blokk­típusok összefoglalása:

A „kompatibilis” szó itt csak a kérés formátumát írja le. Minden más eltér: mely blokktípusokat fogadja el a rendszer, mit kell tartalmaznia az előzménynek, és egyáltalán mely eszközök érhetők el.

Mi nem vihető át a Kimi K3-ra?#

A kiadási bejegyzés korlátozásokról szóló része szó szerint ezt mondja:

A modell fejlesztője azt mondja: használjátok a mi kliensünket; nem garantáljuk, hogy másoké hogyan viselkedik.

Ugyanennek a szakasznak a második pontja még egy dolgot megmagyaráz, amit korábban a modell makacsságának tulajdonítottam:

A CLAUDE.md fájlomat az ellenkező működésre írtam: kérdezzen, mutasson tervet, és várjon a megerősítésre. Az utasítások még mindig ott vannak, de most egy más temperamentumú modell olvassa őket.

Ha több ügynökhöz egyetlen szabályfájlt szeretnél használni, ezt a beállítást külön is bemutattam: egy utasításfájl a Claude Code-hoz, a Codexhez és a Cursorhoz.

Mennyibe került valójában a Kimi K3?#

Először nézzük az árakat, amelyek a Kimi K3-nak kedveznek:

A Kimi árai a kontextus-gyorsítótárazás dokumentációjából származnak; a jobb oldali oszlop a Claude Opus 5 árait mutatja 2026. július 30-i állapot szerint.

A Kimi cache-e automatikus, nem kapcsolható ki, és a kérés elején lévő hash azonosítja. A rendszerprompt vagy az eszközlista bármilyen szerkesztése teljesen törli az üzenetek gyorsítótárát.

Így dolgozik a Claude Code egy átlagos munkanapon:

1. A feladat előrehaladtával külső eszközöket csatlakoztat és választ le.
2. Szükség esetén, igény szerint tölti be az eszközöket.
3. Más eszközkészlettel indít alügynököket.
4. Hozzáadja az utasításfájlt a rendszerpromptjához.
5. A kontextus tömörítésekor újraépíti az előzményeket.

A lista minden egyes eleme visszaállítja a kérés kezdetét, és így a gyorsítótárat is. A bemeneti tokenek ára újra milliónként $3 lesz 30 cent helyett—tízszer annyi. Ehhez adódik a folyamatos következtetés kimeneti tokenenként milliónként $15-ért, az azonos tokenek pedig a következő fordulóban bemenetként visszatérnek. Így állíthat elő egy alacsony listaárú modell váratlanul magas számlát.

Az OpenCode összesített adatai szerint csaknem 280,000 éles munkamenet alapján egy átlagos Kimi K3-munkamenet $1.86-ba kerül, átlagosan 3.1 millió tokenes használattal. Ez az adat azon múlik, hogy a bemeneti tokenek 93%-a eléri a cache-t. Változtasd meg a kérés elejét, és ez az érték már nem érvényes rád.

A Kimi-csomagok ára $19, $39, $99 és $199. A kvóta az egész tagság közös keretéből származik, hetente visszaáll, a fel nem használt mennyiség átvitele nélkül, és gördülő ötórás időablakot használ. A csomagokról szóló értékelés így fogalmaz: négy terminálon futtatva a folyamatosan következtető Kimi K3 gyorsan felhasznál egy ötórás időablakot.

A $99-os csomag kódolási kvótája összemérhető az Anthropic $200-os csomagjával, ami ellentmond a saját álláspontomnak. A Kimi tokenenként olcsóbb, de ezt már nem látod az esti számlán.

Miben jó objektíven a Kimi K3?#

1. Frontend. Első helyezés aktív fejlesztők vak összehasonlításában. Rendezett, jó ízlésű elrendezéseket készít.
2. Mennyiség. Egymillió tokenes kontextusablak, a hosszú fájlok sem riasztják el. Egy nagy adattár elemzése és feltérképezése éppen neki való feladat.
3. Első válasz. Az első tokenig eltelt idő fele Claude-ének. Rövid beszélgetésben ez érezhető és kellemes.
4. Tokenenkénti ár. Körülbelül a Claude Opus 5 árának 60%-a. Ha a kérés kezdete nem változik, ez valódi megtakarítást jelent nagy, ismétlődő munkaterhelésnél.
5. Nyílt súlyok. A modell nincs egyetlen szolgáltatóhoz kötve.

Az utolsó ponthoz tartozik egy kitétel. Egy ilyen modell otthoni futtatása nem reális: a súlyai még tömörített formában is terabájtos nagyságrendűek. Itt a nyitottság azt jelenti, hogy nem függsz egyetlen szolgáltatótól.

Hogyan teszteld mindezt egyetlen este alatt?#

1. Állítsd be a hozzáférést az útmutató szerint. A három környezeti változót és a modellenkénti helyettesítést a Kimi K3 és Claude Code összehasonlító értékelésében írtam le. A beállítást a /status paranccsal ellenőrizd: a Kimi nem fog megjelenni a modellválasztó menüben, mert az beépített aliaslistát használ, és ehhez nem kell hozzányúlnod.
2. Távolítsd el a régi kulcsot. Ha korábban beállítottad az ANTHROPIC_API_KEY változót, töröld. Az ANTHROPIC_AUTH_TOKEN változóval együtt ütközést okoz, és minden ok nélkül hitelesítési hibát kapsz.
3. Azonnal kapcsold ki a halasztott eszközbetöltést. Az első futtatás előtt tedd meg, ne az első munkamenet összeomlása után.
4. Ne válts modellt a feladat közben. Ha Kimi K3-mal kezdtél, Kimi K3-mal fejezd be. Fordítva is ugyanez igaz. Ez a Moonshot közvetlen követelménye; fent idéztem.
5. Valódi saját feladatot használj. Olyat, amin tegnap dolgoztál, minden kuszaságával és befejezetlen szálával együtt. Egy kígyós játék nem mutatja meg a különbséget: az csak hosszabb távon válik láthatóvá.
6. Írj fel két számot. Hány percig tartott, és mennyi pénzt költöttél azon az estén. Hasonlítsd össze egy szokásos Claude-os estével.
7. Külön kövesd az állásidőt. Amikor az ügynök lefagy, hurokban ugyanazt a fájlt olvassa, vagy hibával válaszol—ez is része a költségnek.

Ha az esti számla a vártnál magasabb, szinte mindig a cache az oka: számold meg, hányszor állt vissza a kérés kezdete azon az estén. A tokenenkénti árnak ehhez kevés köze van.

Mit tartottam meg végül?#

A csatorna olvasói, akik velem együtt tesztelték a modellt, egymástól függetlenül ugyanerre a beállításra jutottak: a Kimi K3-at a tárház átvizsgálására és második vélemény kérésére használják, a fő munkát pedig a megszokott ügynökükre hagyják. Ez a megoldás azért működik, mert nem kell áthelyezni a wrappert vagy elrontani azt, ami már működik.

Így is megfogalmazhatjuk: egy teljes feladat megy a Kimi K3-hoz; az eszközöket és alügynököket használó hosszú lánc a Claude Code-hoz. Minél több eszközváltást igényel egy feladat, annál többe kerül a Kimi K3-mal, és annál nagyobb az esélye a munkamenet hibájának.

Külön értékelésem van arról, hogyan osszuk ki a szerepeket két ügynök között anélkül, hogy összekevernénk őket: három módszer két ügynökkel való munkára.

A benchmarkok arra a kérdésre adnak választ, hogy „ki az erősebb laboratóriumi körülmények között?” Az esti számlád és az elvégzett munkák listája arra, hogy „neked ki az erősebb?” Ha a két válasz eltér, bízz a másodikban: te számoltad ki, nem a marketingosztály.

Miután mindezt átgondoltam, magam számára ezt döntöttem el: bármit mondanak is az új modellekről, a vezető továbbra is vezető. A Claude Code marad a fő motorom.