ओपनकोड एक खुला प्रोग्रामिंग एजेंट है जो सीधे टर्मिनल में काम करता है: प्रोजेक्ट फ़ाइलों को पढ़ता है, कोड संपादित करता है, कमांड चलाता है और परीक्षण करता है, रिपॉजिटरी खोजता है और गिट के साथ काम करता है। इसकी ताकत यह है कि यह एक मॉडल प्रदाता से बंधा नहीं है और दर्जनों प्रदाताओं को जोड़ सकता है।
गीगाचैट Sber का एक बड़ा भाषा मॉडल है। यह ओपनकोड प्रदाताओं की तैयार सूची में नहीं है, लेकिन यह कोई समस्या नहीं है: ओपनकोड वर्सेल एआई एसडीके पैकेज के माध्यम से मनमाने प्रदाताओं को जोड़ता है। गीगाचैट के लिए एक पैकेज gigachat-ai-sdk-provider है, जो OAuth प्राधिकरण और एक्सेस टोकन को अपडेट करने का ख्याल रखता है। एक अलग बारीकियां डिजिटल विकास मंत्रालय के प्रमाणपत्र हैं: उनके बिना, नोड गीगाचैट सर्वर पर भरोसा नहीं करता है, और प्रमाणपत्र सत्यापन त्रुटि के साथ अनुरोध विफल हो जाते हैं।
इस पोस्ट में मैं बताऊंगा कि कुंजी कैसे प्राप्त करें, प्रमाणपत्र कैसे स्थापित करें और गीगाचैट को ओपनकोड से कैसे कनेक्ट करें।
आपको क्या चाहिए
काम करने के लिए आपको तीन चीजों की आवश्यकता है:
- OpenCode इंस्टॉल हो गया है। यदि एजेंट अभी तक इंस्टॉल नहीं हुआ है, तो मैंने OpenCode और DeepSeek के बारे में एक अलग नोट में इंस्टॉलेशन प्रक्रिया पर चर्चा की है।
- GigaChat खाता। GigaChat स्टूडियो में पंजीकरण और प्राधिकरण कुंजी – लॉग इन करने के लिए आपको Sber ID की आवश्यकता होगी।
- आधुनिक टर्मिनल। वेज़टर्म, अलाक्रिट्टी, घोस्टी, किट्टी या कोई अन्य करेगा।
गीगाचैट प्राधिकरण कुंजी
कुंजी आपके गीगाचैट स्टूडियो व्यक्तिगत खाते में बनाई गई है। Developers.sber.ru/studio पर जाएं, लॉग इन करें और GigaChat API अनुभाग में एक प्रोजेक्ट बनाएं। प्रोजेक्ट सेटिंग्स में प्राधिकरण डेटा के साथ एक ब्लॉक है: वहां से कॉपी की गई लाइन बेस 64 में एक तैयार प्राधिकरण कुंजी है। इसे पर्यावरण चर में प्रतिस्थापित किया जाता है, न कि क्लाइंट-सीक्रेट जोड़ी को अलग से।
कुंजी के साथ, दायरा निर्दिष्ट किया गया है – पहुंच क्षेत्र:
- GIGACHAT_API_PERS – व्यक्तियों के लिए।
- GIGACHAT_API_B2B – व्यक्तिगत उद्यमियों और कानूनी संस्थाओं के लिए।
- GIGACHAT_API_CORP – कॉर्पोरेट पहुंच।
प्रदर्शित कुंजी मान को तुरंत सहेजा जाना चाहिए: इसे बाद में दोबारा नहीं दिखाया जाएगा, और यदि आवश्यक हो, तो एक नया जारी करना होगा।
ये लाइन क्या है ये समझना जरूरी है. प्राधिकरण कुंजी एक अलग रहस्य नहीं है, बल्कि client_id:client_secret की एक जोड़ी पहले से ही बेस64 में एन्कोडेड है। गीगाचैट-जेएस लाइब्रेरी इस हेडर को OAuth अनुरोध में प्रतिस्थापित करती है:
Authorization: Basic ваш_ключ_авторизации
जवाब में, एक JWE एक्सेस टोकन लगभग आधे घंटे के जीवनकाल के साथ आता है, और फिर लाइब्रेरी इसे स्वचालित रूप से अपडेट करती है। पैकेज स्वयं जाँचता है कि मान बेस64 के समान है और चेतावनी देता है कि क्या चर में गलती से “कच्चा” क्लाइंट रहस्य शामिल है। इसलिए, तैयार बेस 64 स्ट्रिंग को खाते से कॉन्फ़िगरेशन और पर्यावरण चर में स्थानांतरित करना आवश्यक है, न कि क्लाइंट_आईडी और क्लाइंट_सीक्रेट जोड़ी को अलग से।
डिजिटल विकास मंत्रालय के प्रमाण पत्र
गीगाचैट एपीआई एनसीए डिजिटल विकास मंत्रालय के प्रमाणपत्रों का उपयोग करता है। मानक विश्वसनीय रूट्स स्टोर में वे नहीं हैं, इसलिए जब एक्सेस टोकन प्राप्त करने का प्रयास किया जाता है, तो अनुरोध एक त्रुटि के साथ विफल हो जाता है:
self-signed certificate in certificate chain
प्रमाणपत्र ऑपरेटिंग सिस्टम स्तर पर स्थापित किए जा सकते हैं – फिर उन पर ब्राउज़र और सिस्टम उपयोगिताओं द्वारा भरोसा किया जाएगा। लेकिन ओपनकोड नोड और बन पर चलता है, इसलिए प्रमाणपत्र फ़ाइल को सीधे NODE_EXTRA_CA_CERTS वेरिएबल में निर्दिष्ट करना अधिक सुरक्षित और आसान है। रूट और जारीकर्ता प्रमाणपत्र डाउनलोड करें और उन्हें एक PEM फ़ाइल में डालें:
curl -s https://gu-st.ru/content/lending/russian_trusted_root_ca_pem.crt -o russian_trusted_root_ca_pem.crt
curl -s https://gu-st.ru/content/lending/russian_trusted_sub_ca_pem.crt -o russian_trusted_sub_ca_pem.crt
cat russian_trusted_root_ca_pem.crt russian_trusted_sub_ca_pem.crt > russian_trusted_ca_bundle.pem
फ़ाइल को सुविधाजनक स्थान पर रखा जा सकता है और एजेंट शुरू करते समय इसका पूरा पथ निर्दिष्ट किया जा सकता है।
यहाँ एक पकड़ है. डाउनलोड की गई फ़ाइलें सीआरएलएफ लाइन ब्रेक का उपयोग करती हैं, और रूट प्रमाणपत्र में पिछली लाइन फ़ीड नहीं होती है। इसलिए, एक नियमित बिल्ली पहले प्रमाणपत्र के अंत और दूसरे की शुरुआत को एक पंक्ति में जोड़ती है:
-----END CERTIFICATE----------BEGIN CERTIFICATE-----
लिब्रेएसएसएल – और सिस्टम मैकओएस पर ओपनएसएल, मैं आपको याद दिला दूं, बिल्कुल लिब्रेएसएसएल है – ऐसी फ़ाइल को स्वीकार नहीं करता है और एक त्रुटि के साथ प्रतिक्रिया करता है:
PEM routines:CRYPTO_internal:bad end line
इसका मतलब यह है कि अकेली बिल्ली ही काफी नहीं है। प्रत्येक प्रमाणपत्र को पहले ओपनएसएल के माध्यम से चलाया जाना चाहिए: यह इसे एलएफ लाइन फ़ीड और अंतिम लाइन फ़ीड के साथ कैनोनिकल पीईएम में रिकोड करेगा, और उसके बाद ही विलय किया जाएगा:
openssl x509 -in russian_trusted_root_ca_pem.crt -out russian_trusted_root_ca.pem
openssl x509 -in russian_trusted_sub_ca_pem.crt -out russian_trusted_sub_ca.pem
cat russian_trusted_root_ca.pem russian_trusted_sub_ca.pem > russian_trusted_ca_bundle.pem
आप जाँच सकते हैं कि फ़ाइल इस प्रकार पढ़ी जा रही है:
openssl x509 -in russian_trusted_ca_bundle.pem -noout -subject
यदि प्रमाणपत्र किसी अन्य स्रोत से लिए गए हैं और डीईआर या पीकेसीएस#7 प्रारूप में आते हैं, तो उन्हें पीईएम में भी रिकोड किया जा सकता है:
openssl x509 -in cert.crt -inform DER -outform PEM -out cert.pem
openssl pkcs7 -print_certs -in bundle.p7b -out cert.pem
OpenCode से कनेक्ट करें
प्रदाता का वर्णन opencode.jsonc कॉन्फ़िगरेशन फ़ाइल में किया गया है। ओपनकोड स्वयं npm फ़ील्ड में निर्दिष्ट npm पैकेज को डाउनलोड और कनेक्ट करेगा, इसमें createGigaChat फ़ैक्टरी ढूंढेगा और उसमें विकल्प पास करेगा। एपीआई से मॉडलों को उनके पहचानकर्ताओं द्वारा सूचीबद्ध करना पर्याप्त है।
फ़ाइल को दो स्थानों पर रखा जा सकता है:
- वैश्विक – ~/.config/opencode/opencode.jsonc. सेटिंग सभी उपयोगकर्ता प्रोजेक्ट पर लागू होती हैं।
- प्रोजेक्ट में – प्रोजेक्ट रूट में opencode.jsonc। इस कॉन्फिगरेशन की प्राथमिकता अधिक है और गिट के लिए प्रतिबद्ध होना सुरक्षित है।
दोनों फ़ाइलें एक ही योजना का उपयोग करती हैं और संयुक्त होती हैं: प्रोजेक्ट फ़ाइल केवल मिलान कुंजियों के साथ वैश्विक ओवरलैप करती है, शेष सेटिंग्स सहेजी जाती हैं। .jsonc एक्सटेंशन भी समर्थित है। यदि गीगाचैट की आवश्यकता केवल कुछ रिपॉजिटरी के लिए है, तो प्रदाता को वैश्विक के बजाय प्रोजेक्ट कॉन्फ़िगरेशन में रखना अधिक सुविधाजनक है।
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"gigachat": {
"npm": "gigachat-ai-sdk-provider",
"name": "GigaChat",
"models": {
"GigaChat-2-Max": { "name": "GigaChat 2 Max" },
"GigaChat-2-Pro": { "name": "GigaChat 2 Pro" },
"GigaChat-2": { "name": "GigaChat 2 Lite" },
"GigaChat": { "name": "GigaChat" }
}
}
}
}
व्यक्तिगत कुंजी के साथ उपलब्ध मॉडल यहां सूचीबद्ध हैं। यदि आपके पास व्यक्तिगत उद्यमी या गीगाचैट 3 तक पहुंच वाली कानूनी इकाई के लिए कोई प्रोजेक्ट है, तो मॉडल विधि से मॉडल ब्लॉक में आवश्यक पहचानकर्ता जोड़ें।
यह अधिक सुविधाजनक है कि कुंजी को फ़ाइल में ही संग्रहीत न किया जाए, बल्कि इसे एक पर्यावरण चर में पास किया जाए: गीगाचैट-जेएस पैकेज इसे स्वचालित रूप से पढ़ता है। स्कोप मान को एक वेरिएबल पर भी सेट किया जा सकता है। जो कुछ बचा है वह प्रमाणपत्रों के लिए पथ निर्धारित करना और एजेंट को लॉन्च करना है:
export GIGACHAT_CREDENTIALS=ваш_ключ_авторизации
export GIGACHAT_SCOPE=GIGACHAT_API_PERS
export NODE_EXTRA_CA_CERTS=/путь/к/russian_trusted_ca_bundle.pem
opencode
यह विकल्प इसलिए भी अच्छा है क्योंकि रहस्य स्थानीय auth.json संग्रहण में समाप्त नहीं होता है: यह केवल प्रक्रिया के वातावरण में रहता है। यह सीआई और एक बार लॉन्च के लिए अधिक सुविधाजनक है।
मॉडल
उपलब्ध मॉडलों का सेट स्कोप कुंजी पर निर्भर करता है। व्यक्तिगत कुंजी (GIGACHAT_API_PERS) GigaChat और GigaChat 2 परिवार के लिए उपलब्ध है:
- गीगाचैट – मूल मॉडल।
- GigaChat-2 – रोजमर्रा के कार्यों के लिए एक तेज़ और हल्का मॉडल, इंटरफ़ेस में लाइट के रूप में प्रदर्शित होता है।
- GigaChat-2-Pro – संसाधन-गहन कार्यों के लिए एक बेहतर मॉडल।
- GigaChat-2-Max व्यक्तिगत कुंजी का उपयोग करके उपलब्ध सबसे शक्तिशाली है।
GigaChat 3 परिवार (GigaChat-3-Ultra, GigaChat-3-Pro, GigaChat3.5-432B-A28B-रीज़निंग जैसे खुले मॉडल) कंसोल कैटलॉग में दिखाई देता है, लेकिन यह व्यक्तिगत कुंजी के लिए उपलब्ध नहीं है: इसके लिए एक व्यक्तिगत उद्यमी परियोजना या GIGACHAT_API_B2B या GIGACHAT_API_CORP और एक उपयुक्त टैरिफ के साथ एक कानूनी इकाई की आवश्यकता होती है। व्यक्तिगत कुंजी पर, ऐसा मॉडल एक त्रुटि के साथ प्रतिक्रिया करता है:
{"status":404,"message":"No such model"}
आप मॉडलों की सूची पूछकर जांच सकते हैं कि आपकी कुंजी वास्तव में क्या आउटपुट देती है:
curl -H "Authorization: Bearer <токен_доступа>" https://gigachat.devices.sberbank.ru/api/v1/models
दो और अंक. एपीआई में मॉडल आईडी प्रदर्शित नामों से मेल नहीं खाते – लाइट मॉडल को GigaChat-2 कहा जाता है, GigaChat-2-Lite नहीं। और कंसोल में कैटलॉग वही चीज़ नहीं दिखाता है जो आपकी कुंजी के लिए उपलब्ध है, इसलिए आपको मॉडल विधि की प्रतिक्रिया पर ध्यान केंद्रित करना चाहिए, न कि कीमतों वाली सूची पर।
इंटरफ़ेस में, मॉडलों की सूची कमांड के साथ खोली जाती है:
/models
रिपॉजिटरी में नियमित काम के लिए – फ़ाइलों के माध्यम से नेविगेट करना, छोटे संपादन, परीक्षण चलाना – GigaChat-2 काफी है। जटिल कार्यों और डिज़ाइन के लिए, प्रो या मैक्स पर स्विच करना समझ में आता है।
प्रोजेक्ट में पहला लॉन्च
प्रोजेक्ट निर्देशिका पर जाएँ और एजेंट लॉन्च करें:
cd ваш_проект
opencode
पहला कदम एजेंट को आरंभ करना है:
/init
ओपनकोड परियोजना संरचना का विश्लेषण करेगा और एक फ़ाइल AGENTS.md बनाएगा – एजेंट के लिए निर्देश। यह फ़ाइल गिट के लिए प्रतिबद्ध है: यह एजेंट को प्रोजेक्ट में अपनाई गई परंपराओं और पैटर्न को समझने में मदद करती है।
वैकल्पिक: स्थानीय प्रॉक्सी
यदि किसी कारण से आप एनपीएम प्रदाता का उपयोग नहीं करना चाहते हैं, तो स्थानीय प्रॉक्सी वही परिणाम देता है। गीगाचैट टीम के पास एक आधिकारिक gpt2giga – फास्टएपीआई सेवा है जो ओपनएआई, एंथ्रोपिक और जेमिनी प्रारूप में अनुरोधों को गीगाचैट एपीआई में अनुवादित करती है और एक्सेस टोकन को स्वयं अपडेट करती है। इसे स्थानीय रूप से पोर्ट 8090 पर उठाया जाता है, जिसके बाद एक नियमित ओपनएआई-संगत प्रदाता को आधार पते http://localhost:8090/v1 के साथ @ai-sdk/openai-compatible पैकेज के माध्यम से ओपनकोड में कॉन्फ़िगर किया जाता है। इस पथ का नकारात्मक पक्ष यह है कि आपको ओपनकोड के बगल में एक चालू पायथन सेवा भी रखनी होगी।
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"gigachat": {
"npm": "@ai-sdk/openai-compatible",
"name": "GigaChat (proxy)",
"options": {
"baseURL": "http://localhost:8090/v1"
},
"models": {
"GigaChat-2-Max": { "name": "GigaChat 2 Max" }
}
}
}
}
DeepSeek और Cloud.ru के माध्यम से अन्य मॉडल
गीगाचैट एपीआई में स्वयं डीपसीक मॉडल नहीं हैं: एम्बेडिंग के लिए केवल गीगाचैट परिवार और मॉडल हैं। यदि आपको ओपनकोड में डीपसीक की आवश्यकता है, लेकिन रूसी क्लाउड गेटवे के माध्यम से, Cloud.ru की फाउंडेशन मॉडल सेवा उपयुक्त है। यह OpenAI-संगत प्रोटोकॉल का उपयोग करके मॉडल वितरित करता है, इसलिए यह मानक @ai-sdk/openai-compatible पैकेज का उपयोग करके जुड़ा हुआ है।
उदाहरण के लिए, Cloud.ru फाउंडेशन मॉडल कैटलॉग में निम्नलिखित मॉडल हैं:
deepseek-ai/DeepSeek-V4.1-Flash
deepseek-ai/DeepSeek-V4-Flash
deepseek-ai/DeepSeek-V4-Pro
कुंजी Cloud.ru कंसोल में जारी की गई है: अनुभाग उपयोगकर्ता, टैब सेवा खाते। हम एक प्रोजेक्ट-स्तरीय सेवा खाता बनाते हैं, फिर उसके क्रेडेंशियल्स में हम फाउंडेशन मॉडल सेवा के साथ एक एपीआई कुंजी बनाते हैं। मुख्य रहस्य एक बार दिखाया जाता है और हम उसे सहेज लेते हैं।
opencode.json में प्रदाता कॉन्फ़िगरेशन इस तरह दिखता है:
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"cloudru": {
"npm": "@ai-sdk/openai-compatible",
"name": "Cloud.ru Foundation Models",
"options": {
"baseURL": "https://foundation-models.api.cloud.ru/v1",
"apiKey": "{env:CLOUDRU_API_KEY}"
},
"models": {
"deepseek-ai/DeepSeek-V4.1-Flash": { "name": "DeepSeek V4.1 Flash", "limit": { "context": 1048576, "output": 1048576 } },
"deepseek-ai/DeepSeek-V4-Flash": { "name": "DeepSeek V4 Flash", "limit": { "context": 1048576, "output": 1048576 } },
"deepseek-ai/DeepSeek-V4-Pro": { "name": "DeepSeek V4 Pro", "limit": { "context": 1048576, "output": 1048576 } }
}
}
}
}
हम पर्यावरण चर की कुंजी पास करते हैं:
export CLOUDRU_API_KEY=ваш_ключ_cloudru
opencode
यहां डिजिटल विकास मंत्रालय के प्रमाणपत्रों की आवश्यकता नहीं है: GigaChat के विपरीत, api.cloud.ru डोमेन में नियमित TLS है। लेकिन यह परियोजना के संतुलन की निगरानी के लायक है। यदि खाता शून्य है, तो प्राधिकरण पास हो जाता है, और बिलिंग प्रतिक्रिया के साथ अनुरोध हटा दिए जाते हैं:
{"message":"Not enough money"}
यह कोई कॉन्फ़िगरेशन त्रुटि नहीं है, बल्कि एक संकेत है कि आपको Cloud.ru कंसोल में प्रोजेक्ट को अपडेट करने की आवश्यकता है।
किस बात पर ध्यान दें
कुछ व्यावहारिक बिंदु जो पहली बार सेटअप करते समय अक्सर आड़े आते हैं:
- प्रमाणपत्र सत्यापन त्रुटि। श्रृंखला में स्व-हस्ताक्षरित प्रमाणपत्र के बारे में संदेश का अर्थ है कि NODE_EXTRA_CA_CERTS वैरिएबल नहीं उठाया गया था। फ़ाइल के पथ की जाँच करें, कि एजेंट एक ही वातावरण में चल रहा है, और फ़ाइल स्वयं: यदि, बिल्ली का उपयोग करके दो प्रमाणपत्रों को विलय करते समय, उनके सिरे एक ही पंक्ति पर समाप्त होते हैं, तो लिब्रेएसएसएल एक खराब अंत रेखा लौटाएगा, और बंडल को ओपनएसएल के माध्यम से फिर से बनाने की आवश्यकता है, जैसा कि प्रमाणपत्रों के बारे में अनुभाग में है।
- त्रुटि 401। एक नियम के रूप में, यह एक गलत प्राधिकरण कुंजी या एक बेमेल दायरा है – एक व्यक्ति के लिए आपको GIGACHAT_API_PERS की आवश्यकता है।
- ऐसा कोई मॉडल नहीं पाठ के साथ त्रुटि 404। यह कनेक्शन विफलता नहीं है, बल्कि एक विशिष्ट मॉडल तक पहुंच की कमी है। इसे कॉन्फिग से हटा दें या किसी उपलब्ध कॉन्फिगरेशन से बदल दें। GigaChat 404: अज्ञात त्रुटि जैसे संदेश में, उसी GigaChat प्रतिक्रिया को दोष दिया जाता है – प्रदाता केवल त्रुटि निकाय को पार्स नहीं कर सका।
- लागत। ओपनकोड को सदस्यता की आवश्यकता नहीं है: जब आप टोकन खर्च करते हैं तो आप सीधे गीगाचैट का भुगतान करते हैं, इसलिए लंबे सत्र की कीमत का अनुमान लगाया जा सकता है।
- मॉडल गुणवत्ता। जटिल वास्तुशिल्प कार्यों के लिए, विभिन्न वर्गों के मॉडल अलग-अलग होते हैं, इसलिए डिज़ाइन के लिए एक मजबूत मॉडल लेना और दिनचर्या को तेज़ बनाना समझ में आता है।
लिंक
https://opencode.ai/
https://opencode.ai/docs/providers/
https://developers.sber.ru/studio/
https://developers.sber.ru/docs/ru/gigachat/guides/main
https://github.com/nyddle/gigachat-ai-sdk-provider
https://github.com/ai-forever/gpt2giga
https://cloud.ru/docs/foundation-models/ug/topics/quickstart
स्रोत
https://opencode.ai/docs/providers/#custom-provider
https://developers.sber.ru/docs/ru/gigachat/certificates
https://developers.sber.ru/docs/ru/gigachat/models/main
https://developers.sber.ru/docs/ru/gigachat/guides/selecting-a-model
https://github.com/nyddle/gigachat-ai-sdk-provider
https://github.com/ai-forever/gpt2giga
https://cloud.ru/docs/foundation-models/ug/topics/quickstart
https://cloud.ru/docs/foundation-models/ug/topics/overview__available__models
