कम लागत वाला कोडिंग एजेंट कैसे बनाएं: Jev + Opus 5.5 (पूर्ण आर्किटेक्चर)

आपका कोडिंग एजेंट मल्टीपल चॉइस सवालों के लिए फ्रंटियर (frontier) मॉडल्स की भारी-भरकम कीमत चुका रहा है।

मुझे कौन से नोट्स लोड करने चाहिए? क्या यह स्टेप बड़े मॉडल को जाना चाहिए या छोटे वाले को? टूल अभी-अभी फेल हो गया। दोबारा कोशिश करूँ, ठीक करूँ, या छोड़ दूँ? कौन से टेस्ट पहले रन होने चाहिए?

इनमें से हर एक सवाल ऐसा है जिसके चार या पाँच संभावित जवाब होते हैं। और आज के ज़्यादातर एजेंट सेटअप्स में, इनमें से हर एक का जवाब आपके सबसे महंगे मॉडल द्वारा दिया जाता है — thinking मोड ऑन करके, पूरा context पढ़कर, और कोई फैसला लेने से पहले एक पूरा पैराग्राफ लिखकर।

यही वो छेद है जहाँ से आपका पैसा बह रहा है।

यह आर्टिकल आपको बताएगा कि इस छेद को कैसे बंद करें। Opus 5.5 मुश्किल reasoning का काम करेगा: प्लानिंग, कोड लिखना, डीबगिंग। Jev उन चार फैसलों को संभालेगा जो लगभग हर स्टेप पर आते हैं। आपका harness विकल्प तैयार करेगा, जवाब चेक करेगा, और आखिरी फैसला लेगा।

नीचे दिए गए वर्क्ड एग्जांपल में, एक फीचर सेशन की लागत $6.42 से घटकर $2.00 रह जाती है। यानी 69% सस्ता, और इस गणित की हर लाइन इस आर्टिकल में दी गई है ताकि आप इसे अपने आंकड़ों से मिलाकर देख सकें।

यह उन सभी लोगों के लिए लिखा गया है जो असली प्रोजेक्ट्स पर कोडिंग एजेंट चला रहे हैं: Claude Code, API पर आपका अपना harness, या इन दोनों के बीच कुछ भी। आपको अपना एजेंट दोबारा लिखने की ज़रूरत नहीं है। इस आर्टिकल का हर हिस्सा किसी मौजूदा लूप में एक फंक्शन कॉल की तरह फिट हो जाता है, जिसे बंद करने के लिए एक फ्लैग भी दिया गया है। अगर आपने मेरा Jev + Claude Code वाला आर्टिकल पढ़ा है, तो यह उसका अपग्रेडेड वर्ज़न है: वही आईडिया, एक नया reasoning मॉडल, और किसी सामान्य सिद्धांत की जगह चार खास फैसले।

आपको एक Jev API key, एक Anthropic API key, और तुलना करने के लिए अपने एजेंट के लगभग एक हफ्ते के लॉग्स चाहिए होंगे।

चलिए इसे बनाते हैं।

opus सोचता है, jev फैसला करता है।

समस्या: एक मॉडल, दो काम

किसी कोडिंग एजेंट को दस मिनट तक काम करते हुए देखिए, और आप पाएंगे कि वह दो बिल्कुल अलग तरह के काम कर रहा है।

पहला काम है reasoning। किसी फीचर की प्लानिंग करना। कोई फंक्शन लिखना। स्टैक ट्रेस पढ़कर यह समझना कि डेट पार्सर लीप ईयर पर क्यों क्रैश हो रहा है। यह काम ओपन-एंडेड होता है। इसका जवाब किसी लिस्ट में नहीं मिलता। यहाँ आप चाहेंगे कि आपके पास जो सबसे स्मार्ट मॉडल हो वो लगाएँ, और Opus 5.5 इसमें बहुत माहिर है।

दूसरा काम है फैसला लेना। चालीस में से उन तीन प्रोजेक्ट नोट्स को चुनना जो ज़रूरी हैं। यह तय करना कि नाम बदलने का काम किसी सस्ते मॉडल को दे सकते हैं। npm test टाइमआउट होने के बाद क्या करना है, यह चुनना। पूरे 1,400 टेस्ट चलाने से पहले किन 12 टेस्ट फाइल्स को रन करना है, यह तय करना। इनके जवाब एक लिस्ट में होते हैं। लिस्ट छोटी होती है। और आपका कोड उस जवाब पर सीधे काम कर सकता है।

ज़्यादातर एजेंट्स दोनों काम एक ही मॉडल से करवाते हैं, क्योंकि डिफॉल्ट यही है। लूप Opus को कॉल करता है, Opus सोचता है, Opus जवाब देता है, लूप आगे बढ़ता है।

यह काम करता है। लेकिन यह धीमा और महंगा भी है, और यह बात आसानी से नज़रअंदाज़ हो जाती है क्योंकि एक-एक करके देखें तो ये फैसले वाली कॉल्स महंगी नहीं लगतीं। "मुझे कौन से नोट्स चाहिए" वाली एक कॉल शायद एक सेंट की होती है। लेकिन यह हर स्टेप पर होती है, और हर बार पूरा context अपने साथ लेकर चलती है।

और एक दूसरी लागत भी है जो इससे भी ज़्यादा आसानी से छूट जाती है: जब एजेंट तय नहीं कर पाता कि क्या लोड करना है, तो वह सब कुछ लोड कर लेता है। हर प्रोजेक्ट नोट, हर convention डॉक, हर पुराना फैसला — सब कुछ हर कॉल में ठूंस दिया जाता है। Opus 5.5 ने कैश रीड्स को $0.20 प्रति मिलियन tokens करके सस्ता तो बना दिया है, लेकिन "सस्ता × साठ स्टेप्स × आपका पूरा नोट्स फोल्डर" फिर भी जुड़कर बड़ी रकम बन जाता है।

समाधान: Opus सोचेगा, Jev फैसला करेगा, आपका harness राज करेगा

Jev, TypeSafe का बनाया हुआ मॉडल है जो खास तौर पर इसी दूसरे काम के लिए डिज़ाइन किया गया है। यह टेक्स्ट नहीं लिखता। आप इसे context और टाइप किए गए सवाल देते हैं जिनके विकल्प फिक्स होते हैं, और यह हर विकल्प के लिए एक probability लौटाता है। यह मिलीसेकंड्स में जवाब देता है, इनपुट की लागत $0.042 प्रति मिलियन tokens है, और आउटपुट बिल्कुल फ्री है।

इससे आर्किटेक्चर को समझाना आसान हो जाता है:

Opus 5.5 reasoning करेगा। प्लानिंग, कोड, डीबगिंग — कुछ भी जहाँ जवाब किसी लिस्ट में न हो।

Jev छोटे फैसले लेगा। यह उन विकल्पों में से चुनेगा जो आपके harness ने तैयार किए हैं।

कमान आपके harness के हाथ में रहेगी। यह विकल्पों की लिस्ट बनाएगा, probabilities पढ़ेगा, thresholds लागू करेगा, और जब Jev कन्फ्यूज़ हो तो Opus पर वापस लौटेगा।

लोग तीसरी लाइन को अक्सर छोड़ देते हैं, जबकि यही वो चीज़ है जो पूरे सिस्टम को सुरक्षित बनाती है। Jev कभी कोई नया विकल्प खुद से नहीं गढ़ता। Jev को कभी उन मामलों में आखिरी फैसला लेने का अधिकार नहीं मिलता जिन्हें आप undo नहीं कर सकते। "पर्याप्त भरोसेमंद" का मतलब क्या है, यह आपका कोड तय करता है।

यहाँ वो helper कोड है जिस पर इस आर्टिकल का बाकी सब कुछ टिका है:

from dataclasses import dataclass

@dataclass

class Decision:

answer: str

prob: float

probs: dict

confident: bool

def jev_choice(context: str, question: str, options: list[str]):

इसे अपने Jev client से जोड़ें: TypeSafe SDK, Vercel AI Gateway,

या LangChain पैकेज। इसे आपके द्वारा दिए गए हर विकल्प के लिए

{option: probability} लौटाना चाहिए।

raise NotImplementedError

def decide(context: str, question: str, options: list[str], threshold: float):

probs = jev_choice(context, question, options)

answer = max(probs, key=probs.get)

return Decision(answer, probs[answer], probs, probs[answer] >= threshold)

ध्यान दें कि इसमें क्या नहीं है: Jev से यह पूछने वाला कोई सवाल नहीं है कि उसे कितना भरोसा है। आप उसके द्वारा लौटाई गई probability पढ़ते हैं। किसी भी मॉडल से "क्या तुम्हें यकीन है?" पूछने पर लगभग हर बार "हाँ" ही मिलेगा। Probability ही असली और ईमानदार संकेत है।

अब आते हैं उन चार फैसलों पर।

एजेंट स्टेप के अंदर चार फैसले

फैसला 1: Context लोड करने से पहले ज़रूरी प्रोजेक्ट नोट्स चुनें

यह सबसे बड़ा और कारगर तरीका है, और इसे लगभग किसी ने बनाया ही नहीं है।

आपके एजेंट के पास एक नोट्स फोल्डर होता है। एक AGENTS.md, आर्किटेक्चर डॉक्स, conventions, पुराने फैसले, "बिना migration के बिलिंग मॉड्यूल को कभी हाथ मत लगाना" जैसी चेतावनियाँ। शायद 30,000 tokens का डेटा। ज़्यादातर एजेंट्स हर कॉल पर यह सब लोड कर लेते हैं, क्योंकि कोई भी वह इंसान नहीं बनना चाहता जिसने कोई ज़रूरी नोट छोड़ दिया हो।

तो सब कुछ लोड करने के बजाय, आप हर नोट के बारे में Jev से एक साधारण सवाल पूछते हैं, वो भी एक साथ (parallel में): क्या इस टास्क के लिए एजेंट को इस नोट की ज़रूरत है?

सबसे पहले, अपने नोट्स को headings के आधार पर chunks में बाँट लें। AGENTS.md का हर सेक्शन अपना एक chunk बन जाता है। हर आर्किटेक्चर डॉक एक या कई chunks बन जाता है।

import re

def chunk_notes(markdown: str, source: str):

parts = re.split(r"
(?=## )", markdown)

return [{"source": source, "text": p.strip()} for p in parts if p.strip()]

फिर हर chunk को मौजूदा टास्क के हिसाब से स्कोर दें:

from concurrent.futures import ThreadPoolExecutor

def pick_notes(task: str, notes: list[dict], keep: int = 6, floor: float = 0.55):

def score(note):

probs = jev_choice(

context=f"TASK:
{task}

NOTE ({note['source']}):
{note['text']}",

question="Would an engineer need this note to do the task correctly?",

options=["needed", "not_needed"],

)

return probs["needed"], note

with ThreadPoolExecutor(max_workers=16) as pool:

scored = sorted(pool.map(score, notes), key=lambda s: s[0], reverse=True)

picked = [n for p, n in scored[:keep] if p >= floor]

return picked or [n for _, n in scored[:2]]

यहाँ तीन बातों पर ध्यान देना ज़रूरी है।

नॉन-निगोशिएबल चीज़ें हमेशा लोड करें। कुछ नोट्स चाहे जो हो जाए, हर कॉल में होने चाहिए: सिक्योरिटी नियम, "कभी force push मत करो," या वो एक लाइन जो बताती है कि कौन सा डेटाबेस production वाला है। उन्हें हमेशा के लिए टैग कर दें और स्कोरिंग से बाहर रखें।

एक floor और एक fallback रखें। अगर कुछ भी 0.55 को पार नहीं करता, तो भी आप टॉप के दो लोड करते हैं। बिना किसी context वाला एजेंट, थोड़ा ज़्यादा context वाले एजेंट से बदतर होता है।

लॉग करें कि क्या हटाया गया। जब एजेंट कोई गलती करता है, तो सबसे पहले आप यही चेक करते हैं कि क्या वो नोट जिससे यह गलती रुक सकती थी, स्कोरिंग में हट गया था। यही लॉग आपको keep और floor को ट्यून करने में मदद करता है।

वर्क्ड एग्जांपल में, इस एक बदलाव से हर कॉल का नोट्स वाला हिस्सा 30,000 tokens से घटकर 6,000 tokens रह जाता है। अकेले इससे सेशन की लागत लगभग 24% कम हो जाती है।

फैसला 2: उपयुक्त कामों को तेज़ वर्कर की तरफ भेजें

हर स्टेप के लिए Opus की ज़रूरत नहीं होती।

आठ फाइल्स में किसी फंक्शन का नाम बदलने के लिए नहीं। किसी फॉर्म में एक फील्ड जोड़ने के लिए नहीं, जहाँ पहले से वैसी ही नौ फील्ड्स मौजूद हों। इम्पोर्ट पाथ अपडेट करने के लिए नहीं। ये ऐसे बदलाव हैं जो उस पैटर्न का अनुसरण करते हैं जो पहले से कोडबेस में मौजूद है।

इसलिए हर स्टेप रन होने से पहले, Jev उस स्टेप को वर्गीकृत करता है, और आपका harness उस वर्ग को किसी वर्कर से मैप करता है:

ROUTES = {

"rename_or_move": "fast",

"small_edit_following_existing_pattern": "fast",

"new_logic": "opus",

"debugging": "opus",

"design_decision": "opus",

}

def route(step: str, recent_diff: str):

d = decide(

context=f"STEP:
{step}

RECENT CHANGES:
{recent_diff}",

question="What kind of work is this step?",

options=list(ROUTES),

threshold=0.8,

)

if not d.confident:

return "opus"

return ROUTES[d.answer]

गौर करें कि विकल्प कैसे लिखे गए हैं। वे "आसान" और "मुश्किल" नहीं हैं, और बिल्कुल भी "क्या कोई छोटा मॉडल इसे संभाल सकता है?" नहीं हैं। वे काम के ठोस प्रकार हैं जिन्हें आपका कोड किसी एक्शन से जोड़ सकता है। Jev के हर सवाल का यही नियम है: हर विकल्प ऐसा होना चाहिए जिस पर आपका harness काम करना जानता हो।

और डिफॉल्ट पर ध्यान दें। 0.8 से नीचे जाने पर स्टेप Opus के पास जाता है। यहाँ राउटिंग की गलतियाँ सिर्फ एक दिशा में जाती हैं: कोई मुश्किल काम तेज़ वर्कर को भेजने पर आपको एक फेल स्टेप और रिट्राई की कीमत चुकानी पड़ती है, जबकि कोई आसान काम Opus को भेजने पर बस थोड़ा ज़्यादा खर्च होता है। इसलिए जब भी डाउट हो, उसे ऊपर भेज दें।

तेज़ वर्कर के लिए मैं Haiku 4.5 इस्तेमाल करता हूँ, जिसकी कीमत $1 प्रति मिलियन इनपुट tokens और $5 प्रति मिलियन आउटपुट tokens है। वर्क्ड एग्जांपल में, असली काम वाले 36 स्टेप्स में से 12 इसके पास जाते हैं।

फैसला 3: जब कोई टूल फेल हो तो रिकवरी पाथ चुनें

टूल लगातार फेल होते हैं। टेस्ट टाइमआउट होते हैं। फाइल पाथ गलत होता है। कोई पैकेज इंस्टॉल नहीं होता। शेल कमांड को permission error आता है। लिंटर किसी बेसिर-पैर की चीज़ पर शिकायत करता है।

ज़्यादातर एजेंट्स इसे सबसे महंगे तरीके से संभालते हैं: वे पूरी एरर को बड़े मॉडल को लौटा देते हैं और उसे सोचने देते हैं कि क्या करना है। कभी-कभी यह सही होता है। लेकिन अक्सर जवाब साफ होता है, और Opus 1,500 tokens खर्च करके दोबारा खोज निकालता है कि ENOENT का मतलब है कि फाइल वहाँ नहीं है।

इससे भी बुरी बात, एजेंट्स लूप्स में फँस जाते हैं। रिट्राई, फेल, रिट्राई, फेल — और हर बार पूरे reasoning स्टेप की कीमत चुकानी पड़ती है।

इसलिए आप यह फेल्योर Jev को देते हैं, रिकवरी के कुछ फिक्स विकल्पों के साथ:

from collections import deque

def tail(text: str, n: int = 4000):

return "".join(deque(text, maxlen=n)) # एरर के आखिरी n कैरेक्टर्स

def recover(tool: str, command: str, error: str, attempt: int):

if attempt >= 3:

return "stop_and_report"

d = decide(

context=f"TOOL: {tool}
COMMAND: {command}
ATTEMPT: {attempt}
ERROR:
{tail(error)}",

question="What is the best next move after this failure?",

options=RECOVERY,

threshold=0.8,

)

return d.answer if d.confident else "escalate_to_opus"

1RECOVERY = [
2    "retry_unchanged",       # अस्थिर नेटवर्क या टाइमआउट
3    "retry_after_install",   # पैकेज या टूल गायब है
4    "fix_path_and_retry",    # गलत फाइल पाथ या cwd
5    "switch_tool",           # यह टूल नहीं कर सकता, दूसरा कर सकता है
6    "escalate_to_opus",      # असली डीबगिंग की ज़रूरत है
7    "stop_and_report",       # इंसान की ज़रूरत है
8]

प्रयासों की सख्त सीमा कोड में होती है, मॉडल में नहीं। कोई भी मॉडल, चाहे कितना भी सस्ता हो, उसे हमेशा के लिए रिट्राई करने की छूट नहीं मिलनी चाहिए।

हर रिकवरी पाथ आपके harness में एक छोटे फंक्शन से जुड़ा होता है। retry_after_install regex की मदद से एरर में से गायब पैकेज का नाम पढ़ता है और उसे इंस्टॉल करता है। fix_path_and_retry मौजूद पाथ्स को चेक करता है और सबसे करीबी मैच सुझाता है। सिर्फ escalate_to_opus में असली पैसा खर्च होता है, और यह तभी ट्रिगर होता है जब फेल्योर को सच में सोच-विचार की ज़रूरत हो।

वर्क्ड एग्जांपल में, यह सेशन से 6 बेकार रिट्राई स्टेप्स को हटा देता है।

फैसला 4: पूरे टेस्ट सूट से पहले फोकस्ड चेक्स रन करें

यह पैसों से ज़्यादा समय बचाता है, और समय ही वो चीज़ है जिससे एजेंट तेज़ महसूस होता है।

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

इसका समाधान नोट्स वाले पैटर्न जैसा ही है: हर टेस्ट फाइल को diff के खिलाफ स्कोर दें, सबसे प्रासंगिक वाले पहले रन करें, और पूरा सूट तभी रन करें जब फोकस्ड चेक्स पास हो जाएँ।

1def pick_tests(diff: str, test_files: list[str], keep: int = 12):
2    def score(path):
3        probs = jev_choice(
4            context=f"DIFF:\n{diff[:12000]}\n\nTEST FILE: {path}",
5            question="Could this change break tests in this file?",
6            options=["likely", "unlikely"],
7        )
8        return probs["likely"], path
9
10    with ThreadPoolExecutor(max_workers=16) as pool:
11        scored = sorted(pool.map(score, test_files), key=lambda s: s[0], reverse=True)
12    return [p for _, p in scored[:keep]]
13
14def check(diff: str, test_files: list[str]):
15    focused = pick_tests(diff, test_files)
16    if not run_tests(focused):
17        return False            # जल्दी फेल करें, बाकी सब से पहले इसे ठीक करें
18    return run_tests(test_files)  # पूरा सूट अभी भी commit से पहले गेटकीपर है

आखिरी लाइन को दो बार पढ़ें। कुछ भी commit होने से पहले पूरा सूट अभी भी रन होता है। फोकस्ड चेक्स एक अर्ली वार्निंग हैं, विकल्प नहीं। आप ज़्यादातर गलतियों को मिनटों की जगह सेकंड्स में पकड़ लेते हैं, और कभी ऐसी चीज़ शिप नहीं करते जिसे पूरा सूट पकड़ लेता।

सस्ते चेक्स भी पहले जोड़ लें: सिर्फ बदली हुई फाइल्स पर type check और lint। इनमें एक सेकंड लगता है और कोई भी टेस्ट रन होने से पहले ये हैरान कर देने वाली मात्रा में गलतियाँ पकड़ लेते हैं।

सबको एक साथ जोड़ना: Harness लूप

लूप के एक स्टेप के अंदर ये चार फैसले इस तरह बैठते हैं:

def run_step(task: str, step: str, state):

1. context: सिर्फ वही नोट्स लोड करें जिनकी इस स्टेप को ज़रूरत है

notes = state.always_notes + pick_notes(step, state.notes)

2. routing: इस स्टेप के लिए वर्कर चुनें

worker = state.workers[route(step, state.recent_diff())]

result = worker.run(step, notes=notes, history=state.history)

3. recovery: इस स्टेप में किसी भी टूल की फेल्योर को संभालें

for failure in result.failures:

action = recover(failure.tool, failure.command, failure.error, failure.attempt)

state.apply_recovery(action, failure)

4. checks: पहले फोकस्ड टेस्ट, commit से पहले पूरा सूट

if result.diff:

state.log_check(check(result.diff, state.test_files))

और यहाँ Opus का हिस्सा है: यह बस आपकी सामान्य Opus 5.5 कॉल है। अपना स्थिर context पहले रखें (system prompt, tool definitions, "always" वाले नोट्स) ताकि वह स्टेप्स के बीच कैश में रहे, और स्टेप से जुड़ी सामग्री को आखिर में रखें।

import os

import anthropic

client = anthropic.Anthropic()

OPUS = os.environ["OPUS_MODEL"] # आपका Opus 5.5 मॉडल id

def opus_step(system: str, notes: list[dict], history: list, step: str):

notes_text = "

".join(n["text"] for n in notes)

return client.messages.create(

model=OPUS,

max_tokens=8000,

system=[{"type": "text", "text": system, "cache_control": {"type": "ephemeral"}}],

messages=history + [{"role": "user", "content": f"NOTES:
{notes_text}

STEP:
{step}"}],

)

कुछ भी अनोखा नहीं है। बचत इसलिए होती है क्योंकि आप अब इसे वो सब भेजना बंद कर देते हैं, न कि किसी चतुर prompt की वजह से।

एक स्टेप, पूरा ट्रेस किया गया

जब ये चारों फैसले लाइव हो जाते हैं, तो लॉग में एक स्टेप कुछ ऐसा दिखता है। टास्क: public signup endpoint में rate limiting जोड़ना। यह ट्रेस उदाहरण के लिए है, लेकिन आपके अपने लॉग्स में भी आपको ऐसा ही पैटर्न दिखेगा।

step 14 "POST /signup में per IP rate limit जोड़ें"

[notes] parallel में 41 chunks को स्कोर किया गया

रखे गए: api/middleware.md (0.94), conventions/errors.md (0.88),

infra/redis.md (0.81), decisions/2025_auth.md (0.62)

हटाए गए: 37 chunks, जिनमें billing, email templates, CI शामिल थे

[route] new_logic (0.91) → opus

[opus] बदलाव की प्लानिंग करता है, middleware + config + handler edit लिखता है

[tool] npm test FAILED "Cannot find module 'bottleneck'"

[recover] retry_after_install (0.97) → npm install, फिर से रन

[checks] बदली हुई फाइल्स का typecheck: pass

फोकस्ड टेस्ट (1,388 में से 12): pass

पूरा सूट: pass

इसे ऊपर से नीचे पढ़ें और गिनें कि इनमें से कितनी लाइनें पहले पूरी Opus कॉल होती थीं। नोट्स चुनना: एक बड़ी कॉल, या फिर कोई चुनाव नहीं और 30,000 tokens के नोट्स आँख बंद करके लोड करना। राउटिंग: कुछ नहीं, हर स्टेप Opus के पास जाता था। गायब पैकेज: यह समझने के लिए पूरा reasoning स्टेप कि गायब मॉड्यूल का मतलब है "मॉड्यूल इंस्टॉल करो।" टेस्ट चुनना: कुछ नहीं, हर एडिट पर पूरा सूट।

अब उस ट्रेस में सिर्फ एक लाइन Opus की है, और वही वो लाइन है जिसे सच में एक frontier model की ज़रूरत थी: rate limiter की प्लानिंग करना और उसे लिखना।

एक तस्वीर में पूरा आईडिया यही है। महंगा मॉडल अपना समय काम के उस हिस्से में लगाता है जो सिर्फ वही कर सकता है।

वर्क्ड एग्जांपल: 69% की बचत कहाँ से आई

यहाँ एक फीचर सेशन का पूरा गणित है: 60 एजेंट स्टेप्स और साथ में 6 बेकार रिट्राई जो एक आम एजेंट रास्ते में जोड़ लेता है। सभी कीमतें मौजूदा पब्लिक लिस्ट प्राइस हैं।

पहले: Opus 5.5 सब कुछ करता है

हर स्टेप 70,000 tokens का context लोड करता है: 15,000 system prompt और tools के लिए, 30,000 पूरे नोट्स फोल्डर के लिए, और 25,000 अब तक की बातचीत के लिए। मैं मान रहा हूँ कि इसका 80% cache hit है। हर स्टेप लगभग 1,500 output tokens बनाता है, क्योंकि Opus 5.5 में thinking हमेशा ऑन रहता है।

cache reads: 56,000 × $0.20/M = $0.0112

fresh input: 14,000 × $4.00/M = $0.0560

output: 1,500 × $20.00/M = $0.0300

per step = $0.0972

66 steps × $0.0972 = $6.42

बाद में: decision layer

Context घटकर हर स्टेप में 46,000 tokens रह जाता है, क्योंकि Jev पूरे 30,000 लोड करने के बजाय 6,000 tokens के नोट्स चुनता है। 24 शुद्ध decision स्टेप्स Jev के पास चले जाते हैं। 6 रिट्राई लूप्स गायब हो जाते हैं। और बचे हुए 36 वर्क स्टेप्स में से 12 Haiku 4.5 के पास जाते हैं।

Opus 5.5: 24 steps × $0.0742 = $1.78

Haiku 4.5: 12 steps × $0.0169 = $0.20

Jev: 102 calls × 5,000 tokens

× $0.042/M, output free = $0.02

total = $2.00

$6.42 से $2.00। यानी उसी फीचर के लिए 68.8% सस्ता।

threshold इस आधार पर तय करें कि गलत जवाब की कीमत क्या है

और यहाँ बताया गया है कि हर तरीका कितना योगदान देता है, क्रम से:

notes selection only $4.89 23.7% saved

• decisions moved to Jev $3.13 51.2% saved
• recovery paths $2.69 58.1% saved
• routing to a fast worker $2.00 68.8% saved

इस गणित के बारे में दो ईमानदार बातें।

पहली, ये स्पष्ट मान्यताओं पर आधारित मॉडल किए गए आंकड़े हैं, आपके stack की कोई माप नहीं। आपका context size, cache hit rate और decision count अलग होगा। हर लाइन दिखाने का मकसद यही है कि आप अपने आंकड़े इसमें डाल सकें। जब आप अपने असली 'पहले' और 'बाद' को माप लें, तो मेरे नहीं, अपने आंकड़ों का इस्तेमाल करें।

दूसरी, देखें कि पैसा असल में कहाँ जा रहा है। Jev की 102 कॉल्स का कुल खर्च दो सेंट है। बचत इसलिए नहीं हो रही क्योंकि Jev प्रति कॉल सस्ता है। बचत इसलिए हो रही है क्योंकि Jev के फैसला लेने के बाद वो सब होना बंद हो जाता है: फूला हुआ context, मल्टीपल चॉइस सवालों के लिए पूरे reasoning स्टेप्स, रिट्राई लूप्स, और नाम बदलने जैसे कामों के लिए बड़े मॉडल की कॉल्स।

फैसलों के लिए सिर्फ Haiku क्यों न इस्तेमाल करें?

वाजिब सवाल है। Haiku 4.5 सस्ता और तेज़ है। तो फिर नया मॉडल क्यों जोड़ें?

तीन कारण।

यह अभी भी लिखता है। Haiku टेक्स्ट में जवाब देता है। आपको उसे prompt देना पड़ता है कि वह आपके विकल्पों में से किसी एक में जवाब दे, फिर उस जवाब को parse करना पड़ता है, और फिर उन बार को संभालना पड़ता है जब वह कोई व्याख्या जोड़ देता है, लिस्ट से बाहर की कोई चीज़ चुन लेता है, या जवाब को किसी वाक्य में लपेट देता है। Jev आपके द्वारा दिए गए हर विकल्प के लिए probability लौटाता है। न कुछ parse करना है, न लिस्ट से बाहर कुछ।

आपको सिर्फ एक जवाब नहीं, पूरा distribution मिलता है। जब Jev कहता है needed: 0.52, not_needed: 0.48, तो आप जानते हैं कि यह सिक्का उछालने जैसा है और आपका harness इसे escalate कर सकता है। जब कोई text model "needed" कहता है, तो आपको कोई अंदाज़ा नहीं होता कि उसे कितना यकीन था। Thresholds तभी काम करते हैं जब आप probabilities देख सकें।

लागत का गणित अलग है। Jev का आउटपुट फ्री है और इनपुट $0.042 प्रति मिलियन tokens है। हर स्टेप पर 41 नोट chunks को स्कोर करने का मतलब है प्रति स्टेप 41 छोटी कॉल्स। Jev के साथ यह एक सेंट का छोटा सा हिस्सा है। किसी भी text model के साथ, चाहे वह सस्ता ही क्यों न हो, यह 41 generations हैं जिनकी अपनी आउटपुट लागत और latency है।

छोटे एडिट्स के लिए Haiku का इस्तेमाल करें, जहाँ उसे सच में कोड लिखना हो। लिस्ट में से चुनने के लिए Jev का इस्तेमाल करें। सोचने के लिए Opus का। हर मॉडल वही काम करे जिसके लिए उसे बनाया गया है।

बिना कुछ तोड़े इसे कैसे लागू करें

चारों फैसले एक साथ ऑन मत करें। मैं यह क्रम अपनाऊँगा।

पहला हफ्ता: shadow mode। अपने मौजूदा एजेंट को जैसा है वैसा ही रहने दें। वह जो भी फैसला ले, उसी सवाल को Jev से भी पूछें और दोनों जवाबों के साथ Jev की probability लॉग करें। Jev के जवाब पर कोई एक्शन बिल्कुल न लें।

1def shadow(decision_name, context, question, options, current_answer):
2    probs = jev_choice(context, question, options)
3    jev_answer = max(probs, key=probs.get)
4    log_row(
5        decision=decision_name,
6        current=current_answer,
7        jev=jev_answer,
8        prob=probs[jev_answer],
9        agree=(jev_answer == current_answer),
10    )

दूसरा हफ्ता: असहमतियों को पढ़ें। सिर्फ उन पंक्तियों को देखें जहाँ Jev और आपके मौजूदा एजेंट की राय अलग थी। उन्हें Jev की probability के हिसाब से छाँटें। आपको आमतौर पर एक साफ रेखा मिलेगी: किसी खास probability के ऊपर, Jev उतनी ही बार सही होता है जितनी बार Opus। वही रेखा आपका threshold है। असहमति वाली ये पंक्तियाँ आपका टेस्ट सेट भी बन जाती हैं, जो आपके असली ट्रैफिक से मुफ्त में तैयार हो गया।

तीसरा हफ्ता: notes selection ऑन करें। यह सबसे बड़ा तरीका है और इसे undo करना सबसे आसान है, क्योंकि कोई छूटा हुआ नोट आपके लॉग्स में जल्दी दिख जाता है।

चौथा हफ्ता: recovery और tests ऑन करें। दोनों में कोड में सख्त सीमाएँ और fallbacks हैं, इसलिए सबसे बुरी स्थिति यह होगी कि आप वहीं लौट आएँ जो आप आज कर रहे हैं।

आखिर में: routing। राउटिंग की गलतियाँ यूज़र्स को सबसे जल्दी दिखती हैं, क्योंकि तेज़ वर्कर को भेजा गया कोई मुश्किल काम खराब कोड पैदा करता है। इसे आखिर में ऑन करें, एक रूढ़िवादी threshold के साथ, और तेज़ वर्कर स्टेप्स पर fail rate पर नज़र रखें।

हर फैसले को एक on/off flag के पीछे रखें ताकि आप उसे एक लाइन में undo कर सकें।

जोखिम के हिसाब से Thresholds तय करना

हर चीज़ के लिए एक ही threshold रखना गलती है। इन्हें इस आधार पर तय करें कि गलत जवाब आने पर क्या होगा।

एक फीचर सेशन, वही नतीजा $6.42 से $2.00

कम जोखिम, undo करना आसान: 0.55 से 0.65। नोट्स चुनना। टेस्ट का क्रम तय करना। गलत जवाब की कीमत बस थोड़ा सा context या कुछ सेकंड है।

मध्यम जोखिम: 0.8। राउटिंग और रिकवरी। गलत जवाब की कीमत एक फेल स्टेप है, जिसे आपका harness पकड़ लेता है।

उच्च जोखिम, undo करना मुश्किल: 0.9 या कभी नहीं। फाइलें डिलीट करना। Force push करना। Production config को छेड़ना। Migration रन करना। मेरी ईमानदार सलाह: किसी भी मॉडल को ये फैसले अकेले न लेने दें। इन्हें किसी इंसान के पास भेजें, या कम से कम एक confirmation step के साथ Opus के पास।

Threshold से नीचे की कोई भी चीज़ ऊपर भेजी जाती है: अगर reasoning की ज़रूरत है तो Opus के पास, अगर समझदारी (judgment) की ज़रूरत है तो इंसान के पास।

यह कहाँ काम नहीं आता

यह आर्किटेक्चर हर workload पर कोई जादुई गुणक नहीं है।

शुद्ध generation workloads में शायद ही कोई फर्क पड़े। अगर आपका एजेंट अपना ज़्यादातर समय किसी साफ spec से बड़ी मात्रा में नया कोड लिखने में लगाता है, तो हटाने के लिए ज़्यादा फैसले नहीं होते। आपको नोट्स चुनने से बचत मिलेगी, लेकिन और कुछ खास नहीं।

छोटे प्रोजेक्ट्स को इसकी ज़रूरत नहीं है। अगर आपका पूरा नोट्स फोल्डर 2,000 tokens का है और आपका सूट आठ सेकंड में रन हो जाता है, तो इसे बनाने का ओवरहेड अभी इसके लायक नहीं है।

Jev अकेले आखिरी फैसला लेने में बहुत अच्छा नहीं है। यह चीज़ों को नोटिस करने और छोटी लिस्ट में से चुनने में बेहतरीन है। यह वो मॉडल नहीं है जिसे आप "क्या यह pull request merge होने के लिए तैयार है?" जैसे एकल सवाल का फैसला लेने के लिए चाहेंगे। बड़े सवालों को छोटे-छोटे सवालों में तोड़ें, हर एक को स्कोर दें, और नतीजों को अपने कोड में अपने weights के साथ जोड़ें।

अगर आपके पास किसी फिक्स सवाल के लिए पहले से labelled data है, तो आपका खुद होस्ट किया गया कोई छोटा मॉडल कीमत के मामले में Jev को हरा सकता है। Jev तब चमकता है जब सवाल बदलते रहते हैं और आपके पास training data नहीं होता, जो ज़्यादातर कोडिंग एजेंट्स की स्थिति है।

वे गलतियाँ जिनसे मैं बचूँगा

मॉडल को विकल्पों की लिस्ट लिखने देना। पूरा आर्किटेक्चर उन विकल्पों पर निर्भर करता है जिन पर आपका कोड काम कर सके। अगर कोई मॉडल विकल्प बनाता है, तो आप वापस free text parse करने के चक्कर में आ जाएँगे।

Jev से पूछना कि क्या उसे भरोसा है। इसके बजाय probability पढ़ें। खुद की रिपोर्ट लगभग हमेशा "हाँ" ही होती है।

कोई fallback न होना। Jev के हर फैसले के लिए "पक्का नहीं" का एक रास्ता होना चाहिए, और वह रास्ता Opus या इंसान है, कभी अंदाज़ा नहीं।

कोड की जगह prompt में retry limits रखना। जिस मॉडल को कहा गया है "सिर्फ 3 बार रिट्राई करो", वह कभी-कभी 30 बार रिट्राई कर देगा। कोड ऐसा नहीं करता।

पूरे टेस्ट सूट को छोड़ देना। फोकस्ड चेक्स आपकी रफ्तार बढ़ाते हैं। पूरा सूट आपको ईमानदार रखता है। दोनों को बनाए रखें।

कुछ भी मापना नहीं। अगर आप शुरू करने से पहले प्रति सेशन लागत (cost per session) का रिकॉर्ड नहीं रखते, तो आपको कभी पता नहीं चलेगा कि आपने 20% बचाया या 70%। सबसे पहले अपने सामान्य काम के एक हफ्ते का यूसेज डेटा निकाल लें। इसमें दस मिनट लगते हैं और यही वो इकलौता आंकड़ा है जो मायने रखता है।

इस हफ्ते क्या करें

यहाँ पूरी प्रक्रिया एक चेकलिस्ट के रूप में दी गई है:

1. एजेंट सेशन्स के एक हफ्ते का रिकॉर्ड रखें: स्टेप्स, टोकन, लागत, फेलियर।
2. अपने लूप में छिपे फैसलों को पहचानें: नोट्स, राउटिंग, रिकवरी, टेस्ट।
3. हर एक को विकल्पों की एक तय लिस्ट के साथ सवाल के रूप में लिखें।
4. एक हफ्ते तक Jev को अपने मौजूदा एजेंट के साथ शैडो मोड (shadow mode) में चलाएं।
5. असहमति (disagreement) लॉग से, रिस्क के आधार पर थ्रेशोल्ड तय करें।
6. पहले नोट्स सेलेक्शन चालू करें, फिर रिकवरी और टेस्ट, और अंत में राउटिंग।
7. पहले और बाद की प्रति सेशन लागत की तुलना करें। यही आपका असली आंकड़ा है।

Opus 5.5 कोड के लिए मेरे द्वारा इस्तेमाल किया गया सबसे बेहतरीन रीज़निंग मॉडल है। गलती यह है कि लोग बाकी सब कुछ भी इसी से करवाने की कोशिश करते हैं।

इसे सोचने दें। Jev को फैसला करने दें। अपने कोड को राज करने दें।

अगर यह जानकारी आपके काम आई, तो @cyrilXBT को फॉलो करें। मैं हर हफ्ते असली आंकड़ों के साथ बताता हूँ कि नए AI मॉडल्स के साथ चीज़ें कैसे बनाई जाती हैं।

इसे बुकमार्क कर लें ताकि जब आप बनाना शुरू करें, तो यह आपके पास रहे।