DeepSeek V4 Pro से V4.1 Flash: 14 सितंबर से पहले जाँच
Pro की प्रस्तावित रूटिंग समझें, क्लाइंट और बिलिंग जाँचें और पुराने Pro नाम से स्वतंत्र बैकअप तैयार करें।
विषय-सूची

DeepSeek की योजना V4 Pro को 14 सितंबर 2026, बीजिंग समय 12:00 बजे, यानी 04:00 UTC या मॉस्को समय 07:00 बजे बंद करने की है। लॉगिन के बाद उपलब्ध आधिकारिक प्लेटफ़ॉर्म की सूचना के अनुसार V4 Pro अनुरोध V4.1 Flash को भेजे जाएँगे और V4.1 Flash की दरें लागू होंगी।
आधिकारिक API की योजना मौजूदा अनुरोधों को आगे भेजने की है। केवल यह घोषणा हर कॉन्फ़िगरेशन में deepseek-v4-pro को तुरंत बदलना अनिवार्य नहीं बनाती। लेकिन पुराने नाम के पीछे दूसरा मॉडल जवाब देगा। बदलाव से पहले अपने कामों का परीक्षण करें और ऐसा बैकअप बनाएँ जो उस नाम पर निर्भर न हो।
एक अलग सूचना Flash की कीमतों में बदलाव 10 सितंबर, बीजिंग समय 12:00 बजे के लिए तय करती है। यह अलग घटना है। 10 सितंबर को देखी गई Pro बंद होने की सूचना 14 सितंबर बताती है। यह गाइड प्रस्तावित बदलाव की तैयारी है, माइग्रेशन पहले ही पूरा हो जाने का दावा नहीं।
अनुरोध पाने वाले प्रदाता को पहचानें
| कनेक्शन | क्या जाँचें |
|---|---|
| सीधे DeepSeek API | खाते की सूचना, Pro बदलाव की तारीख और विकल्प की वर्तमान दरें |
| BetterToken सहित तीसरे पक्ष की API | उसका अपना कैटलॉग, Model ID, समय, रूटिंग और कीमत; DeepSeek की सूचना रीसेलर की शर्तें तय नहीं करती |
| चुने गए प्रदाता वाला कोडिंग एजेंट | असली Base URL और भेजा गया Model ID, मुख्य एजेंट और सहायक कामों के लिए अलग-अलग |
क्लाइंट के मेन्यू का नाम पूरी रूटिंग नहीं बताता। मुख्य बातचीत, उपकार्य और बैकअप में अलग मॉडल सेटिंग हो सकती हैं। ग्लोबल के साथ प्रोजेक्ट की सेटिंग भी जाँचें।
एक छोटी सूची बनाएँ: ऐप, प्रदाता, प्रोटोकॉल, वर्तमान Model ID, सेटिंग की जगह और जाँच के ज़िम्मेदार व्यक्ति। उसमें API कुंजियाँ न लिखें।
ripgrep वाले स्थानीय प्रोजेक्ट में यह कमांड केवल उन फ़ाइलों के नाम दिखाती है जिनमें Pro का सीधा उल्लेख है:
rg -l --hidden -g '!.git' -g '!node_modules' -g '!.venv' \
'deepseek-v4-pro' .
इसे प्रोजेक्ट डायरेक्टरी से चलाएँ। कोई मेल न मिलना निर्भरता न होने का प्रमाण नहीं है: CI वैरिएबल, होस्टेड सेवाओं की सेटिंग और क्लाइंट के उपनाम भी देखें। कमांड न सेटिंग बदलती है, न API जाँचती है।
क्या नया Model ID चाहिए?
आधिकारिक Pro सूचना में रूटिंग बदलने की व्यवस्था है। विकल्प का नाम अनुमान से न लिखें, और अस्थायी ID का प्रत्यय हटाने को माइग्रेशन न मानें। V4.1 Flash स्पष्ट रूप से चुनना हो तो अपने असली प्रदाता के वर्तमान कैटलॉग से उपलब्ध ID कॉपी करें और पहले अलग क्लाइंट प्रोफ़ाइल में जाँचें।
अस्थायी deepseek-v4.1-flash-expires-on-0910 दूसरी प्रविष्टि है। उसकी समाप्ति Pro बंद होने की तारीख नहीं है और पुरानी ट्रायल प्रोफ़ाइल अपने-आप स्थायी विकल्प नहीं बनती।
अप्रत्यक्ष नाम भी जाँचें। वर्तमान DeepSeek Anthropic API गाइड claude-opus उपसर्ग को Pro और claude-haiku या claude-sonnet को Flash से जोड़ती है। असमर्थित नामों के लिए दस्तावेज़ deepseek-v4-flash पर फ़ॉलबैक बताता है। टाइपिंग की गलती के बाद सफल उत्तर मिलना इच्छित मॉडल चुने जाने का प्रमाण नहीं। ये आधिकारिक DeepSeek अडैप्टर के नियम हैं; दूसरे प्रदाता अलग हो सकते हैं।
बदलने के बाद भेजी गई ID, प्रदाता का रिकॉर्ड और उसकी घोषित मॉडल मैपिंग मिलाएँ। मॉडल का अपना परिचय या उत्तर का अकेला model फ़ील्ड स्वतंत्र रूप से नहीं साबित करता कि अनुरोध किस वेट से चला।
प्रोटोकॉल बनाए रखें और पूरे काम जाँचें
DeepSeek का आधिकारिक Anthropic-संगत Base URL https://api.deepseek.com/anthropic है। केवल मॉडल बदलने के कारण उसे Chat Completions क्लाइंट में न डालें। तीसरे पक्ष के अपने पते और प्रमाणीकरण नियम होते हैं।
शुरुआत में काम कर रहा प्रोटोकॉल बनाए रखें। सेटिंग अलग टेस्ट प्रोफ़ाइल में कॉपी करें, केवल उपलब्धता-पुष्ट मॉडल बदलें और छोटा अनुरोध करें। नया मॉडल अभी सूचीबद्ध न हो तो परीक्षण और बैकअप तैयार करें; संगतता जाँची जा चुकी है ऐसा न कहें।
HTTP 200 और टेक्स्ट उत्तर केवल उस अनुरोध की सफलता साबित करते हैं। उपयोगी एजेंट के लिए उसके मौजूदा कामों की जाँच चाहिए:
| स्थिति | दिखाई देने वाला स्वीकृति संकेत |
|---|---|
| बग फ़िक्स | मूल टेस्ट पहले विफल और बाद में सफल हो, संबंधित जाँच न टूटे |
| टूल कॉल | सही नाम और तर्क, टूल परिणाम का सही इस्तेमाल, परिणाम लौटने के बाद पूरा उत्तर |
| स्ट्रीमिंग | क्लाइंट स्ट्रीम प्राप्त और समाप्त करे तथा अंतिम नतीजा और उपयोग बिना पार्सिंग त्रुटि सँभाले |
| लंबी बातचीत | काम की सीमाएँ और पुराने आवश्यक तथ्य बने रहें |
| रेट लिमिट या अस्थायी त्रुटि | प्रयास और कुल समय सीमित हों; दोबारा कोशिश से अतिरिक्त बाहरी कार्रवाई न बने |
ईमेल, CRM या दूसरी बाहरी कार्रवाइयाँ जाँचते समय टेस्ट डेटा लें या असली भेजना बंद करें। सही तर्क बनना यह सिद्ध नहीं करता कि कार्रवाई दोहराना सुरक्षित है।
अपने प्रोटोकॉल के सोचने के नियंत्रण जाँचें। उदाहरण के लिए आधिकारिक DeepSeek Anthropic अडैप्टर thinking.budget_tokens को अनदेखा करता है और output_config में केवल effort स्वीकार करता है। सेटिंग फ़ाइल में फ़ील्ड बचे रहने से पुराना बजट लागू होने का प्रमाण नहीं मिलता। Thinking Mode मैपिंग देखें।
ये आपके वातावरण के स्वीकृति परीक्षण हैं, यह दावा नहीं कि V4.1 Flash हर क्लाइंट में इन्हें पास कर चुका है। विस्तृत निर्भरता सूची और कटओवर जाँच के लिए AI API माइग्रेशन ऑडिट देखें।
गुणवत्ता से अलग बिलिंग जाँचें
सूचना रीडायरेक्ट हुए Pro अनुरोधों पर V4.1 Flash बिलिंग लागू करती है। वह तीसरे पक्ष की कीमतें तय नहीं करती और न समान काम पर समान टोकन उपयोग का वादा करती है।
टेस्ट का समय, प्रदाता, भेजी गई ID, इनपुट और आउटपुट टोकन, उपलब्ध कैश विवरण और अंतिम शुल्क लिखें। उन्हें उस समय के उसी प्रदाता के रेट से मिलाएँ। पीक और ऑफ़-पीक दरें हों तो सही समय-खंड लें। बदलाव के बाद पुराना Pro रेट लगाने के बजाय आधिकारिक API कीमतें फिर जाँचें।
BetterToken कॉल के लिए उपयोग फ़ील्ड Dashboard में और मॉडल उपलब्धता तथा दरें BetterToken कैटलॉग में देखें। इससे आपका कनेक्शन जँचता है; यह साबित नहीं होता कि BetterToken आधिकारिक API के साथ ही रूटिंग बदलेगा।
प्रति स्वीकार किए गए काम का खर्च तुलना करते समय असफल प्रयास भी गिनें। टोकन सस्ते होने पर भी अनुरोध बढ़ सकते हैं या उत्तर लंबे हो सकते हैं।
बैकअप Pro बंद होने के बाद भी चलना चाहिए
घोषित रूटिंग के बाद deepseek-v4-pro पर लौटना Pro-0813 को वापस नहीं लाएगा। मुख्य और बैकअप प्रोफ़ाइल उसी आधिकारिक नाम का उपयोग करें तो दोनों V4.1 Flash तक पहुँच सकती हैं।
कोई दूसरा उपलब्ध Model ID या सेवा चुनें, असली मॉडल की पुष्टि करें और पहले एक महत्वपूर्ण काम जाँचें। बैकअप स्वीकृति परीक्षण में असफल हो तो संबंधित प्रक्रिया इंसानी नियंत्रण में रखें या रोकें। बिना जाँचा विकल्प तैयार रोलबैक नहीं है।
कटओवर से पहले ज़िम्मेदार व्यक्ति के पास टेस्ट नतीजे, सत्यापित बैकअप और रुकने की शर्तें होनी चाहिए—जैसे गलत टूल कॉल, खराब स्ट्रीमिंग या अपनी सीमा से अधिक खर्च। घोषित समय के बाद एक छोटा नियंत्रण कार्य फिर चलाएँ और लोड बढ़ाने से पहले प्रदाता की वर्तमान सूचना से रूटिंग मिलाएँ।