Kimi K2 API बंद होगा: K2.7 Code से K3.1 Pro पर जाएँ

दिसंबर 2026 के अंत में K2 की नियोजित बंदी से पहले kimi-k2.6 और kimi-k2.7-code के अनुरोध kimi-k3.1-pro पर ले जाएँ। प्रोडक्शन ट्रैफ़िक बदलने से पहले रीज़निंग का स्तर और जनरेशन सीमा तय करें, फिर टूल कॉल का इतिहास और कैश शुल्क जाँचें। 2026-11-05 तक नए खातों पर पाबंदियाँ लागू हो चुकी हैं।

Kimi K2 कब काम करना बंद करेगा?

जिन पुराने खातों को K2 का एक्सेस मिला हुआ है, वे अभी इसका इस्तेमाल कर सकते हैं। इन सूचनाओं में बंद करने का सटीक दिन या समय नहीं दिया गया है।

कीमतों वाले पेज की सूचना के अनुसार, 31 अक्टूबर 2026 से नए पंजीकृत उपयोगकर्ताओं के लिए K2 उपलब्ध नहीं है। सभी K2 मॉडल दिसंबर 2026 के अंत तक बंद करने की योजना है।

वर्तमान मॉडल सूची की भाषा थोड़ी अलग है। उसके अनुसार, 1 नवंबर से पहले पंजीकृत उपयोगकर्ता kimi-k2.6, kimi-k2.7-code और kimi-k2.7-code-highspeed का इस्तेमाल जारी रख सकते हैं। इन्हें दिसंबर 2026 के अंत में बंद किए जाने की उम्मीद है।

यदि आपने इन तारीखों के आसपास खाता बनाया था, तो अपने खाते का वास्तविक एक्सेस जाँचें। दोनों सूचनाएँ पंजीकरण की एक सटीक समय-सीमा तय नहीं करतीं। नए डिप्लॉयमेंट के लिए K3.1 Pro से शुरू करें।

K2 के हर एक्सेस-संबंधी विफल अनुरोध में एक ही त्रुटि मानकर न चलें। अगस्त के बदलावों का विवरण बंद हो चुके kimi-k2.5 और moonshot-v1 मॉडल के लिए 404 “model not found” की पुष्टि करता है। यह विवरण K2.6 या K2.7 Code बंद होने पर मिलने वाला उत्तर तय नहीं करता।

ट्रैफ़िक बदलने से पहले अनुरोध का प्रारूप बदलें

अनुरोध की बॉडी और बातचीत का इतिहास सहेजने का तरीका साथ में अपडेट करें। Kimi की पैरामीटर तुलना ऐसे अंतर बताती है जो केवल मॉडल का नाम बदलने पर छूट सकते हैं।

सेटिंग	`kimi-k2.6`	`kimi-k2.7-code`	`kimi-k3.1-pro`
थिंकिंग मोड	डिफ़ॉल्ट रूप से चालू; बंद कर सकते हैं	हमेशा चालू	हमेशा चालू; K2 का `thinking` ऑब्जेक्ट हटाएँ
`reasoning_effort`	समर्थित नहीं	समर्थित नहीं	शीर्ष स्तर पर `low`, `high` या `max`; डिफ़ॉल्ट `max`
`temperature`	थिंकिंग में निश्चित `1.0`; उसके बिना `0.6`	निश्चित `1.0`	निश्चित `1.0`; इसे न भेजें
दस्तावेज़ में दी गई डिफ़ॉल्ट जनरेशन सीमा	`max_tokens`: `32768`	`max_tokens`: `32768`	`max_completion_tokens`: `131072`

K2.7 Code में थिंकिंग मोड पहले से अनिवार्य था और रीज़निंग का इतिहास भी सुरक्षित रहता था। अगर आप K2.6 में थिंकिंग बंद रखते थे, तो ये आवश्यकताएँ बड़ा बदलाव हैं।

K3.1 Pro की शुरुआती गाइड में top_p=0.95, n=1, presence_penalty=0 और frequency_penalty=0 भी निश्चित हैं। इन फ़ील्ड और temperature को अनुरोध में न भेजें। क्लाइंट या रैपर की डिफ़ॉल्ट सेटिंग भी देखें। वह ऐसा सैंपलिंग मान जोड़ सकता है जिसे आपके एप्लिकेशन ने सेट ही नहीं किया।

नए Chat Completions अनुरोधों में max_completion_tokens इस्तेमाल करें। API संदर्भ max_tokens को अप्रचलित बताता है; उसे हटाए जाने की बात नहीं कहता। K3.1 Pro में अधिकतम 1048576 सेट कर सकते हैं, लेकिन कॉन्टेक्स्ट विंडो में बची जगह भी जनरेशन सीमित करती है।

यह सीमा अधिकतम जनरेशन तय करती है। इसका अर्थ यह नहीं कि हर अनुरोध उतने टोकन खर्च करेगा। बढ़ी हुई डिफ़ॉल्ट सीमा लेने के बजाय अपनी ज़रूरत के अनुसार मान चुनें।

रीज़निंग के स्तर के लिए, कनेक्शन जाँचने और सीमित जानकारी खोजने वाले अनुरोधों में low से शुरू करें। सामान्य कोडिंग के लिए high आज़माएँ। जब आपकी रिग्रेशन जाँच में अतिरिक्त रीज़निंग का फायदा दिखे, तब max चुनें। low रीज़निंग का स्तर घटाता है; थिंकिंग मोड बंद नहीं करता।

API और टूल कॉल की सीमित जाँच चलाएँ

एजेंट की सेटिंग में समस्या ढूँढ़ने से पहले सीधे API को जाँचें।

Global Kimi Open Platform की API कुंजी बनाएँ। 2026-11-05 तक एक्सेस की शर्तों के अनुसार कम से कम $1 का सफल टॉप-अप ज़रूरी है। https://api.moonshot.ai से मेल खाने वाले प्लेटफ़ॉर्म की कुंजी इस्तेमाल करें। Kimi Code खाते की त्रुटियों के लिए अलग Kimi Code सीमा गाइड देखें।

Bash में कुंजी इस तरह दर्ज करें कि वह स्क्रीन पर न दिखे:

read -rs MOONSHOT_API_KEY && export MOONSHOT_API_KEY

अगली Bash कमांड Python 3 की मानक लाइब्रेरी इस्तेमाल करती है। यह दो शुल्क वाले अनुरोध भेजती है और स्थानीय रूप से गुणा करती है। 4096 की जनरेशन सीमा इस गणितीय जाँच के लिए है, सामान्य कोडिंग बजट के लिए नहीं।

python3 - <<'PY'
import json
import os
import urllib.error
import urllib.request

tools = [{
    "type": "function",
    "function": {
        "name": "multiply",
        "description": "Multiply two integers.",
        "parameters": {
            "type": "object",
            "properties": {
                "a": {"type": "integer"},
                "b": {"type": "integer"}
            },
            "required": ["a", "b"],
            "additionalProperties": False
        }
    }
}]

def chat(messages, choice):
    payload = {
        "model": "kimi-k3.1-pro",
        "messages": messages,
        "reasoning_effort": "low",
        "max_completion_tokens": 4096,
        "tools": tools,
        "tool_choice": choice
    }
    request = urllib.request.Request(
        "https://api.moonshot.ai/v1/chat/completions",
        data=json.dumps(payload).encode("utf-8"),
        headers={
            "Authorization": "Bearer " + os.environ["MOONSHOT_API_KEY"],
            "Content-Type": "application/json"
        },
        method="POST"
    )
    try:
        with urllib.request.urlopen(request, timeout=120) as response:
            data = json.load(response)
    except urllib.error.HTTPError as error:
        raise SystemExit(f"HTTP {error.code}: check access and request parameters.")
    if data.get("model") != "kimi-k3.1-pro":
        raise RuntimeError("Unexpected response model.")
    if data["choices"][0]["finish_reason"] == "length":
        raise RuntimeError("Generation limit reached; do not accept this result.")
    return data

messages = [{
    "role": "user",
    "content": "Use multiply to calculate 6 times 7, then report the result."
}]
first = chat(messages, "required")
assistant = first["choices"][0]["message"]
calls = assistant.get("tool_calls") or []
if not calls:
    raise RuntimeError("Expected a tool call.")
messages.append(assistant)

for call in calls:
    function = call["function"]
    arguments = json.loads(function["arguments"])
    if function["name"] != "multiply":
        raise RuntimeError("Unexpected tool.")
    if not isinstance(arguments, dict) or set(arguments) != {"a", "b"}:
        raise RuntimeError("Unexpected arguments.")
    if any(type(arguments[key]) is not int for key in ("a", "b")):
        raise RuntimeError("Expected integer arguments.")
    result = arguments["a"] * arguments["b"]
    messages.append({
        "role": "tool",
        "tool_call_id": call["id"],
        "content": json.dumps({"result": result})
    })

final = chat(messages, "none")
choice = final["choices"][0]
answer = choice["message"].get("content") or ""
if choice["finish_reason"] != "stop" or not answer.strip():
    raise RuntimeError("Expected a completed final answer.")
print(answer)
print(json.dumps({"first": first["usage"], "final": final["usage"]}))
PY

अपेक्षित परिणाम में 42 वाला अंतिम उत्तर और दोनों अनुरोधों के उपयोग के आँकड़े होंगे। टूल कॉल न मिलने, अलग मॉडल लौटने, गलत आर्ग्युमेंट, कटी हुई जनरेशन या अधूरे अंतिम उत्तर पर जाँच परिणाम स्वीकार नहीं करती।

मुख्य चरण messages.append(assistant) है। यह reasoning_content और tool_calls सहित असिस्टेंट का पूरा संदेश सुरक्षित रखता है। फिर हर टूल परिणाम में उससे मेल खाता tool_call_id जाता है। अपने प्रोडक्शन एप्लिकेशन में बातचीत का इतिहास सहेजते समय भी पूरा संदेश वापस भेजने का नियम अपनाएँ।

दोनों चरण जाँचने के लिए उदाहरण में टूल कॉल अनिवार्य करने और रोकने के विकल्प चुने गए हैं। सामान्य एजेंट चक्र में auto इस्तेमाल कर सकते हैं, ताकि अगला टूल बुलाने का निर्णय मॉडल करे।

अनुरोध विफल हो तो त्रुटि संदर्भ के अनुसार अगली जाँच चुनें:

401 पर कुंजी जारी करने वाला प्लेटफ़ॉर्म और अनुरोध का पता जाँचें। फिर यही उदाहरण दोबारा चलाएँ।
मौजूदा एप्लिकेशन में 400 पर भेजे गए JSON को देखें। उसमें K2 का thinking या निश्चित सैंपलिंग मान बदलने वाली सेटिंग तो नहीं है?
404 पर मॉडल ID और खाते का एक्सेस, दोनों जाँचें। यह कोड अकेले नाम की वर्तनी गलत होने का प्रमाण नहीं है।
finish_reason="length" पर उत्तर अधूरा मानें। परिणाम स्वीकार करने से पहले काम, रीज़निंग का स्तर या जनरेशन सीमा बदलें।

2026-11-05 तक BetterToken की सूची में भी kimi-k3.1-pro है। उसका OpenAI-संगत API https://www.bettertoken.ai/v1 और आपकी अपनी BetterToken API कुंजी इस्तेमाल करता है। उसकी वर्तमान कीमतें और अनुरोध के नियम अलग से जाँचें। Moonshot के कैश नियम इस गेटवे का व्यवहार निर्धारित नहीं करते।

OpenCode और Claude Code अपडेट करें

हर ऐसे रूट को बदलें जो K2 चुन सकता है, जिसमें बैकग्राउंड कार्य और सबएजेंट भी शामिल हैं। मुख्य बातचीत सफल होने से इन रूट की जाँच नहीं हो जाती।

OpenCode: Moonshot प्रोवाइडर चुनें

बिल्ट-इन Moonshot AI प्रोवाइडर इस्तेमाल करें और उसकी मॉडल सूची रीफ़्रेश करें। उसकी प्रोवाइडर ID moonshotai है और वह MOONSHOT_API_KEY पढ़ता है।

OpenCode v1.19.5 के CLI इंटरफ़ेस के अनुसार, उसी Bash सत्र में ये कमांड चलाएँ:

opencode models moonshotai --refresh
opencode run --model moonshotai/kimi-k3.1-pro --variant high \
  "Inspect the current project and identify the test command. Do not edit files."

रीफ़्रेश की गई सूची में moonshotai/kimi-k3.1-pro होना चाहिए। अगली कमांड को चुने गए प्रोवाइडर और मॉडल से आपके प्रोजेक्ट के बारे में उत्तर मिलना चाहिए। मॉडल न दिखे तो आगे बढ़ने से पहले क्लाइंट का संस्करण और सूची का रीफ़्रेश जाँचें।

CLI संदर्भ दोनों फ़्लैग समझाता है। मॉडल को स्थायी रूप से चुनने के लिए प्रोजेक्ट की opencode.json या वैश्विक ~/.config/opencode/opencode.json में "model": "moonshotai/kimi-k3.1-pro" सेट करें। दोनों फ़ाइलें हों तो सेटिंग की प्राथमिकता के नियम देखें।

कमांड सिर्फ़ उस बार के लिए high सेट करती है। इंटरैक्टिव सत्र में पहला प्रॉम्प्ट भेजने से पहले /variants से स्तर चुनें। यदि क्लाइंट भी अपग्रेड कर रहे हैं, तो रिपॉज़िटरी में बदलाव की अनुमति देने से पहले OpenCode 2 की अनुमति-संबंधी बदलावों की गाइड पढ़ें।

Claude Code: मॉडल की सभी मैपिंग अपडेट करें

Moonshot ने Claude Code के लिए संगत कनेक्शन का तरीका दिया है। Anthropic के गेटवे दस्तावेज़ कहते हैं कि Claude Code को गैर-Claude मॉडल पर भेजने के लिए वे सपोर्ट नहीं देते। इसे Moonshot के अडैप्टर वाला मार्ग मानें और अपने स्थापित क्लाइंट के साथ जाँचें।

पहले ~/.claude/settings.json और प्रोजेक्ट की सेटिंग देखें। उनके env ब्लॉक में पुराने पते, कुंजी-संबंधी मान, मॉडल और रीज़निंग स्तर सुधारें। Moonshot चेतावनी देता है कि सेटिंग फ़ाइल के पर्यावरण चर टर्मिनल से एक्सपोर्ट किए मानों को ओवरराइड कर सकते हैं।

उसके वर्तमान उदाहरण में Haiku अभी भी kimi-k2.7-code से जुड़ा है। नीचे की प्रस्तावित Bash सेटिंग सभी सूचीबद्ध मॉडल स्तरों को नई मॉडल ID पर ले जाती है:

unset ANTHROPIC_API_KEY
export ANTHROPIC_BASE_URL="https://api.moonshot.ai/anthropic"
export ANTHROPIC_AUTH_TOKEN="$MOONSHOT_API_KEY"
export ANTHROPIC_MODEL="kimi-k3.1-pro"
export ANTHROPIC_DEFAULT_OPUS_MODEL="$ANTHROPIC_MODEL"
export ANTHROPIC_DEFAULT_SONNET_MODEL="$ANTHROPIC_MODEL"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="$ANTHROPIC_MODEL"
export ANTHROPIC_DEFAULT_FABLE_MODEL="$ANTHROPIC_MODEL"
export CLAUDE_CODE_SUBAGENT_MODEL="$ANTHROPIC_MODEL"
export CLAUDE_CODE_EFFORT_LEVEL="high"

claude --model kimi-k3.1-pro

यह API जाँच के लिए एक्सपोर्ट की गई कुंजी दोबारा इस्तेमाल करती है। बची हुई पुरानी K2 सेटिंग भी देखें, जिनमें ANTHROPIC_SMALL_FAST_MODEL शामिल है।

/status चलाकर बेस URL और मॉडल जाँचें। फिर साधारण प्रश्न पूछें और ऐसा काम दें जिसमें स्थानीय फ़ाइल पढ़नी हो। मॉडल सेटिंग नियंत्रणों से लागू रीज़निंग स्तर की पुष्टि करें।

Claude Code Messages प्रोटोकॉल इस्तेमाल करता है। इन Kimi Messages फ़ील्ड को Chat Completions से अलग रखें:

उद्देश्य	Chat Completions	Kimi Messages
रीज़निंग का स्तर	`reasoning_effort`	`output_config.effort`
जनरेशन सीमा	`max_completion_tokens`	अनिवार्य `max_tokens`
कैश में रखने की अवधि	`prompt_cache_options.ttl`	शीर्ष-स्तरीय `cache_control.ttl`

Chat Completions में अप्रचलित होने के कारण Messages के max_tokens फ़ील्ड का नाम न बदलें।

टोकन दो बार गिने बिना कैश खर्च जाँचें

इनपुट को कैश से पढ़े गए, कैश में लिखे गए और कैश से बाहर के टोकन में बाँटें। K3.1 Pro कैश में लिखने का शुल्क अलग लेता है। इसे लागत की गणना में शामिल करें।

Chat Completions में ये मान पढ़ें:

कुल इनपुट: usage.prompt_tokens।
कैश से पढ़े गए टोकन: usage.prompt_tokens_details.cached_tokens।
कैश में लिखे गए टोकन: usage.prompt_tokens_details.cache_write_tokens।
कुल आउटपुट: usage.completion_tokens।

API के गणना नियमों के अनुसार, इनपुट की इन तीन श्रेणियों में एक ही टोकन दो बार नहीं आता। आउटपुट में रीज़निंग और उत्तर, दोनों के टोकन पहले से शामिल हैं।

एक ही मुद्रा में प्रति 1,000,000 टोकन की दरें इस्तेमाल करें:

uncached = prompt_tokens - cached_tokens - cache_write_tokens

token_cost = (
    uncached * miss_rate
    + cached_tokens * hit_rate
    + write_5m * write_5m_rate
    + write_1h * write_1h_rate
    + completion_tokens * output_rate
) / 1_000_000

यहाँ write_5m + write_1h का योग cache_write_tokens के बराबर होना चाहिए। दरें प्रोवाइडर की वर्तमान कीमतों से लें। यह टोकन शुल्क का अनुमान है; इसे वास्तविक बिल से मिलाएँ।

कैश विकल्प न भेजने पर Kimi अपने-आप 5m कैश इस्तेमाल करता है। अनुरोधों के बीच लंबा अंतर हो तो "prompt_cache_options": {"mode": "implicit", "ttl": "1h"} पर विचार करें।

कैश गाइड बताती है कि मौजूदा एंट्री अपनी मूल अवधि रखती है। 1h भेजने से सक्रिय 5m एंट्री की अवधि नहीं बढ़ती। कैश में लिखे गए टोकन की वास्तविक संख्या जानने के लिए उत्तर के Msh-Usage-Cache-Write-Tokens-5m और Msh-Usage-Cache-Write-Tokens-1h हेडर रिकॉर्ड करें।

अनुरोध का साझा शुरुआती हिस्सा, यानी प्रिफ़िक्स, बदले बिना अपने सामान्य काम जैसे अनुरोध दोहराकर जाँचें। गणितीय उदाहरण उपयोगी कैश प्रभाव दिखाने के लिए छोटा हो सकता है, क्योंकि अधूरे ब्लॉक कैश में नहीं लिखे जाते। जाँच के दौरान रीज़निंग का स्तर स्थिर रखें। स्तर बदलने से प्रिफ़िक्स कैश हिट अमान्य हो जाते हैं।

स्ट्रीमिंग एप्लिकेशन में stream_options.include_usage=true भी सेट करें। स्ट्रीमिंग गाइड के अनुसार रीज़निंग, उत्तर और टूल कॉल के हिस्से जोड़ें। उपयोग के आँकड़ों वाला अंतिम हिस्सा पढ़ें, भले उसका choices ऐरे खाली हो।

ट्रैफ़िक बदलने से पहले रिग्रेशन जाँच तय करें

नया रूट आपके मौजूदा स्वीकृति परीक्षण पास कर ले, तभी ट्रैफ़िक का छोटा हिस्सा उस पर भेजें।

हर तुलना में रिपॉज़िटरी की एक ही रिविज़न, वही प्रॉम्प्ट, टूल परिभाषाएँ और परीक्षण कमांड इस्तेमाल करें। low, high और max अलग-अलग सत्रों में चलाएँ। काम की गुणवत्ता, पूरा उत्तर मिलने का समय, इनपुट श्रेणियाँ, कुल आउटपुट, दोबारा भेजे गए अनुरोध और बिल की लागत रिकॉर्ड करें।

रिग्रेशन जाँच में ये स्थितियाँ शामिल करें:

कई चरणों वाला संवाद, जिसमें पिछले असिस्टेंट संदेश की जानकारी चाहिए।
टूल कॉल, जिसके बाद मॉडल को अगला उत्तर देना हो।
स्ट्रीमिंग टूल कॉल, जिसमें JSON आर्ग्युमेंट टुकड़ों में आएँ।
ऐसा काम जो आपकी जनरेशन सीमा के करीब पहुँचे।
बैकग्राउंड या सबएजेंट का काम, जिसमें K2 की पुरानी मैपिंग बची हो सकती है।

वह सबसे कम रीज़निंग स्तर चुनें जो गुणवत्ता और उत्तर मिलने के समय की आपकी शर्तें पूरी करे। यदि high किसी ज़रूरी काम में विफल हो और max उसे आपकी जाँच में भरोसेमंद ढंग से पूरा करे, तो उस तरह के काम के लिए max रखें।

K2 पर वापस लौटने का विकल्प तभी तक रखें जब तक खाते को उसका एक्सेस है। बंद होने की अवधि से पहले ऐसा वैकल्पिक रूट जाँचें जो K2 पर निर्भर न हो। निर्धारित कार्यों, दोबारा अनुरोध भेजने वाले रूट और एजेंट की सेटिंग से पुरानी K2 ID हटाएँ।