Claude Fable 5.1 AI एजेंट वर्कफ़्लो में विश्वसनीयता का नया स्तर लाता है। यह टूल कॉल, सब-एजेंट को काम सौंपने, मेमोरी मैनेज करने और लंबी अवधि की टास्क प्लानिंग को संभालता है, और Anthropic के पिछले मॉडलों की तुलना में कम विफलताओं और ज़्यादा अनुमानित व्यवहार के साथ।
अगर आप कुछ समय से AI एजेंट बना रहे हैं, तो आप इसकी विफलताओं के तरीके पहले से जानते हैं। मॉडल एक टूल कॉल को हैलुसिनेट कर देता है। वह एक ही स्टेप पर लूप में फँस जाता है। दो हज़ार टोकन पहले लिए गए फ़ैसले का उसे ध्यान नहीं रहता। ये कोई अपवाद नहीं हैं; ये प्रोडक्शन एजेंट डेवलपमेंट की रोज़ की रुकावटें हैं। Claude Fable 5.1 को ठीक इसी रुकावट को कम करने के लिए बनाया गया था, और यह लेख बताता है कि यह यह कैसे करता है और कहाँ अब भी कमी रह जाती है।
Anthropic की Fable मॉडल लाइन क्षमता के क्रम में Claude Sonnet 5 और Claude Opus 4.7 के बीच आती है, लेकिन इसका एक खास झुकाव है। Sonnet गति के लिए और Opus कच्ची रीज़निंग की गहराई के लिए अनुकूलित है, जबकि Fable को लगातार मल्टी-स्टेप एक्ज़ीक्यूशन के लिए बनाया गया है। जब एक ही टास्क में एक के बजाय बीस क्रमिक फ़ैसले चाहिए, तो आप इसी मॉडल तक पहुँचते हैं।
Anthropic का नामकरण सिर्फ़ वर्ज़न नंबर नहीं, बल्कि काम को भी दर्शाता है। "Fable" नैरेटिव कोहेरेंस का संकेत देता है: कई क्रियाओं के लंबे क्रम में एक लक्ष्य को मन में बनाए रखने और उसे एक सुसंगत नतीजे तक पहुँचाने की क्षमता। Claude Fable 5 ने आर्किटेक्चर पेश किया; वर्ज़न 5.1 टूल-यूज़ की विश्वसनीयता को बेहतर बनाता है और उन गलत सब-गोल बनाने की दर को कम करता है, जिसने शुरुआती एजेंट डिप्लॉयमेंट को परेशान किया था।
💡 ध्यान देने लायक बात: Fable 5.1 कोई सामान्य-उद्देश्य वाला चैट मॉडल नहीं है। इसे सरल Q&A या सिंगल-टर्न टास्क के लिए इस्तेमाल करना ऐसा है जैसे कील ठोकने के लिए खराद मशीन चलाना। सही टूल, गलत स्थिति।
5.1 में दो सबसे बड़े बदलाव हैं टूल कॉल स्कीमा एन्फ़ोर्समेंट और बेहतर स्टेप-लेवल कॉन्फ़िडेंस कैलिब्रेशन। 5.0 में मॉडल कभी-कभी ऐसी टूल कॉल बना देता था जो सिंटैक्टिक रूप से सही थी, पर सेमांटिक रूप से गलत थी, जैसे किसी पूर्णांक की जगह स्ट्रिंग भेज देना, भले ही स्कीमा साफ़ तौर पर दिया गया हो। वर्ज़न 5.1 इसे काफ़ी हद तक कसता है।
कैलिब्रेशन में सुधार कम दिखता है, पर एजेंट बनाने वालों के लिए ज़्यादा असरदार है। जब Fable 5.1 किसी अस्पष्ट ब्रांच पॉइंट पर पहुँचता है, तो वह आगे अनुमान लगाकर हैलुसिनेट करने के बजाय "रुकें और स्पष्ट करें" वाला संकेत देने की संभावना कहीं ज़्यादा रखता है। यह मायने रखता है, क्योंकि लंबे समय तक चलने वाली एजेंट पाइपलाइन में चुपचाप होने वाली हैलुसिनेशन सबसे मुश्किल से डीबग होने वाली विफलता है।
ज़्यादातर LLM सिंगल-टर्न बेंचमार्क पर प्रशिक्षित और मूल्यांकित किए गए थे। एक सवाल आता है; एक जवाब जाता है। मॉडल को कभी यह याद नहीं रखना पड़ता कि उसने तीन स्टेप पहले क्या तय किया था, या किसी टूल के नतीजे को अपनी पिछली धारणा से कैसे मिलाना है। चैट के लिए और वन-शॉट कोड जनरेशन के लिए यह ठीक है। लेकिन जब आप तीस स्टेप की डेटा एनरिचमेंट पाइपलाइन चलाने की कोशिश करते हैं, तो यह बुरी तरह टूट जाता है।
विफलता का खास तरीका है कॉन्टेक्स्ट ड्रिफ़्ट: जैसे-जैसे कॉन्टेक्स्ट विंडो टूल के नतीजों, बीच की रीज़निंग और सिस्टम संदेशों से भरती है, मॉडल धीरे-धीरे मूल लक्ष्य से अपना जुड़ाव खोने लगता है। वह "अच्छा अगला स्टेप क्या लगता है" के लिए ऑप्टिमाइज़ करने लगता है, न कि "असली उद्देश्य के लिए क्या सही है" के लिए। Fable 5.1 इसे छोटे डायलॉग डेटासेट के बजाय लंबी-अवधि के सिमुलेशन ट्रेस से मिली रीइन्फ़ोर्समेंट के ज़रिए संबोधित करता है।
लंबी अवधि के टास्क में कम से कम तीन ऐसी खासियतें होती हैं जो सिंगल-टर्न टास्क में नहीं होतीं: शर्तों पर आधारित ब्रांचिंग (स्टेप 7 विफल हो तो क्या करना है), जमा होती स्टेट (स्टेप 3 के नतीजे स्टेप 14 को प्रभावित करते हैं), और संसाधन की सीमाएँ (आपके पास X API कॉल, Y मिनट, या Z डॉलर ही हैं)। सिंगल-टर्न मॉडलों में इन सीमाओं के लिए कोई ढाँचा नहीं होता; वे एक स्टेटलेस वर्तमान में काम करते हैं।
Fable 5.1 हर स्टेप की शुरुआत में एक स्ट्रक्चर्ड कॉन्टेक्स्ट ब्लॉक पाता है, जिसमें शामिल है:
यह कोई जादू नहीं है; यह प्रॉम्प्ट आर्किटेक्चर है। लेकिन 5.1 को इस ब्लॉक को भारी महत्व देने और ड्रिफ़्ट होने पर बार-बार इसी पर लौटने के लिए प्रशिक्षित किया गया है।
Fable 5.1 में टूल यूज़ Anthropic के मानक function-calling API का पालन करता है। आप टूल्स को JSON स्कीमा के रूप में परिभाषित करते हैं, उन्हें रिक्वेस्ट के साथ भेजते हैं, और मॉडल या तो टेक्स्ट रिस्पॉन्स लौटाता है या एक स्ट्रक्चर्ड tool_use ब्लॉक। 5.1 में जो बदलता है वह है विफलता दर।
500 मल्टी-टूल एजेंट रन के एक सेट पर आंतरिक परीक्षण में, Fable 5.1 ने लगभग 1.2% इनवोकेशन में स्कीमा-अमान्य टूल कॉल बनाई, जबकि उन्हीं टास्क पर Claude 4.5 Sonnet के लिए यह दर 4.7% थी। 50 क्रमिक टूल कॉल वाली पाइपलाइन के लिए, प्रति कॉल 1.2% और 4.7% की त्रुटि दर का फ़र्क उस पाइपलाइन के बीच का फ़र्क है जो ज़्यादातर सही चलती है और उसे लगातार निगरानी की ज़रूरत पड़ती है।
tools = [
{
"name": "search_database",
"description": "Search the product database for matching records",
"input_schema": {
"type": "object",
"properties": {
"query": {"type": "string"},
"limit": {"type": "integer", "minimum": 1, "maximum": 100}
},
"required": ["query"]
}
}
]
Fable 5.1 एक ही रिस्पॉन्स टर्न में कई टूल कॉल माँगने को सपोर्ट करता है। यह एजेंट डेवलपमेंट के सबसे कम इस्तेमाल होने वाले फ़ीचरों में से एक है। जब एजेंट को आगे बढ़ने से पहले तीन स्वतंत्र स्रोतों से डेटा लाना हो, तो क्रमिक टूल कॉल वॉल-क्लॉक समय बर्बाद करती हैं और कुल टोकन उपयोग बढ़ाती हैं।
पैरेलल टूल यूज़ के साथ, Fable 5.1 एक ही रिस्पॉन्स में तीन टूल कॉल ब्लॉक दे सकता है। आपका ऑर्केस्ट्रेटर तीनों रिक्वेस्ट एक साथ भेजता है, नतीजे इकट्ठा करता है, और उन्हें अगले टर्न में एक साथ लौटाता है। जो टास्क क्रमिक कॉल के साथ 90 सेकंड में पूरा होता था, वह पैरेलल रिट्रीवल के साथ 35 सेकंड में पूरा हो सकता है।
💡 व्यावहारिक टिप: पैरेलल टूल यूज़ तभी समझदारी है जब टूल कॉल सचमुच स्वतंत्र हों। Fable 5.1 इस बात को पहचानने में अच्छा है कि कॉल कब पैरेलल चल सकती हैं और कब नहीं, लेकिन फिर भी आपको इसे अपने ऑर्केस्ट्रेटर लॉजिक में जाँचना चाहिए।
दो-स्तरीय ऑर्केस्ट्रेटर-वर्कर पैटर्न प्रोडक्शन मल्टी-एजेंट सिस्टम का सबसे आम आर्किटेक्चर है। ऑर्केस्ट्रेटर उच्च-स्तरीय योजना रखता है और काम को विशेष सब-एजेंट्स तक पहुँचाता है। हर सब-एजेंट का फ़ोकस सीमित होता है और उसके अपने टूल्स का सेट होता है।
Claude Fable 5 ऑर्केस्ट्रेटर की सीट पर उत्कृष्ट है। इसकी लंबी-अवधि की कोहेरेंस का मतलब है कि यह भूलता नहीं कि उसने कौन-से सब-एजेंट भेजे हैं या किन नतीजों का उसे अब भी इंतज़ार है। जिन सब-एजेंट भूमिकाओं में कम जटिलता पर उच्च गति चाहिए, उनके लिए Claude 4.5 Haiku किफ़ायती विकल्प है।
| भूमिका | सुझाया गया मॉडल | कारण |
|---|---|---|
| ऑर्केस्ट्रेटर | Claude Fable 5 | लंबी-अवधि की कोहेरेंस, कम ड्रिफ़्ट |
| रीज़निंग सब-एजेंट | Claude Sonnet 5 | गहराई और गति का संतुलन |
| तेज़ डेटा रिट्रीवल | Claude 4.5 Haiku | कम लेटेंसी, कम लागत |
| जटिल कोड जनरेशन | Claude Opus 4.7 | अधिकतम रीज़निंग गहराई |
यहीं ज़्यादातर एजेंट आर्किटेक्चर गलती करते हैं। आपके एजेंट सिस्टम को तीन प्रकार की मेमोरी चाहिए:
इन-कॉन्टेक्स्ट मेमोरी सबसे सरल है: मौजूदा मॉडल की कॉन्टेक्स्ट विंडो में मौजूद सब कुछ। Fable 5.1 में 200K टोकन तक सपोर्ट है, जो ज़्यादातर सिंगल-टास्क पाइपलाइन के लिए काफ़ी है। समस्या स्केल पर लागत और लेटेंसी की है।
एक्सटर्नल मेमोरी का मतलब है जानकारी को डेटाबेस, वेक्टर स्टोर, या नामित कैश में रखना, जिसे एजेंट टूल कॉल के ज़रिए लाता है। उन वर्कफ़्लो के लिए यह ज़रूरी है जो कई मॉडल इनवोकेशन में फैले हों या जिन्हें कॉन्टेक्स्ट में समा सकने से ज़्यादा जानकारी चाहिए।
प्रोसीड्यूरल मेमोरी सबसे ज़्यादा नज़रअंदाज़ होने वाली है: यह एजेंट का यह ज्ञान है कि काम कैसे करने हैं, जो डेटा में नहीं बल्कि सिस्टम प्रॉम्प्ट में ही दर्ज होता है। Fable 5.1 नंबर वाले प्रोटोकॉल के रूप में लिखे प्रोसीड्यूरल निर्देशों पर अच्छी प्रतिक्रिया देता है: "जब आप रिट्रीवल विफलता का सामना करें, तो एस्केलेट करने से पहले स्टेप 1, 2, 3 करें।"
राउटर-वर्कर पैटर्न इंटेंट क्लासिफ़िकेशन को टास्क एक्ज़ीक्यूशन से अलग करता है। राउटर (एक हल्का मॉडल या यहाँ तक कि नियम-आधारित सिस्टम) आने वाली रिक्वेस्ट को पढ़ता है और उसे उपयुक्त वर्कर एजेंट तक भेजता है। हर वर्कर के पास गहरा, विशेष सिस्टम प्रॉम्प्ट और सीमित टूल सेट होता है।
Fable 5.1 राउटर के रूप में खास तौर पर अच्छा काम करता है, क्योंकि यह अस्पष्ट रिक्वेस्ट को सबसे नज़दीकी कैटेगरी में ज़बरदस्ती डालने के बजाय सटीक रूप से पहचानता है। जब कोई रिक्वेस्ट दो वर्कर्स में से किसी का भी हो सकता है, तो Fable 5.1 आत्मविश्वास से गलत चुनाव करने के बजाय स्पष्टीकरण वाला सवाल पूछने की ज़्यादा संभावना रखता है।
💡 पैटर्न टिप: अपने राउटर का सिस्टम प्रॉम्प्ट छोटा और साफ़-साफ़ लिखा हुआ रखें। लंबे राउटर प्रॉम्प्ट ध्यान बिखेरते हैं। गहराई वर्कर प्रॉम्प्ट्स में डालें।
कोई भी पाइपलाइन जो दो मिनट से ज़्यादा चले, उसे अपनी स्टेट का चेकपॉइंट लेना चाहिए। चेकपॉइंटिंग का मतलब है हर सफल स्टेप के बाद मौजूदा एक्ज़ीक्यूशन स्टेट (पूरे हो चुके स्टेप, जमा नतीजे, योजना में मौजूदा स्थिति) को टिकाऊ स्टोरेज में सेव करना।
अगर एजेंट 30 में से स्टेप 17 पर विफल होता है, तो आप स्टेप 1 से दोबारा शुरू करने के बजाय स्टेप 17 से फिर शुरू करना चाहेंगे। Fable 5.1 चेकपॉइंट-आधारित फिर से शुरू करने के साथ अच्छा काम करता है, क्योंकि इसका कॉन्टेक्स्ट ब्लॉक आर्किटेक्चर आपको पूरी हिस्ट्री दोबारा चलाए बिना चेकपॉइंट से अर्थपूर्ण कॉन्टेक्स्ट दोबारा बनाने देता है।
def save_checkpoint(state: dict, step: int):
checkpoint_store.write(f"agent_run_{run_id}_step_{step}", json.dumps(state))
def load_checkpoint(run_id: str, step: int) -> dict:
return json.loads(checkpoint_store.read(f"agent_run_{run_id}_step_{step}"))
एजेंट डेवलपमेंट में स्वाभाविक प्रवृत्ति होती है कि एजेंट को यथासंभव स्वायत्त बनाया जाए। शुरुआती प्रोडक्शन डिप्लॉयमेंट में यह लगभग हमेशा गलती होती है। एक अच्छी तरह डिज़ाइन किए गए एजेंट में स्पष्ट इंटरप्ट शर्तें होनी चाहिए: ऐसी स्थितियाँ जहाँ वह रुकता है, अपनी मौजूदा स्थिति बताता है, और आगे बढ़ने से पहले इंसानी पुष्टि का इंतज़ार करता है।
Fable 5.1 की बेहतर कैलिब्रेशन उसे ज़रूरत पड़ने पर इंटरप्ट संकेत देने में ज़्यादा भरोसेमंद बनाती है, बजाय इसके कि वह अनिश्चित फ़ैसलों को आगे धकेलता जाए। आप इसे स्पष्ट सिस्टम प्रॉम्प्ट निर्देशों से मज़बूत कर सकते हैं:
ये सेफ़्टी थिएटर नहीं हैं। ये इस बात का फ़र्क हैं कि ऑपरेटर किस एजेंट पर भरोसा करते हैं और कौन सा पहली घटना के बाद बंद कर दिया जाता है।
ज़रूरी नहीं कि हर टीम एजेंट के मुख्य आधार के रूप में Fable 5.1 इस्तेमाल करे। PicassoIA पर उपलब्ध दूसरे प्रमुख मॉडलों के मुकाबले यह इस तरह है:
| मॉडल | कॉन्टेक्स्ट | टूल यूज़ | एजेंट कोहेरेंस | लागत |
|---|---|---|---|---|
| Claude Fable 5 | 200K | उत्कृष्ट | उत्कृष्ट | $$$ |
| Claude Sonnet 5 | 200K | बहुत अच्छा | अच्छा | $$ |
| GPT 5.1 | 128K | बहुत अच्छा | अच्छा | $$$ |
| Kimi K2.6 | 128K | अच्छा | मध्यम | $ |
| Deepseek R1 | 64K | मध्यम | मध्यम | $ |
| Gemini 3 Pro | 1M | अच्छा | अच्छा | $$ |
Gemini 3 Pro का 1M कॉन्टेक्स्ट प्रभावशाली लगता है, लेकिन कच्ची कॉन्टेक्स्ट लंबाई एजेंट कोहेरेंस के बराबर नहीं है। जो मॉडल 1M टोकन कॉन्टेक्स्ट में रख सकता है, पर 50K प्रभावी टोकन के बाद बुरी तरह ड्रिफ़्ट करता है, वह लंबी-अवधि के टास्क के लिए उस 200K मॉडल से बदतर है जो लक्ष्य के साथ सटीक तालमेल बनाए रखता है। Fable 5.1 की बढ़त आकार की नहीं, बल्कि पूरी विंडो में लक्ष्य-स्थिति पर ध्यान की गुणवत्ता की है।
GPT 5.1 सबसे करीबी प्रतिस्पर्धी है और एक वास्तव में मज़बूत विकल्प है, खासकर कोड-जनरेशन-भारी वर्कफ़्लो के लिए। दोनों में से चुनाव अक्सर इस पर निर्भर करता है कि किस मॉडल की टूल-कॉल स्कीमा की व्याख्या आपके खास टूल सेट के साथ बेहतर बैठती है।
Claude Fable 5 PicassoIA के प्लेटफ़ॉर्म पर Large Language Models कैटेगरी में सीधे उपलब्ध है। एजेंट-शैली के टास्क के लिए इसे इस्तेमाल करने का तरीका यह है:
चरण 1: मॉडल तक पहुँचें
PicassoIA पर Claude Fable 5 पर जाएँ। इंटरफ़ेस आपके उपयोग के अनुसार चैट-शैली इंटरैक्शन और स्ट्रक्चर्ड API एक्सेस, दोनों को सपोर्ट करता है।
चरण 2: अपना सिस्टम प्रॉम्प्ट सेट करें
एजेंट वर्कफ़्लो के लिए, आपके सिस्टम प्रॉम्प्ट में ये चीज़ें होनी चाहिए:
चरण 3: अपना कॉन्टेक्स्ट ब्लॉक स्ट्रक्चर करें
हर स्टेप की शुरुआत में एक स्ट्रक्चर्ड ब्लॉक डालें:
GOAL: [original objective]
FINISHED: [steps done so far, brief]
CURRENT STEP: [what to do now]
CONSTRAINTS: [time, cost, or scope limits]
चरण 4: टूल के नतीजों को साफ़-साफ़ संभालें
अगले टर्न में टूल के नतीजे स्पष्ट लेबल के साथ लौटाएँ। Fable 5.1 नतीजों के फ़ॉर्मेट के प्रति संवेदनशील है। TOOL_RESULT: search_database → 42 records found, top match: ... जैसा साफ़ लेबल वाला नतीजा बिना संदर्भ के भेजे गए, बिना लेबल वाले JSON डंप से कहीं बेहतर प्रदर्शन करता है।
चरण 5: निगरानी करें और चेकपॉइंट लें
हर टर्न लॉग करने के लिए PicassoIA के API का इस्तेमाल करें। सफल स्टेप के बाद चेकपॉइंट लिखें। उन टर्न के लिए अलर्ट सेट करें जहाँ मॉडल स्टॉप संकेत देता है या अप्रत्याशित फ़ॉर्मेट लौटाता है।
ज़्यादातर एजेंट विफलताएँ एक ही तीन गलतियों से होती हैं, चाहे आप कोई भी मॉडल इस्तेमाल करें:
1. एजेंट को ज़रूरत से ज़्यादा प्रॉम्प्ट देना
लंबा होना बेहतर नहीं है। वह सिस्टम प्रॉम्प्ट जो हर संभव स्थिति का अनुमान लगाने की कोशिश करता है, असंगत हो जाता है। Fable 5.1 अनिश्चितता को बेहतर संभालता है जब उसे संपूर्ण नियमों के बजाय स्पष्ट सिद्धांत दिए जाएँ। कम, लेकिन मज़बूत निर्देश लिखें और मॉडल को एज केस खुद तर्क करने दें।
2. टोकन बजट को नज़रअंदाज़ करना
कॉन्टेक्स्ट में जोड़ा गया हर टूल नतीजा बाद की हर कॉल पर टोकन खर्च करता है। जो पाइपलाइन 30 स्टेप तक भरपूर टूल नतीजों के साथ चलती है, वह स्टेप 15 तक आसानी से 100K टोकन का कॉन्टेक्स्ट जमा कर सकती है। सीमा पर पहुँचने से पहले अपनी कॉन्टेक्स्ट कंप्रेशन रणनीति बनाएँ, बाद में नहीं। Fable 5.1 माँगने पर पिछले स्टेप का सार बना सकता है; इसे शुरू से ही अपने ऑर्केस्ट्रेटर में बनाएँ।
3. इंटरप्ट लॉजिक छोड़ना
जिस एजेंट में रुकने की कोई शर्त नहीं है, वह एक ऐसा एजेंट है जो किसी घटना को जन्म देने के मौके का इंतज़ार कर रहा है। भले ही आप मॉडल पर भरोसा करते हों, फिर भी हाई-कॉस्ट कार्रवाइयों, अपरिवर्तनीय ऑपरेशनों और अप्रत्याशित डेटा स्थितियों के लिए इंटरप्ट शर्तें जोड़ें। आप एजेंट को बाद में ज़्यादा स्वायत्त बना सकते हैं; लेकिन दूषित रिकॉर्ड के बैच को पूर्ववत नहीं कर सकते।
Claude Fable 5.1 के साथ एजेंट वर्कफ़्लो में सहज होने का सबसे अच्छा तरीका है एक सरल तीन-स्टेप पाइपलाइन चलाना और हर टर्न पर होने वाली चीज़ों का अध्ययन करना। कोई ऐसा टास्क चुनें जिसे आप अच्छी तरह जानते हों: जैसे "URLs की सूची खोजें, हर पेज से मुख्य विषय निकालें, और एक क्वेरी से प्रासंगिकता के आधार पर उन्हें रैंक करें।" यह डीबग करने के लिए काफ़ी सरल है, लेकिन उन विफलता के तरीकों को उजागर करने के लिए काफ़ी जटिल है जिनका सामना आप प्रोडक्शन में करेंगे।
PicassoIA का लार्ज लैंग्वेज मॉडल कलेक्शन आपको एक ही जगह Claude Fable 5, Claude Sonnet 5, Claude Opus 4.7, और दर्जनों दूसरे मॉडलों तक पहुँच देता है। आप प्रयोग के बीच में मॉडल बदल सकते हैं, बिना अपना इंफ़्रास्ट्रक्चर दोबारा बनाए, जिससे तुलनात्मक टेस्टिंग काफ़ी तेज़ हो जाती है।
Claude Fable 5 से शुरू करें, देखें कि यह अस्पष्टता को कहाँ अच्छी तरह संभालता है और कहाँ अब भी आपके इनपुट की ज़रूरत है, और जो विफलता के तरीके आप देखें, उनके आधार पर अपनी इंटरप्ट शर्तें बनाएँ। यह कोई वर्कअराउंड नहीं है; प्रोडक्शन-ग्रेड एजेंट सिस्टम ऐसे ही बनते हैं।
अपनी भाषा चुनें
