Claude Code vs Codex: दोनों इंजनों को एक ही रिमोट सिस्टम में जोड़ने के बाद हमारे सामने आईं सात प्रोटोकॉल भिन्नताएँ

हित प्रकटीकरण: हम PandaNpc विकसित करते हैं — एक ऐसी प्रणाली जो Claude Code, Codex जैसे कोडिंग एजेंटों को दूरस्थ रूप से एक्सेस करने और कई लोगों द्वारा साझा करने योग्य बनाती है। चूँकि हमें एक ही पेज और एक ही मैसेज चेन में इन कई इंजनों को एक साथ सपोर्ट करना था, हमें उनके प्रोटोकॉल व्यवहार को एक-एक करके संरेखित करना पड़ा। यह लेख इस प्रक्रिया में वास्तव में सामने आई भिन्नताओं के बारे में है, बेंचमार्क तुलना नहीं — हमने कोई तुलनात्मक बेंचमार्क परीक्षण नहीं किया है, इसलिए लेख में गति या सफलता दर जैसे कोई परीक्षण आँकड़े नहीं होंगे। अंत में आगे की योजना बताई गई है।

टिप्पणी: इस लेख में Codex से तात्पर्य OpenAI Codex के कमांड-लाइन टूल से है, न कि इसी नाम के अन्य उत्पादों से।

एक पंक्ति का निष्कर्ष: टर्मिनल में अकेले उपयोग करने पर, दोनों के अनुभव में अंतर आपकी अपेक्षा से कहीं कम है; एक बार जब आप उन्हें अपने सिस्टम (रिमोट कंट्रोल, मल्टी-डिवाइस सिंक, सेशन रिज़्यूम, टूल अनुमोदन) में जोड़ते हैं, तो अंतर लगभग पूरी तरह प्रोटोकॉल परत में केंद्रित हो जाते हैं — और ये अंतर हम उस समय दस्तावेज़ों से पहले से नहीं जान सके, सभी टकराकर पता चले।

यदि आप Codex vs Claude Code खोज रहे हैं और जानना चाहते हैं "कौन सा चुनें", तो यह लेख वह तुलनात्मक समीक्षा नहीं हो सकता जो आप चाहते हैं — यह तुलना नहीं करता कि कौन बेहतर कोड लिखता है, बल्कि एक अधिक विशिष्ट प्रश्न का उत्तर देता है: जब आप उन्हें एक प्रोग्रामेबल बैकएंड के रूप में जोड़ना चाहते हैं, तो आपको क्या सामना करना पड़ेगा।

यह किसे पढ़ना चाहिए

• वे डेवलपर्स जो एक साथ दोनों इंजनों को सपोर्ट करना चाहते हैं, या एक से दूसरे में माइग्रेट करना चाहते हैं
• वे लोग जो रिमोट कंट्रोल / मल्टी-डिवाइस सिंक / सेशन शेयरिंग जैसे सहायक उपकरण बनाना चाहते हैं
• वे लोग जो जानना चाहते हैं "इन दोनों CLI के सेशन मॉडल में वास्तव में क्या अंतर है"

यदि आप केवल अपने कंप्यूटर पर कोड लिखना चाहते हैं और इंटीग्रेशन नहीं करना चाहते, तो इस लेख का मूल्य सीमित है — सीधे दोनों के आधिकारिक दस्तावेज़ देखना तेज़ है।

पहले समानताएँ: "एक जैसा दिखने" का कारण

अंतर बताने से पहले यह स्पष्ट करना आवश्यक है: इन दोनों टूल्स का मेंटल मॉडल काफी समान है — दोनों टर्मिनल में चलते हैं, दोनों सेशन इकाइयों में काम करते हैं, दोनों टूल को कॉल करके फ़ाइलें बदल सकते हैं और कमांड चला सकते हैं, दोनों को खतरनाक कार्यों के लिए उपयोगकर्ता की पुष्टि की आवश्यकता होती है, और दोनों एक सेशन में लगातार कई दौर के कार्यों को संभाल सकते हैं। इसी कारण, इंटीग्रन करते समय "एक एडेप्टेशन लेयर लिखना पर्याप्त है" का निर्णय लेना आसान होता है, और हमने इसी तरह शुरुआत की।

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

सात भिन्नताओं की त्वरित संदर्भ तालिका

#	आयाम	Claude Code का व्यवहार	Codex का व्यवहार	किसे परेशानी होगी यदि संभाला न जाए
1	सहायक संदेश पहचान	स्थिर id के साथ	शायद बिना id के	संदेश पर्सिस्टेंस / मल्टी-डिवाइस सिंक करने वाले
2	सेशन जीवितता जाँच	बैच रूप, एक बार में एक समूह	एकल सेशन id की अपेक्षा करता है	ऑनलाइन स्थिति प्रदर्शन करने वाले
3	इतिहास रीप्ले क्रम	वास्तविक समयक्रम के अनुरूप	उप-थ्रेड गतिविधि फ्रेम पूरे बैच में अंत में	सब-एजेंट / मल्टी-थ्रेड व्यू बनाने वाले
4	टूल कॉल कमांड संरचना	पूर्ण	संभवतः खंडित	टूल अनुमोदन UI बनाने वाले
5	चैनल इवेंट सब्सक्रिप्शन	सेशन स्विच का निष्पादक	स्विच एक साथ निष्पादित नहीं कर सकता	मल्टी-रिले करने वाले
6	ऑनलाइन कनेक्शन कोटा	Codex के साथ एक ही गणना पूल	बाईं ओर समान	कोटा सीमा लगाने वाले
7	लंबे इतिहास का प्रदर्शन	रैखिक	गलत तरीके से संभालने पर गैर-रैखिक	मोबाइल के लिए काम करने वाले

नीचे प्रत्येक बिंदु का विस्तार है, प्रत्येक "लक्षण → निदान कैसे करें → समाधान कैसे करें" प्रारूप में।

एक: क्या सहायक संदेश में स्थिर id होती है — यह आपकी डीडुप्लीकेशन रणनीति तय करता है

लक्षण: एक Codex सेशन खोलें, बातचीत के तुरंत बाद सब कुछ सामान्य लगता है; बाहर निकलकर फिर से खोलने पर, वही सहायक उत्तर 2, 3 प्रतियों में दिखाई देता है, और बार-बार खोलने पर और बढ़ता जाता है। उपयोगकर्ता द्वारा भेजे गए संदेश प्रभावित नहीं होते, केवल सहायक उत्तर बढ़ते हैं। Claude Code के सेशन में ऐसा नहीं होता।

निदान कैसे करें: यह लक्षण आसानी से क्लाइंट रेंडरिंग समस्या या इतिहास लोडिंग में डुप्लीकेशन के रूप में गलत निदान किया जा सकता है, और फिर सीधे फ्रंटएंड में खोजबीन शुरू हो जाती है। सही पहला कदम यह देखना है कि सर्वर कैश में वास्तव में कितनी प्रतियाँ संग्रहीत हैं — यदि कैश में वास्तव में N प्रतियाँ हैं, तो समस्या डेटा परत में है, रेंडरिंग से संबंधित नहीं। हमने इसी कदम से अपनी दिशा क्लाइंट से वापस सही जगह खींची।

मूल कारण: Claude Code के सहायक संदेशों में स्थिर पहचान होती है, इसलिए रीप्ले और रीयल-टाइम पुश आने पर id के आधार पर सीधे डीडुप्लीकेशन किया जा सकता है। Codex की ओर सहायक संदेशों में ऐसी पहचान होने की गारंटी नहीं होती, इसलिए वही "id-आधारित डीडुप्लीकेशन" तर्क उपयोग करने पर, एक ही उत्तर को दो अलग-अलग संदेशों के रूप में लिख दिया जाता है।

समाधान कैसे करें: स्थिर id के बिना संदेशों के लिए, "राउंड एंकर + सामग्री" फोल्डिंग का उपयोग करें — एंकर इस उत्तर से पहले के निकटतम उपयोगकर्ता संदेश का हैश लेता है।

⚠️ यहाँ एक खतरा है जिसका अलग से उल्लेख करना उचित है: हमारा पहला संस्करण शुद्ध टेक्स्ट फोल्डिंग पर आधारित था। लॉन्च के बाद इतिहास डेटा स्कैन करने पर पता चला कि इसने 691 क्रॉस-राउंड समान उत्तर गलती से हटा दिए। कारण यह था कि Codex के छोटे उत्तरों की पुनरावृत्ति दर बहुत अधिक है ("ठीक है।" "पूर्ण।" जैसे उत्तर), और डीडुप्लीकेशन सेट सेशन-स्तरीय था — एक बार किसी वाक्य का हैश दर्ज हो जाने पर, उसी सेशन में बाद के किसी भी राउंड में वही वाक्य हटा दिया जाएगा। यह सामग्री हानि है, जो डुप्लीकेशन से कहीं अधिक गंभीर है। एंकर परत को छोड़ा नहीं जा सकता।

दो: जीवितता जाँच: एक एकल की अपेक्षा करता है, दूसरा बैच की

लक्षण: सेशन वास्तव में चल रहा है, लेकिन इंटरफ़ेस पर ऑफ़लाइन दिखाई देता है।

निदान कैसे करें: यह अंतर ऐसा दिखता है जैसे इसे सामान्यीकृत किया जा सकता है — दोनों ओर फ़ील्ड नाम समान हैं, इसलिए लिखते समय आसानी से लगता है कि एक ही कोड दोनों को संभाल सकता है। निर्णय का तरीका सरल है: बैच संरचना भेजें और देखें कि क्या रिटर्न अपेक्षित आकार का है।

मूल कारण: "क्या यह सेशन अभी भी जीवित है" की जाँच के लिए दोनों ओर के इंटरफ़ेस का रूप अलग है। Claude Code की ओर हमने बैच रूप का उपयोग किया, एक बार में एक समूह के सेशन id भेजे; Codex की ओर एकल सेशन id की अपेक्षा की जाती है।

समाधान कैसे करें: दो अलग-अलग कॉल पथ बनाएँ, साझा करने की कोशिश न करें। यह अंतर अपने आप में कठिन नहीं है; असली समस्या यह है कि यह कोई त्रुटि नहीं देता — गलत संरचना भेजने पर कोई अपवाद नहीं उठता, बस एक अर्थपूर्ण रूप से गलत उत्तर मिलता है।

तीन: इतिहास रीप्ले में फ्रेम क्रम अलग होता है — सब-एजेंट स्थिति अटक जाती है

यह सबसे उलझाने वाला निदान पथ है।

लक्षण: साइडबार में सब-एजेंट स्थिति बिंदु लगातार नारंगी "चालू" रहकर साँस लेता रहता है, जबकि वह वास्तव में बहुत पहले समाप्त या बाधित हो चुका होता है। पेज रीफ्रेश करने पर भी वापस नहीं जाता — हर रीफ्रेश पर फिर से गलत दिखता है। यह केवल Codex सेशन में होता है।

निदान कैसे करें: "रीफ्रेश करने पर भी वापस नहीं जाता" मुख्य निर्णायक मानदंड है। यह दर्शाता है कि समस्या रीयल-टाइम पुश में नहीं, बल्कि इतिहास रीप्ले में ही है — हर रीप्ले स्थिति को फिर से गलत तरीके से लिख देता है।

मूल कारण: रीप्ले के दौरान पहले पैरेंट थ्रेड की सभी प्रविष्टियाँ पूरी कर दी जाती हैं (जिनमें "सब-एजेंट समाप्त हो गया" के सूचना फ्रेम भी शामिल हैं), फिर प्रत्येक सब-थ्रेड की गतिविधि फ्रेम पूरे बैच में अंत में जोड़ दी जाती हैं। इससे क्लाइंट को जो क्रम मिलता है वह है: पहले "बाधित" की सूचना दिखती है, फिर समय में पहले की गतिविधि फ्रेम दिखती हैं। और स्थिति लिखने वाला तर्क टाइमस्टैम्प की तुलना नहीं करता, इसलिए अंत में आने वाले पहले के फ्रेम अंतिम स्थिति को बिना शर्त वापस "चालू" में बदल देते हैं।

समाधान कैसे करें: स्थिति लिखने वाली शाखा में अंतिम-स्थिति गार्ड जोड़ें — जो पहले से अंतिम स्थिति (पूर्ण/विफल/रोका गया) में है, उसे केवल बाद के फ्रेम ही ओवरराइट कर सकते हैं। ध्यान दें कि निर्णय मानदंड को अन्य स्थानों के साथ एक ही स्थिति मैपिंग साझा करनी चाहिए, अलग से नई मैपिंग न बनाएँ, अन्यथा दोनों जगहों की "अंतिम स्थिति क्या है" की समझ में अंतर आ जाएगा।

इस प्रकार की समस्याओं की सामान्य विशेषता: अकेले देखने पर हर फ्रेम मान्य है, गलती उनके सापेक्ष क्रम में है। इसलिए केवल एकल फ्रेम के लॉग देखकर समस्या कभी नहीं दिखेगी।

चार: टूल कॉल कमांड की संरचना: खंडित हो सकती है

लक्षण: Codex सेशन के टूल कार्ड में, कमांड 1,220p या /pid=…/ {print} जैसे खंडों में दिखाई देते हैं, कभी-कभी पूरी स्क्रिप्ट कट जाती है, और उत्तर समाप्त होने के बाद भी अनपूर्ण टूल कार्ड लटके रहते हैं।

निदान कैसे करें: रेंडर किए गए परिणाम को नहीं, बल्कि मूल फ्रेम में कमांड फ़ील्ड की वास्तविक संरचना देखें। यदि आप Claude Code वाले फ़ील्ड पथ से "उपयोगकर्ता ने कौन सा कमांड चलाया" निकालते हैं, तो आपको खंडित टुकड़े मिलेंगे।

समाधान कैसे करें: Codex के लिए अलग से एक कमांड पुनर्संरचना परत लिखें, खंडों को जोड़कर पूर्ण कमांड बनाएँ और फिर UI को दें।

यह अंतर टूल अनुमोदन करने वालों के लिए विशेष रूप से गंभीर है: उपयोगकर्ता को फ़ोन पर "अनुमति दें / अस्वीकार करें" दबाना होता है, लेकिन कार्ड पर कमांड खंडित दिखाई देता है — यह अंधे हस्ताक्षर करने जैसा है। सुरक्षा सुविधा का अर्थ समाप्त हो जाना केवल खराब दिखने से कहीं अधिक गंभीर है।

पाँच: चैनल इवेंट की सदस्यता सतह अलग है

लक्षण: दो उपयोगकर्ता एक-दूसरे को लॉगआउट करा देते हैं।

मूल कारण: यदि दोनों रिले लिंक "सेशन स्विच" जैसे इवेंट की सदस्यता लेते हैं और उसे निष्पादित करते हैं, तो दोनों ओर से एक-एक पीड़ित को बाहर निकाला जाएगा, जिससे दोहरा निष्कासन बनेगा। स्विच क्रिया का एकमात्र निष्पादक होना चाहिए।

समाधान कैसे करें: हमारा तरीका यह था कि Codex वाली लिंक केवल किक-आउट और कैश इनवैलिडेशन इवेंट की सदस्यता ले, स्विच इवेंट की कभी नहीं, और स्विच का निष्पादन अधिकार दूसरी लिंक पर स्थिर कर दिया।

इस प्रकार के "जानबूझकर कुछ न करने" के निर्णय कोड में आमतौर पर केवल एक पंक्ति की टिप्पणी में छोड़े जाते हैं, लेकिन यह एक बार गलती होने के बाद ही जोड़ी गई थी — और एक बार यह बाधा किसी बाद के डेवलपर द्वारा "सुविधा के लिए पूरी" कर दी जाए, तो दुर्घटना दोबारा होगी। इसलिए टिप्पणी में स्पष्ट रूप से लिखें कि यह क्यों नहीं किया जाता, न कि केवल यह कि नहीं किया जाता।

छह: कोटा और कनेक्शन गणना संयुक्त है

लक्षण: उपयोगकर्ता सोचता है कि अभी कोटा शेष है, जबकि वास्तव में वह समाप्त हो चुका है।

मूल कारण: यदि आप हमारी तरह ऑनलाइन कनेक्शन की संख्या पर सीमा लगाते हैं, तो ध्यान दें कि दोनों इंजनों के कनेक्शन एक ही गणना पूल में आते हैं। जब उपयोगकर्ता एक साथ Claude Code और Codex के सेशन खोलता है, तो वही कोटा उपयोग होता है।

यह दोष नहीं है, यह डिज़ाइन विकल्प है — उपयोगकर्ता के दृष्टिकोण से "मैं एक साथ कुल कितने सेशन खोल सकता हूँ" "प्रत्येक इंजन के कितने खोल सकते हैं" से अधिक समझने योग्य है। लेकिन यदि आपका कार्यान्वयन प्रत्येक इंजन के लिए अलग-अलग गणना करता है, तो फ्रंटएंड पर दिखाई देने वाला शेष बैकएंड की वास्तविक कटौती से मेल नहीं खाएगा।

समाधान कैसे करें: पहले स्पष्ट करें कि आपको कौन सा मापदंड चाहिए, फिर सुनिश्चित करें कि फ्रंटएंड और बैकएंड एक ही मापदंड का उपयोग करें। दो मापदंडों को मिलाना गलत मापदंड चुनने से भी बदतर है।

सात: इतिहास के आकार बढ़ने पर प्रदर्शन की विशेषताएँ अलग होती हैं

लक्षण: मोबाइल पर लंबे इतिहास वाला सेशन खोलने पर हैंग हो जाता है।

मूल कारण: हमें iOS पर एक बार स्पष्ट फ़्रीज़ का सामना करना पड़ा, जिसका मूल कारण इतिहास प्रसंस्करण में संदेशों की संख्या के साथ द्विघात वृद्धि वाला ऑपरेशन था। यह स्पष्ट करना आवश्यक है कि यह इंजन की अपनी समस्या नहीं है, बल्कि उसकी इतिहास संरचना का हमारे मूल प्रसंस्करण तरीके से मेल न खाना है — वही प्रसंस्करण तरीका दूसरे इंजन पर कोई समस्या नहीं दिखाता।

समाधान कैसे करें: संदेशों की संख्या के साथ बढ़ने वाले दोहराए जाने वाले स्कैन को एक बार के इंडेक्स से बदलें। इससे भी महत्वपूर्ण है पहले से डिज़ाइन करना: लंबे इतिहास को शुरुआत से ही ध्यान में रखना चाहिए, उपयोगकर्ता के हजारों संदेश जमा करने के बाद पता चलने का इंतज़ार नहीं करना चाहिए।

तो किसे चुनें

पहले स्पष्ट करें: नीचे दी गई सलाह इंटीग्रेशन दृष्टिकोण पर आधारित है, कोडिंग क्षमता का मूल्यांकन नहीं। हमने कोई तुलनात्मक बेंचमार्क परीक्षण नहीं किया है, और कोई भी दावा कि "कोई चीज़ कितनी तेज़ है" इस लेख से नहीं आएगा।

Codex चुनना कब अधिक उपयुक्त है

1. आपकी टीम पहले से OpenAI इकोसिस्टम में है — खाता, कोटा और बिलिंग एक ही स्थान पर हैं, एक कम वित्तीय और क्रेडेंशियल प्रबंधन, इस सुविधा को कम आंकना नहीं चाहिए।
2. आपकी प्रक्रियाएँ पहले से उसके सेशन और कार्य मॉडल के आसपास बनी हैं — माइग्रेशन के लिए सहायक टूल्स को फिर से बनाना आमतौर पर उचित नहीं होता, ऊपर की सात भिन्नताएँ उलटी माइग्रेशन लागत हैं।

Claude Code चुनना कब अधिक उपयुक्त है

1. आपको सहायक टूल्स खुद बनाने हैं — हमारे इंटीग्रेशन अनुभव से, संदेशों में स्थिर पहचान होने से पर्सिस्टेंस और मल्टी-डिवाइस सिंक कहीं आसान हो जाता है, पहली, तीसरी और चौथी भिन्नताएँ इसी ओर आसानी से संभाली जाती हैं।
2. आपको टूल अनुमोदन जैसी इंटरैक्शन बनानी है — कमांड संरचना पूर्ण होती है, अनुमोदन UI बनाते समय अतिरिक्त जोड़ने की आवश्यकता नहीं होती, इसलिए "अंधा हस्ताक्षर" का जोखिम नहीं होता।

दोनों में से कोई न चुनने की स्थिति

यदि आपकी आवश्यकता केवल "समान इंटरैक्शन के लिए मॉडल बदलना" है, तो इंजन बदलने से बेहतर है मॉडल बैकएंड बदलना। हमने PandaCode बनाने का एक कारण यही है: इंटरैक्शन परत अपरिवर्तित रखें, मॉडल बदल दें।

यदि आप माइग्रेट करना चाहते हैं: सात भिन्नताओं के अनुरूप बदलाव की मात्रा

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

स्पष्टीकरण आवश्यक: यह खंड पूर्व की सात भिन्नताओं से निकाला गया बदलाव का अनुमान है, यह हमारे द्वारा किए गए पूर्ण माइग्रेशन का रिकॉर्ड नहीं है — हमारा रास्ता "एक साथ जोड़ना" था, न कि "एक से दूसरे में बदलना"। इसलिए इसे जाँच सूची के रूप में उपयोग करें, कार्य घंटे के अनुमान के रूप में नहीं।

Claude Code से Codex में माइग्रेट करने पर, बदलाव इन स्थानों पर केंद्रित होगा:

• डीडुप्लीकेशन तर्क फिर से लिखना होगा (पहली भिन्नता) — यह सबसे अधिक कम आंका जाने वाला बिंदु है। id-आधारित डीडुप्लीकेशन वाला मूल कोड सीधे उपयोग नहीं किया जा सकता, और गलती होने पर कोई त्रुटि नहीं दिखती, केवल चुपचाप अतिरिक्त संदेश या चुपचाप खोए संदेश होते हैं। यदि आपके पास संदेश पर्सिस्टेंस है, तो माइग्रेशन से पहले यह सोच लें कि एंकर क्या लेना है।
• ऑनलाइन स्थिति जाँच का कॉल रूप बदलना होगा (दूसरी भिन्नता) — काम की मात्रा कम है, लेकिन छूट जाने पर "चल रहा है फिर भी ऑफ़लाइन दिखता है" की स्थिति बनेगी, और कोई अपवाद नहीं उठेगा।
• इतिहास समयक्रम पर निर्भर सभी सुविधाओं की फिर से जाँच करनी होगी (तीसरी भिन्नता) — सब-एजेंट व्यू, प्रोग्रेस बार, और कोई भी "इतिहास से वर्तमान स्थिति का अनुमान" तर्क इसी श्रेणी में आता है।
• टूल अनुमोदन UI में कमांड पुनर्संरचना परत जोड़नी होगी (चौथी भिन्नता) — यदि आपके उत्पाद में अनुमोदन सुविधा है, तो इसे छोड़ा नहीं जा सकता, अन्यथा उपयोगकर्ता को अंधे हस्ताक्षर करने जैसा होगा।

उल्टी दिशा (Codex से Claude Code) आमतौर पर अधिक आसान होती है: डीडुप्लीकेशन id-आधारित पर सरल किया जा सकता है, कमांड संरचना को पुनर्संरचना परत की आवश्यकता नहीं होती। लेकिन ध्यान दें Codex के लिए लिखी गई संगतता परत को सीधे हटाएँ नहीं — यदि आप एक साथ दोनों को सपोर्ट करने की क्षमता रखना चाहते हैं, तो वह तर्क एक संपत्ति है, देनदारी नहीं।

दोनों दिशाओं में फिर से पुष्टि करने योग्य: कोटा मापदंड (छठी भिन्नता) और लंबे इतिहास का प्रदर्शन (सातवीं भिन्नता)। इन दोनों का इंजन से संबंध उतना सीधा नहीं है, लेकिन ये इंजन बदलने के बाद सबसे अधिक भूली जाने वाली पुनः परीक्षण वाली चीज़ें हैं।

एक सुझाव: यदि आपका सिस्टम पहले से लाइव है और उसमें मौजूदा सेशन डेटा है, तो माइग्रेशन से पहले नए तर्क को मौजूदा डेटा पर एक बार चलाकर तुलना करें, सीधे स्विच न करें। हमारा वह 691 प्रविष्टियाँ गलती से हटाने वाला सबक इसी से मिला — तर्क देखने में सही लग रहा था, लेकिन इतिहास डेटा स्कैन करने पर पता चला कि वह सामग्री निगल जाता है। नया तर्क सही होने का मतलब मौजूदा डेटा के लिए सुरक्षित होना नहीं है।

हमारा तरीका: चुनाव नहीं, दोनों जोड़ना

क्योंकि हमें एक साथ दोनों को सपोर्ट करना था, हमारा अंतिम निष्कर्ष यह था कि भिन्नताओं को मध्य परत में समाहित करें — ऊपर की ओर एकीकृत संदेश और सेशन मॉडल प्रदर्शित करें, नीचे की ओर इंजन के अनुसार अनुकूलन करें। लागत यह है कि हर नया इंजन जोड़ने पर ऊपर की सात प्रकार की व्यवहारों को फिर से संरेखित करना पड़ता है; लाभ यह है कि उपयोगकर्ता एक ही इंटरफ़ेस में स्वतंत्र रूप से इंजन बदल सकते हैं, और सेशन, इतिहास तथा अनुमोदन का अनुभव एक समान रहता है।

नया इंजन जोड़ने के लिए सत्यापन सूची

यदि आप भी इस रास्ते पर जाना चाहते हैं, तो इस क्रम में सत्यापन करने की सलाह दी जाती है, पहली चार चीज़ें तय करती हैं कि उपयोग हो सकता है या नहीं, बाद की तीन तय करती हैं कि प्रोडक्शन में समस्या होगी या नहीं:

1. संदेश पहचान — क्या सहायक संदेशों में स्थिर id होती है? यदि नहीं, तो आपका डीडुप्लीकेशन एंकर क्या है?
2. सेशन जीवितता — जीवितता जाँच इंटरफ़ेस एकल लेता है या बैच? गलत संरचना भेजने पर त्रुटि आएगी या चुपचाप गलत उत्तर मिलेगा?
3. इतिहास रीप्ले क्रम — क्या रीप्ले किया गया फ्रेम क्रम वास्तविक समयक्रम से मेल खाता है? विशेष रूप से जब उप-थ्रेड हों।
4. टूल कॉल संरचना — क्या कमांड फ़ील्ड निकालने पर पूर्ण मिलती है? क्या वह खंडित हो सकती है?
5. इवेंट सदस्यता सतह — किन इवेंट्स का एकमात्र निष्पादक होना आवश्यक है? दोहरा निष्पादन होने पर क्या होगा?
6. कोटा मापदंड — गणना इंजन के अनुसार अलग है या संयुक्त? फ्रंटएंड और बैकएंड एक समान हैं?
7. लंबे इतिहास का प्रदर्शन — जब संदेशों की संख्या दस गुना बढ़ती है, तो प्रसंस्करण समय रैखिक बढ़ता है या उससे तेज़?

प्रत्येक बिंदु के लिए सलाह है कि पहले छोटे डेटा पर जाँच करें, फिर बड़े इतिहास पर जाँच करें — तीसरी और सातवीं चीज़ें केवल डेटा की मात्रा बढ़ने पर ही सामने आती हैं।

लक्षण से उल्टा खोजें: आप किस बिंदु से टकराए हैं

यदि आप पहले से ही समस्या में हैं, तो लक्षण से उल्टा अनुमान लगाना आमतौर पर दस्तावेज़ पढ़ने से तेज़ होता है:

आपका दिखाई देने वाला लक्षण	संभावित बिंदु	एक-कदम पहचान का तरीका
बाहर निकलकर फिर से खोलने पर सहायक उत्तर बढ़ जाते हैं	पहला बिंदु (संदेश पहचान)	सीधे देखें कि सर्वर कैश में कितनी प्रतियाँ हैं — डेटा परत है या रेंडरिंग परत, एक नज़र में पता चल जाता है
सेशन चल रहा है फिर भी ऑफ़लाइन दिखता है	दूसरा बिंदु (जीवितता जाँच)	जाँचें कि जीवितता अनुरोध एकल है या बैच संरचना
सब-एजेंट स्थिति "चालू" में अटकी है, रीफ्रेश करने पर भी वापस नहीं जाती	तीसरा बिंदु (रीप्ले क्रम)	"रीफ्रेश करने पर भी वापस नहीं जाना" ही मानदंड है: समस्या रीप्ले में है, रीयल-टाइम पुश में नहीं
टूल कार्ड में कमांड खंडित है / उत्तर समाप्त होने पर भी टूल कार्ड लटके हैं	चौथा बिंदु (कमांड संरचना)	मूल फ्रेम में कमांड फ़ील्ड की संरचना देखें, रेंडर परिणाम नहीं
दो उपयोगकर्ता एक-दूसरे को लॉगआउट करा देते हैं	पाँचवाँ बिंदु (सदस्यता सतह)	जाँचें कि क्या दो निष्पादक एक साथ स्विच इवेंट संभाल रहे हैं
फ्रंटएंड दिखाता है कोटा शेष है, बैकएंड समाप्त हो चुका है	छठा बिंदु (कोटा मापदंड)	पुष्टि करें कि फ्रंटएंड और बैकएंड इंजन के अनुसार अलग गिनते हैं या संयुक्त
मोबाइल पर लंबा सेशन खोलने पर हैंग	सातवाँ बिंदु (लंबा इतिहास)	संदेशों की संख्या दोगुनी वाले सेशन से समय की तुलना करें, देखें कि गैर-रैखिक है या नहीं

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

सामान्य प्रश्न (FAQ)

क्या Codex CLI और OpenAI Codex एक ही चीज़ हैं? इस लेख में चर्चित Codex का अर्थ OpenAI के कमांड-लाइन कोडिंग टूल से है। बाज़ार में अन्य उत्पाद भी हैं जिन्हें Codex कहा जाता है (कुछ कानूनी और अनुपालन क्षेत्र के सॉफ़्टवेयर सहित), खोजते समय भ्रम हो सकता है, "CLI" या "OpenAI" जोड़कर सीमित करना अधिक सटीक रहेगा।

क्या ये भिन्नताएँ संस्करणों के साथ बदलेंगी? हाँ। ऊपर प्रत्येक बिंदु एक विशिष्ट समय पर सामने आया व्यवहार है, और दोनों इंजन तेज़ी से विकसित हो रहे हैं। इसलिए वह सत्यापन सूची अधिक महत्वपूर्ण है — विशिष्ट भिन्नताएँ बदल सकती हैं, लेकिन जिन आयामों को सत्यापित करने की आवश्यकता है वे बहुत नहीं बदलेंगे।

क्या दोनों इंजनों को एक साथ जोड़ा जा सकता है? हाँ, हमने यही किया है। कुंजी भिन्नताओं को मध्य परत में समाहित करना है, न कि उन्हें UI परत में फैलाने देना — अन्यथा हर नया इंजन जोड़ने पर इंटरफ़ेस तर्क को एक बार फिर से विभाजित करना होगा।

आगे की योजना

हम तुलनात्मक कार्य परीक्षणों का एक सेट जोड़ने की योजना बना रहे हैं (एक ही कार्यों का बैच, निश्चित संस्करण, सार्वजनिक पद्धति और मूल आउटपुट), और परिणाम इस लेख में अपडेट किए जाएँगे। उससे पहले, इस लेख में कोई प्रदर्शन या सफलता दर के आँकड़े नहीं हैं — जो चीज़ हमने परीक्षण नहीं की, उसे परीक्षण किया हुआ नहीं लिखेंगे।

---

यह लेख Claude Code और OpenAI Codex को एक ही रिमोट एक्सेस प्रणाली में जोड़ने के हमारे वास्तविक इंजीनियरिंग अनुभव पर आधारित है, अंतिम अद्यतन 2026-08-26 को। दोनों इंजन लगातार अपडेट हो रहे हैं, विशिष्ट व्यवहार के लिए कृपया उनके आधिकारिक दस्तावेज़ देखें।