Codex CLI OpenAI के Responses API का उपयोग करता है, /v1/chat/completions का नहीं। GetVibe integration के लिए wire_api = "responses" आवश्यक है; किसी generic SDK उदाहरण से कॉपी किया गया chat-completions base URL इसका विकल्प नहीं है। जेनरेट किया गया सेटअप Codex CLI docs में मेंटेन किया जाता है और इसे /api/integrations/codex.toml से रीफ़्रेश किया जा सकता है।
इंस्टॉल करें और key सेट करें
CLI इंस्टॉल करें और इसकी config directory बनाएँ। API key को environment में रखें, TOML फ़ाइल के अंदर नहीं:
npm install -g @openai/codex
mkdir -p ~/.codex
export GETVIBE_API_KEY="your-dashboard-key"इस provider block को ~/.codex/config.toml में जोड़ें:
model = "gpt-5.6-luna"
model_provider = "getvibe"
model_reasoning_effort = "medium"
model_reasoning_summary = "auto"
model_context_window = 786432
[model_providers.getvibe]
name = "GetVibe"
base_url = "https://getvibeapi.com/v1"
env_key = "GETVIBE_API_KEY"
wire_api = "responses"
request_max_retries = 4
stream_max_retries = 5
stream_idle_timeout_ms = 600000TOML value में $GETVIBE_API_KEY न रखें। Codex env_key द्वारा बताए गए variable को पढ़ता है; config फ़ाइल के अंदर मौजूद text shell द्वारा expand नहीं होता। Team-managed setup के लिए environment variable को उस shell profile या secret manager के ज़रिए provision करें जो Codex लॉन्च करता है।
Responses को support करने वाला model चुनें
जेनरेट किया गया Codex config प्रकाशित catalog से बनाया जाता है और इसमें एक coding model के साथ fast और deep tasks के लिए profiles की सिफारिश की जाती है। कोई दूसरा model चुनने से पहले जाँच लें कि वह Responses API के लिए सूचीबद्ध है और उसमें वह context limit उपलब्ध है जिसे आप सेट करना चाहते हैं। 3 अक्टूबर 2026 को जाँचे गए catalog snapshot में, GPT-6 Luna की कीमत $0.0055 इनपुट · $0.0274 आउटपुट प्रति 10 लाख टोकन, GPT-6 Sol की $0.1096 इनपुट · $0.548 आउटपुट प्रति 10 लाख टोकन, और GPT-6.1 Sol की $0.1096 इनपुट · $0.548 आउटपुट प्रति 10 लाख टोकन प्रति million input और output tokens है। हर value live model page से render की जाती है।
जब अलग-अलग task classes की cost और reasoning आवश्यकताएँ अलग हों, तब profile उपयोगी होती है। Summaries या commit messages के लिए fast profile रखें और cross-file changes के लिए deeper profile। Project का generated config इस pattern का उदाहरण देता है और public catalog में बदलाव होने पर अपने recommended IDs अपडेट करता है। Context window को hand-edit करके model page की supported limit से अधिक न करें: ऐसा करने पर Codex upstream में fail होने वाली oversized request भेज सकता है।
Read-only repository task से verify करें
Codex को disposable checkout में शुरू करें। उससे बिना editing किए किसी एक function को समझाने के लिए कहें। पुष्टि करें कि वह GetVibe provider का उपयोग कर रहा है और request पूरी हो रही है। फिर explicit permission review के साथ एक छोटा patch माँगें। यदि CLI कहता है कि provider missing है, तो exact table name और यह जाँचें कि model_provider उससे match करता है। यदि authentication fail हो, तो उसी shell में GETVIBE_API_KEY verify करें जिसमें Codex लॉन्च किया जा रहा है।
जब response कहे कि वह tools का उपयोग नहीं कर सकता, तो पहले चुने गए model का Responses support और CLI version verify करें। General catalog में किसी model ID का दिखाई देना यह नहीं दर्शाता कि उसके लिए हर protocol उपलब्ध है। Logs में exact model ID रखें, ताकि tool failure को endpoint या auth failure से अलग पहचाना जा सके।
Context और agent cost नियंत्रित करें
Codex repository files पढ़ता है और अपनी conversation के हिस्से के रूप में tool results वापस भेजता है। Ignore settings के ज़रिए generated output और dependency directories को exclude करें, उससे केवल relevant paths inspect करने के लिए कहें और हर prompt में बहुत बड़ी specification दोहराने से बचें। Agent task की cost में हर turn शामिल होता है, केवल final patch नहीं। Representative task के बाद dashboard usage की तुलना model page की input और output rates से करें।
Fair model comparison के लिए समान repository commit, prompt, approval policy और tests रखें। एक bug fix और एक cross-file task का उपयोग करें, फिर test success और repair turns की संख्या का score करें। 3 अक्टूबर 2026 को GPT-6 Luna का catalog rate $0.0055 इनपुट · $0.0274 आउटपुट प्रति 10 लाख टोकन दिखाया गया है; वास्तविक request bill इस बात पर निर्भर करता है कि task कितना context और output उपयोग करता है।
Profiles और सुरक्षित defaults
सामान्य coding task के लिए medium reasoning से शुरू करें, फिर speed के लिए low और कठिन reasoning के लिए high की तुलना करें, जहाँ model इन settings को support करता हो। अधिक reasoning से output usage बढ़ सकता है। आदतन बहुत बड़ा global context सेट करने से बचें; generated file एक measured model-specific window चुनती है। Codex के approval behavior को तब तक enabled रखें, जब तक आप समझ न लें कि वह कौन-से commands प्रस्तावित करता है।
यदि CLI सफलतापूर्वक शुरू हो जाता है लेकिन GetVibe तक कभी नहीं पहुँचता, तो केवल आपके द्वारा edit की गई फ़ाइल नहीं, बल्कि effective config inspect करें: Codex किसी अन्य profile या config location के साथ लॉन्च हो सकता है। एक harmless request चलाएँ, dashboard में usage जाँचें और उसके बाद ही इसे किसी महत्वपूर्ण repository पर उपयोग करें।
दोहराए जाने वाले task classes के लिए profiles का उपयोग करें
Codex profiles किसी team को एक provider रखते हुए task के अनुसार model और reasoning effort बदलने देती हैं। Fast profile किसी diff का summary बना सकती है या commit message draft कर सकती है; deep profile multi-file failure की जाँच कर सकती है। अपनी team के documentation में profile name को command में रखें, ताकि दो developers अनजाने में अलग-अलग defaults की तुलना न करें। Profiles में ऐसे model IDs होने चाहिए जो वर्तमान में published हों और Responses के साथ compatible हों।
Generated GetVibe config fast और deep profiles के लिए एक pattern देता है, लेकिन recommendation बदलने पर यह भी बदल सकता है। पुराने model context limit को कॉपी करने के बजाय documented endpoint से इसे refresh करें। Codex configured context window के अनुसार history को compact कर सकता है, इसलिए route द्वारा स्वीकार की जाने वाली सीमा से बड़ी window लंबे tasks को उपयोगी context देने के बजाय request errors में बदल सकती है।
Repository context को focused रखें
Agent लॉन्च करने से पहले जाँचें कि ignore rules package caches, build outputs, generated API clients और बड़े fixtures को exclude करती हैं। Codex को बताएँ कि पहले किस package या test को inspect करना है। किसी bug के लिए उससे failure reproduce करने, उन files के नाम बताने जिन्हें वह बदलने की योजना बना रहा है, फिर सबसे छोटा patch बनाने और test चलाने के लिए कहें। इससे दोहराया जाने वाला tool output कम होता है और result की review आसान बनती है।
Fair cost comparison के लिए समान commit पर समान prompt चलाएँ। ऐसा task भी शामिल करें जिसमें किसी edit की आवश्यकता न हो, ताकि आप देख सकें कि agent boundary का सम्मान करता है या नहीं, और ऐसा task भी जिसमें test run आवश्यक हो, ताकि repair loops की गिनती की जा सके। केवल final response length नहीं, बल्कि token usage और यह भी record करें कि patch पास हुआ या नहीं।
Reasoning और output budgets
अपने quality target को पूरा करने वाला सबसे कम reasoning effort उपयोग करें। High effort कुछ planning tasks के लिए उपयोगी है, लेकिन इससे latency और output usage बढ़ सकता है। Requested patch और explanation के लिए पर्याप्त बड़ा output budget सेट करें, लेकिन इसे unlimited न छोड़ें। जब response जल्दी रुक जाए, तो पूरी request दोहराने से पहले finish reason inspect करें; targeted continuation में कम context लग सकता है।
Automatic command approvals को conservative रखें। Codex कोई destructive shell command प्रस्तावित कर सकता है या intended scope के बाहर files बदल सकता है। इसे accept करने से पहले diff और test output की review करें, भले ही reasoning summary confident सुनाई दे।
सामान्य errors
- Wrong endpoint: base URL का अंत
/v1से होना चाहिए औरwire_apiresponsesहोना चाहिए। - 401: process environment में
GETVIBE_API_KEYexport करें; TOML shell variables को expand नहीं करता। - Context error:
model_context_windowको चुने गए model के published page से match करें। - Tool behavior differs: Responses-compatible model का test करें और CLI version को current रखें।
JSON request fields के लिए Messages and Responses देखें; balances और metering के लिए usage docs देखें।