ये तीनों मॉडल GetVibe के GPT-6 catalog में अलग-अलग स्थान रखते हैं। सही चुनाव task की कठिनाई, आपके द्वारा मांगी गई reasoning की मात्रा और output की लंबाई पर निर्भर करता है। यह तुलना 3 अक्टूबर 2026 को जांचे गए public model pages पर आधारित है; प्रदर्शित prices live-rendered catalog values हैं, benchmark का दावा नहीं।
वर्तमान catalog snapshot
| Model ID | प्रति 1M tokens पर input / output | उपयोगी शुरुआती भूमिका |
|---|---|---|
| gpt-6-luna | $0.0055 इनपुट · $0.0274 आउटपुट प्रति 10 लाख टोकन | कम लागत वाला baseline और छोटे tasks |
| gpt-6-sol | $0.1096 इनपुट · $0.548 आउटपुट प्रति 10 लाख टोकन | सामान्य reasoning और code work |
| gpt-6.1-sol | $0.1096 इनपुट · $0.548 आउटपुट प्रति 10 लाख टोकन | multi-step agent work पर तुलना |
Catalog snapshot की तारीख 3 अक्टूबर 2026 है। Deploy करने से पहले प्रत्येक linked page जांच लें, क्योंकि active USD rate बदल सकता है।
Model suffix को benchmark न समझें
केवल model name से यह पता नहीं चलता कि वह आपके repository, tool schema या output constraint को कितनी अच्छी तरह संभालेगा। एक evaluation set का उपयोग करें जिसमें failing test वाला bug, छोटी multi-file feature और ऐसा explanation task शामिल हो जिसमें कोई edit नहीं होना चाहिए। Prompt, commit, permission settings और test command को स्थिर रखें। Correctness, test result, latency, input/output usage और repair turns दर्ज करें। हमने इस article के लिए कोई public benchmark नहीं चलाया है, इसलिए यह table price और setup comparison है, quality ranking नहीं।
Reasoning से behavior और cost दोनों बदलते हैं
प्रत्येक model अपनी model page पर documented reasoning settings का एक set उपलब्ध कराता है। उस task की correctness bar पार करने वाली सबसे कम setting से शुरू करें, फिर fail होने वाले cases के लिए उसे बढ़ाएं। Reasoning tokens output usage में शामिल होते हैं, इसलिए समान output size मानने के बजाय total task cost की तुलना करें। max_tokens को requested answer के लिए पर्याप्त ऊंचा रखें, लेकिन unlimited न रखें। यदि आपका prompt code के साथ explanation और tests भी मांगता है, तो इन outputs के लिए जानबूझकर budget तय करें।
OpenAI SDK के साथ पहले test के लिए model ID को configuration के रूप में इस्तेमाल करें, उसे कई call sites में hard-code न करें:
export GETVIBE_API_KEY="your-dashboard-key"
export GETVIBE_MODEL="gpt-6.1-sol"
python - <<'PY'
import os
from openai import OpenAI
client = OpenAI(base_url="https://getvibeapi.com/v1", api_key=os.environ["GETVIBE_API_KEY"])
response = client.chat.completions.create(
model=os.getenv("GETVIBE_MODEL", "gpt-6-luna"),
reasoning_effort="medium",
messages=[{"role":"user", "content":"इस failing test को समझाएं और सबसे छोटा fix सुझाएं।"}],
max_tokens=1200,
)
print(response.choices[0].message.content)
PYEnvironment variable ही model setting है; यह model name से derive नहीं होती। अपनी API key को secret manager में रखें।
आपको पहले किसे आजमाना चाहिए?
- Luna: छोटे, सीमित changes और आसान validation वाले tasks के लिए यहां से शुरू करें। इसका कम catalog rate इसे एक अच्छा baseline बनाता है, लेकिन verify करें कि इसका context और tools आपके client के अनुकूल हैं।
- Sol: उन कामों के लिए candidate के रूप में रखें जहां Luna baseline quality threshold से चूक जाता है। हर request को default रूप से upgrade करने के बजाय उसी test पर तुलना करें।
- 6.1 Sol: वहां test करें जहां multi-step planning या repeated tool use महत्वपूर्ण हो। मापें कि क्या यह per-token difference की भरपाई करने के लिए correction turns को पर्याप्त रूप से कम करता है।
Test harness के लिए coding-agent cost comparison और parameter behavior के लिए reasoning effort guide का उपयोग करें। इन्हें coding agent के साथ चलाने के लिए Codex CLI configuration देखें; Claude Code अलग Messages protocol का उपयोग करता है।
निष्पक्ष cost comparison करें
हर attempt से input और output usage दर्ज करें, जिसमें failed patches और retries भी शामिल हों। कुल spend को उन changes की संख्या से divide करें जो आपके test और review criteria को pass करते हैं। Variation को ध्यान में रखने के लिए किसी task को दोहराएं। Vendor benchmark या किसी एक आकर्षक response को अपने repository के proxy के रूप में इस्तेमाल न करें। Catalog price change, CLI upgrade या महत्वपूर्ण prompt change के बाद उसी set को फिर से चलाएं।
चुने गए model को एक environment या project setting में रखें ताकि code edits के बिना उसे बदला और rollback किया जा सके। Date, model IDs, test results और live model-page links के साथ एक छोटा internal note publish करें। Comparison article को permanent ranking मानने की तुलना में यह अधिक उपयोगी है।
जानें कि कौन-सी settings model के अनुसार बदलती हैं
Reasoning levels और context limits model-specific होते हैं। केवल इसलिए किसी setting को reuse न करें कि दो IDs के नाम में “Sol” समान है। Supported levels और maximum context के लिए वर्तमान GPT-6.1 Sol, GPT-6 Sol और GPT-6 Luna pages देखें। यदि किसी request पर parameter validation error मिलता है, तो optional fields को एक-एक करके हटाएं; invalid parameter के आसपास automatic retries न जोड़ें।
Output cap की वास्तविक task से भी तुलना करें। Coding agent को patch और संक्षिप्त explanation के लिए जगह की आवश्यकता हो सकती है, लेकिन unbounded output request अनावश्यक spend पैदा कर सकती है। यदि आपका client model और output configuration को आसानी से switch करने देता है, तो short questions के लिए अलग profile रखें।
अपने client के अपेक्षित protocol का उपयोग करें
तीनों models GetVibe text catalog में दिखाई देते हैं, लेकिन कोई agent client केवल एक API protocol बोल सकता है। Codex CLI को Responses API के लिए configure किया जाता है; इसके dedicated setup का उपयोग करें। Claude Code Anthropic Messages पर चलता है और उस endpoint के माध्यम से इन GPT-6 models को call नहीं कर सकता। OpenAI-compatible SDK, यदि model और parameters supported हों, तो Chat Completions का उपयोग कर सकता है। General catalog में किसी model की मौजूदगी से protocol support का संकेत नहीं मिलता।
तारीख के साथ result sheet रखें
Snapshot date, model ID, linked model page, input/output usage, reasoning effort, total time और test result दर्ज करें। Clean checkout से कई tasks दोहराएं। यदि catalog price बदलता है, तो इस page की live table update हो जाती है, लेकिन आपका historical benchmark नहीं; dated observation को सुरक्षित रखें ताकि बाद की comparison समझने योग्य बनी रहे।