कोडिंग एजेंट्स के लिए सबसे सस्ते मॉडल: लाइव कीमत तुलना

सबसे सस्ता coding-agent model वह है जो सबसे कम कुल bill में किसी change को review पास करवा दे, जरूरी नहीं कि वही हो जिसकी input rate सबसे कम हो। एक agent बार-बार repository context भेजता है, tool output प्राप्त करता है, reasoning करता है, patch लिखता है और उसे कई corrections की आवश्यकता पड़ सकती है। यह comparison 3 अक्टूबर 2026 के GetVibe के live model catalog snapshot का उपयोग करता है और उन models पर केंद्रित है जिन्हें coding workflows के साथ इस्तेमाल किया जा सकता है।

Catalog price snapshot

नीचे दिए गए आंकड़े प्रति one million tokens USD में हैं, पहले input और उसके बाद output। प्रदर्शित price cells GetVibe catalog से resolve होते हैं; date यह दर्ज करती है कि यह comparison कब check किया गया था।

Model	Input / output rate	पहला test किसके लिए
GPT-6 Luna	$0.0055 इनपुट · $0.0274 आउटपुट प्रति 10 लाख टोकन	छोटे fixes, summaries और तेज iteration
GPT-6.1 Sol	$0.1096 इनपुट · $0.548 आउटपुट प्रति 10 लाख टोकन	Multi-step edits और बेहतर reasoning
GPT-6 Sol	$0.1096 इनपुट · $0.548 आउटपुट प्रति 10 लाख टोकन	मौजूदा prompts पर 6.1 से तुलना
Claude Sonnet 5.5	$0.168 इनपुट · $0.84 आउटपुट प्रति 10 लाख टोकन	Messages-format coding और agent loops

ये catalog rates हैं, benchmark result नहीं। यदि 3 अक्टूबर 2026 के बाद rates बदलते हैं, तो model page वर्तमान source बना रहेगा। Claude Sonnet 5.5 Claude Code के लिए उपयोगी है क्योंकि यह Messages format स्वीकार करता है; GPT-6 models को Claude Code के माध्यम से नहीं, बल्कि Codex CLI जैसे Responses-compatible tool के माध्यम से test किया जाना चाहिए।

ऐसा coding test इस्तेमाल करें जो पूरा हुआ काम मापे

तीन repository tasks चुनें: failing test वाला localized bug fix, कई files को छूने वाला छोटा feature और स्पष्ट no-behavior-change requirement वाला refactor। प्रत्येक run के लिए वही Git commit, instructions, tool permissions और test command freeze करें। यह score करें कि task सही है या नहीं, tests पास होते हैं या नहीं, कितने repair turns की आवश्यकता पड़ी और पूरा change होने में कितना समय लगा।

केवल final answer की तुलना न करें। कोई model convincing patch दे सकता है जो tests में fail हो जाए और इसके कारण एक और लंबा turn चलाना पड़े। हर turn के लिए input और output usage record करें, जिसमें tool results और repair prompts भी शामिल हों। Passing change की cost calculate करें। प्रत्येक task के लिए कम से कम कुछ samples चलाएँ; एक lucky response स्थिर ranking नहीं होती।

सस्ती token rate की कुल cost फिर भी अधिक क्यों हो सकती है

Agents अक्सर एक बड़ा prefix दोबारा भेजते हैं: system instructions, repository notes, tool schemas और पिछली conversation। Output tokens short prompts के अनुमान से अधिक bill का हिस्सा हो सकते हैं। जिस model को दो correction turns की आवश्यकता होती है, वह उस model से अधिक महंगा हो सकता है जिसकी प्रति-token cost अधिक है लेकिन वह एक ही pass में working patch तैयार कर देता है। Cache reads repeated-input economics बदल सकते हैं, लेकिन savings गिनने से पहले confirm करें कि cached input usage में report किया गया है।

Context को focused रखें। Build output, dependencies, generated snapshots और unrelated packages को ignore करें। Agent से पहले केवल संभावित files inspect करने को कहें। इससे tokens कम होते हैं और अक्सर attention भी बेहतर होती है। Stable repeated prefixes के लिए prompt caching guidance का उपयोग करें।

आपको किस model से शुरुआत करनी चाहिए?

GPT-6 Luna: routine और अच्छी तरह scoped changes के लिए एक उपयुक्त low-cost baseline। Context और features के लिए model page check करें, फिर जिन tasks में यह fail हो उन्हें escalate करें।
GPT-6.1 Sol: उन tasks पर तुलना करें जहाँ planning और multi-file reasoning महत्वपूर्ण हैं। इस catalog snapshot में इसकी कीमत GPT-6 Sol से कम है।
GPT-6 Sol: यदि आपके मौजूदा prompts इसके behavior पर निर्भर करते हैं, तो इसे matrix में रखें; switch करने से लाभ होता है या नहीं, इसका निर्णय measured results से करें।
Claude Sonnet 5.5: इसे Claude Code और Messages-based workflows के लिए शामिल करें। इसका path और tool semantics Responses-based Codex से अलग है, इसलिए clients को समान मानने के बजाय outcomes की तुलना करें।

Comparison को reproducible बनाएँ

SDK-based clients के लिए environment में key के साथ OpenAI-compatible API का उपयोग करें:

export GETVIBE_API_KEY="your-dashboard-key"
python - <<'PY'
import os
from openai import OpenAI

client = OpenAI(base_url="https://getvibeapi.com/v1", api_key=os.environ["GETVIBE_API_KEY"])
result = client.chat.completions.create(
    model="gpt-6-luna",
    messages=[{"role": "user", "content": "src/parser.py का निरीक्षण करें और failing edge case ठीक करें। संबंधित test चलाएँ।"}],
    max_tokens=1200,
)
print(result.choices[0].message.content)
PY

Agent client जिस exact endpoint को support करता है, उसी का उपयोग करें। Codex CLI के लिए Responses API configuration का उपयोग करें; Claude Code के लिए Messages configuration का उपयोग करें। Permission prompts को बनाए रखें और agents को किसी branch में चलाएँ, ताकि आप concrete diff review कर सकें।

Decision rule

अपने repository tasks पर आपके pass-rate target और latency budget को पूरा करने वाले candidates में से सबसे कम खर्चीले candidate को चुनें। Fixed evaluation set बनाए रखें और catalog, agent version या prompt बदलने पर उसे फिर से चलाएँ। प्रत्येक observation के साथ date, model ID, usage और test result store करें। 3 अक्टूबर 2026 का catalog snapshot model pages के माध्यम से linked है; आज की prices के लिए stale values को spreadsheet में copy करने के बजाय उन्हीं pages का उपयोग करें।

Total task cost का अनुमान लगाएँ

Planning के लिए input और output usage को अलग रखें। यदि कोई task 40,000 input tokens और 2,000 output tokens का उपयोग करता है, तो selected model page की वर्तमान per-million rates से प्रत्येक leg calculate करें और फिर उन्हें जोड़ें। यह केवल baseline है: cached input, minimum request charges, multiple agent turns और retries वास्तविक bill बदल सकते हैं। Test run के बाद usage details का उपयोग करके estimates को observed totals से बदलें।

Context size को billed tokens न समझें। Model का maximum context बताता है कि वह क्या स्वीकार कर सकता है, यह नहीं कि प्रत्येक request की cost कितनी होगी। Coding agent को पूरी repository load करने से रोकें, जब केवल कुछ files relevant हों। Selective context अक्सर answer quality सुधारता है और भेजे जाने वाले tokens की संख्या घटाता है।

Cost को प्रभावित करने वाले quality signals track करें

प्रत्येक run के लिए record करें कि patch cleanly apply होता है या नहीं, relevant tests pass होते हैं या नहीं, कितने tool calls fail होते हैं, कितने correction turns होते हैं और reviewer change accept करता है या नहीं। Displayed token rate कम होने पर भी बहुत retries की आवश्यकता वाला model प्रति accepted change अधिक महंगा हो सकता है। Latency भी महत्वपूर्ण है: सबसे धीमा route overnight work के लिए उपयुक्त हो सकता है, लेकिन interactive editor के लिए अनुपयुक्त।

Model errors को harness errors से अलग रखें। Missing test command, stale checkout या permission denial को reasoning failure के रूप में score नहीं किया जाना चाहिए। Task ID, model ID, repository SHA और redacted error category के साथ trace रखें, ताकि team बाद में वही comparison दोहरा सके।

Evidence मिलने पर ही two-tier workflow इस्तेमाल करें

एक cost strategy यह है कि routine edits के लिए lower-cost model आज़माया जाए और deterministic signal मिलने पर task escalate किया जाए, जैसे failing tests या invalid structured output। अधिकांश tasks simple होने पर इससे पैसे बच सकते हैं। कठिन tasks पर यह दूसरा full context pass भी जोड़ सकता है। इस strategy को deploy करने से पहले escalation rate और combined usage measure करें।

Fallback model selection को application configuration में explicit रखें। यदि reproducibility महत्वपूर्ण है, तो report करें कि प्रत्येक task को किस model ने handle किया। Developer को यह बताते हुए कि change original model से आया है, चुपचाप किसी अलग public model को call न करें।