Kimi K3-256k

• Kimi K3-256k रोज़मर्रा की coding के लिए बना मॉडल है, जो 256k context में K3 की result quality बनाए रखता है, जबकि 1M context वाले k3 की तुलना में लगभग आधा quota ही इस्तेमाल करता है
• Kimi Code, K3 और K2.7 Code को 4 model ID के रूप में देता है; k3 2.8T parameters और अधिकतम 1M context को support करता है, जबकि kimi-for-coding-highspeed लगभग 5~6 गुना तेज output देता है, लेकिन quota 3 गुना इस्तेमाल करता है
• k3 से k3-256k पर स्विच करते समय अगर मौजूदा context 256k से बड़ा है या उसमें video शामिल है, तो compatibility बनाए रखते हुए मुख्य जानकारी बचाने के लिए पहले compact चलाना होगा
• मॉडल या reasoning_effort बदलने पर मौजूदा context cache invalidate हो जाता है और फिर से prefill करना पड़ता है, इसलिए usage बढ़ सकता है; नए session में स्विच करना recommended है
• उपलब्ध मॉडल और context plan के अनुसार अलग होते हैं, और permission से अधिक होने पर 401 लौटता है. Third-party tools में सही model ID और context size·reasoning strength को सीधे सेट करना होगा

---

Kimi Code का model configuration

• Kimi Code, Kimi K3 और Kimi K2.7 Code को 4 model ID के रूप में देता है
  • k3: 2.8T parameters वाला flagship coding model, जो higher-tier plans में अधिकतम 1M context support करता है
  • k3-256k: Kimi K3 का 256k context version, जो consumption कम करने पर केंद्रित है
  • kimi-for-coding: code completion और रोज़मर्रा के development tasks के लिए उपयुक्त Kimi K2.7 Code
  • kimi-for-coding-highspeed: वही coding capability के साथ लगभग 5~6 गुना तेज output देने वाला K2.7 Code HighSpeed
• हर मॉडल की specs और usage conditions इस प्रकार हैं
  • k3
    • सामान्य speed पर चलता है और higher-tier members को अधिकतम 1M context देता है
    • reasoning_effort में low, high, max supported हैं और default high है
    • Moderato या उससे ऊपर में उपलब्ध है, और 1M context Allegretto या उससे ऊपर में मिलता है
    • image और video input ले सकता है
  • k3-256k
    • सामान्य speed पर चलता है और context 256k पर fixed है
    • reasoning_effort में low, high, max supported हैं और default high है
    • Moderato या उससे ऊपर के members इसे इस्तेमाल कर सकते हैं
    • केवल image input ले सकता है; video supported नहीं है
  • kimi-for-coding
    • सामान्य speed और 256k context देता है, और सभी members इसका उपयोग कर सकते हैं
    • Thinking:ON पर चलता है और image व video support करता है
  • kimi-for-coding-highspeed
    • 256k context में लगभग 6 गुना तेज output देता है, लेकिन quota 3 गुना इस्तेमाल करता है
    • Allegretto या उससे ऊपर में उपलब्ध है और Thinking:ON, image·video input support करता है

K3-256k का उपयोग और model switching

• k3-256k, 256k context range में k3 जैसा ही result देता है, जबकि 1M version की तुलना में लगभग आधा quota ही इस्तेमाल करता है
• यह रोज़मर्रा के Q&A, code completion, सामान्य feature development, और single file या छोटे file edits के लिए उपयुक्त है, लेकिन video input support नहीं करता

• K3 से K3-256k पर स्विच

  • अगर मौजूदा session context 256k से बड़ा है, तो Kimi Code CLI और Claude Code जैसे कुछ tools अपने-आप compact करते हैं
  • हर agent tool का handling अलग हो सकता है, इसलिए switch से पहले manually एक बार compact चलाकर context को 256k के भीतर compress करना recommended है
  • इससे session बनाए रखते हुए काम की मुख्य सामग्री बचाई जा सकती है
  • switch के बाद quota को अधिक समय तक इस्तेमाल किया जा सकता है
  • अगर conversation history में video file है, तो सीधे k3-256k पर स्विच नहीं किया जा सकता; पहले compact चलाना होगा

• K3-256k से K3 पर स्विच

  • अगर k3-256k 256k limit के करीब पहुँच गया है और आप compact से होने वाले information loss से बचना चाहते हैं, तो सीधे k3 1M पर स्विच कर सकते हैं
  • मौजूदा version में 256k से 1M पर स्विच करने से cache पर असर नहीं पड़ता

Cache और usage management

• मॉडल बदलने पर पिछले मॉडल में बना context cache hit नहीं होता, इसलिए उस context को फिर से prefill करना पड़ता है
• इसी वजह से switch के तुरंत बाद usage बढ़ा हुआ लग सकता है. नया model इस्तेमाल करते समय नया session शुरू करना बेहतर result और कम consumption के लिए फायदेमंद है

• Reasoning strength switch की लागत

  • reasoning_effort बदलने पर भी मौजूदा context cache invalidate हो जाता है और फिर से prefill करना पड़ता है
  • काम के अनुसार reasoning strength चुनने के बाद एक session के भीतर उसे लगातार वही रखना recommended है
  • अगर वास्तव में अलग reasoning strength चाहिए, तो लंबे session में बार-बार switch करने के बजाय नया session शुरू करना बेहतर है

Plan permissions और 401 error

• सही model ID इस्तेमाल करने पर भी अगर requested feature plan permission से बाहर है, तो server 401 लौटाता है
  • K3 access नहीं: Moderato से नीचे के plan में k3 और k3-256k को call नहीं किया जा सकता
  • 1M access नहीं: Moderato में k3 अधिकतम 256k तक support करता है; अधिकतम 1M केवल Allegretto या उससे ऊपर में उपलब्ध है
  • k3-256k की context limit plan से अलग हमेशा 256k पर fixed रहती है
  • HighSpeed access नहीं: kimi-for-coding-highspeed के लिए Allegretto या उससे ऊपर चाहिए
• पूरी error wording और handling methods Error Reference में देखी जा सकती हैं

HighSpeed तेज क्यों महसूस नहीं होता

• HighSpeed model ID बिल्कुल kimi-for-coding-highspeed ही होना चाहिए
  • गलत input देने पर बिना error के standard kimi-for-coding पर fallback हो जाता है, इसलिए speed gain दिखाई नहीं देता
• HighSpeed सिर्फ model output को accelerate करता है
  • file read·write, command calls और script execution तेज नहीं होते
  • अगर किसी एक task में tools या scripts चलाने का हिस्सा ज़्यादा है, तो कुल speed improvement कम महसूस हो सकती है

Client में model switch करना

• model ID बदलने पर context cache invalidate हो जाता है. अतिरिक्त token consumption से बचने और बेहतर usage experience के लिए नया session शुरू करना recommended है
• call करते समय model version name नहीं, बल्कि नीचे दिए गए model ID में से एक डालना होगा
  • k3
  • k3-256k
  • kimi-for-coding
  • kimi-for-coding-highspeed
• Kimi K3 या K2.7 Code जैसे version name डालने पर call fail हो जाएगा
• K3 या K2.7 में Thinking बंद करने पर request K2.6 पर route हो जाती है, इसलिए K3 या K2.7 Code इस्तेमाल करने के लिए Thinking चालू रखना होगा

• Official clients

  • Kimi Code CLI में /model टाइप करके बिना settings बदले model switch किया जा सकता है
  • अगर latest model list में नहीं दिखता, तो /logout के बाद /login करके फिर से sign in करना होगा
  • Kimi Code for VS Code में input box के dropdown menu से model चुना जाता है
  • अगर model दिखाई न दे, तो VS Code restart करें या extension फिर से install करें

Third-party tool settings

• Kimi Code Console में API Key बनाने के बाद tool में Base URL और model ID दर्ज करें
• Kimi Code API, OpenAI-compatible protocol और Anthropic-compatible protocol दोनों को support करता है
  • OpenAI-compatible Base URL: https://api.kimi.com/coding/v1
  • Anthropic-compatible Base URL: https://api.kimi.com/coding/
• हर tool की setting method नीचे दिए गए docs में देखी जा सकती है
  • Claude Code: Anthropic का command-line coding assistant
  • OpenCode: terminal-based coding agent
  • Codex: OpenAI का coding agent

• K3 context setting

  • कुछ third-party tools का default context, K3 के अधिकतम 1M से छोटा होता है
  • अधिकतम 1M context इस्तेमाल करने के लिए context-window field को सीधे 1048576 पर सेट करना होगा

• K3 reasoning strength mapping

  • K3, low, high, max को support करता है, और tool द्वारा भेजी गई value नीचे की तरह map होती है
  • null या undefined: default high
  • अन्य अज्ञात value: HTTP 400 error
  • ultra, max, xhigh: max
  • high, medium: recommended level high
  • low, minimum, light: low
  • none: thinking.type disabled

[GN⁺]

Hacker News की राय

• Codex 256k context का बहुत अच्छी तरह उपयोग करता है। 1M काफी उदार है, लेकिन अभी भी महंगा है और default के रूप में अनावश्यक लगता है

• LLM तेज़ी से सामान्य commodity बन रहे हैं, और OpenAI जैसे अमेरिकी AI research labs की moat कमज़ोर हो रही है। अंततः सस्ते token बेच सकने वाले hyperscalers और data center owners के जीतने की संभावना ज़्यादा है

  • मैंने दूसरे products ज़्यादा इस्तेमाल नहीं किए हैं, लेकिन Codex harness इतना आकर्षक है कि उससे switch करना मुश्किल लगता है। सोचता हूँ कि क्या इसी गुणवत्ता का harness कहीं और भी मिलता है
  • हर एक model में भारी पूंजी और जटिल R&D लगाने वाली frontier AI कंपनियों का मैं गहराई से आभारी हूँ। यहाँ तक पहुँचने में कितना बड़ा खर्च हुआ, यह बात अब इतनी आसानी से भूल जाती है

• k3-256k जारी हो गया है, और 256k context के भीतर वही परिणाम देता है। k3 (1M) k3-256k की तुलना में quota लगभग दोगुना खर्च करता है

• यह अच्छा बदलाव है। मैं आमतौर पर context को 200k से नीचे रखने की कोशिश करता हूँ

  • इस खबर के Reddit thread में भी यही वाक्य top comment है
    https://www.reddit.com/r/kimi/s/BFa1TR9vNg
  • काम के दायरे पर निर्भर करता है, लेकिन मेरे हिसाब से सही जगह 500k से नीचे है। Claude में 5 लाख token होने पर शुरुआत से अब तक का पूरा संदर्भ बनाए रखते हुए भी काफ़ी बड़े project बनाए जा सकते हैं
  • “256k सबके लिए काफ़ी होना चाहिए”

• तो क्या इसका मतलब है कि सभी users, context के 256k तक पहुँचने तक, अचानक Kimi को आधी कीमत पर इस्तेमाल करेंगे? अगर ऐसा है तो यह बहुत बड़ा बदलाव है

  • क्योंकि यह अलग model है, मैंने सोचा था कि k3-256k इस्तेमाल करते हुए 256k पर 1M model में switch करने पर cache invalid हो जाएगा, और पहले के 256k tokens का भुगतान भी 1M model की कीमत पर फिर से करना पड़ेगा
    लेकिन यह गलत था, और context limit के करीब पहुँचने पर cache invalidate किए बिना 1M model में switch किया जा सकता है। मौजूदा version में k3-256k से k3 (1M) में बदलने पर cache पर असर नहीं पड़ता
  • मेरी समझ में ऐसा नहीं है। शायद मतलब यह है कि context window छोटी होने पर समय के साथ जमा होने वाले input tokens कम होते हैं, इसलिए आम तौर पर यह सस्ता पड़ता है

• इस पोस्ट को आए 38 मिनट हुए हैं, और 20 मिनट पहले से Anthropic की कई services बड़े outage में दिख रही हैं। शायद कोई संबंध नहीं है, लेकिन थोड़ा मज़ेदार लगा

• लगता है model खुद वही है और यह सिर्फ API-स्तर का बदलाव है

• कार्यात्मक रूप से यह OpenAI के उस तरीके जैसा है जिसमें एक तय context length के बाद pricing tier बदल जाता है। सीमा भी लगभग 272k, यानी 2^18 या 256k के आसपास है
  active context बढ़ने पर output token प्रति ज़रूरी compute और पढ़े जाने वाले bytes दोनों बढ़ते हैं, इसलिए इसकी लागत users पर डालना तर्कसंगत है। हालांकि step-based threshold की जगह smooth pricing curve न अपनाना थोड़ा हैरान करता है

  • संभवतः वे maximum sequence length के हिसाब से दो तरह के infrastructure configuration चला रहे हैं, इसलिए step-based threshold चौंकाने वाली बात नहीं है
    short context configuration में प्रति instance prefill-only nodes कम हो सकते हैं, बड़े KV cache को support करने की ज़रूरत नहीं होती, और कुल nodes की संख्या भी घट सकती है। disaggregated inference इस्तेमाल करने पर prefill और decoding को दिए जाने वाले compute ratio को भी अलग-अलग समायोजित किया जा सकता है

• उम्मीद है इस बदलाव से infrastructure पर बोझ कम होगा। हाल के सभी models साफ़ तौर पर धीमे हो गए हैं, लेकिन support team जवाब नहीं दे रही है। शक है कि requests के बड़े हिस्से को quantized models से संभाला जा रहा है

  • बिना आधार वाली conspiracy theory Reddit पर तो चल सकती है, HN पर नहीं

• सोच रहा हूँ कि क्या यह quantized model नहीं, बल्कि सिर्फ 256k context window तक सीमित version है

  • 256k context window और quantization अलग चीज़ें हैं। बाहर से सीधे पुष्टि करना मुश्किल है, इसलिए वास्तव में quantized होने की संभावना को भी पूरी तरह नकारा नहीं जा सकता