Fable 5 बनाम GPT-5.6 Sol: क्या NP-कठिन समस्याओं में `/goal` मददगार है?

• अप्रकाशित fiber network optimization समस्या पर 30-30 मिनट तक काम कराने पर Fable 5 ने सबसे ऊंचा स्कोर और सबसे स्थिर प्रदर्शन दिखाया, लेकिन /goal लगातार सुधार नहीं ला सका
• /goal सिर्फ मॉडल को अधिक देर तक काम करवाने वाला फीचर नहीं है; यह control loop और exploration path बदल देता है, जिससे अच्छी रणनीतियों के साथ गलत रणनीतियां भी बनी रह सकती हैं
• /goal ने Fable 5 और GPT-5.6 Sol की 6 paired runs में 4 बार जीत हासिल की, लेकिन कभी-कभार हुए बड़े performance drop की वजह से औसत स्कोर क्रमशः 759 points और 868 points खराब हो गया
• Fable 5 का सामान्य मोड औसतन 32,386 points और 319-point range के साथ सबसे स्थिर था, जबकि /goal मोड ने कुल सर्वश्रेष्ठ 31,934 points का रिकॉर्ड बनाया
• कठिन optimization में दोहराव होना या न होना नहीं, बल्कि दोहराई जा रही रणनीति की गुणवत्ता ज्यादा महत्वपूर्ण होती है, और individual win rate व average performance एक-दूसरे के उलट निष्कर्ष दे सकते हैं

---

KIRO fiber network optimization समस्या

• KIRO 2018 में engineering students के लिए आयोजित hackathon में सबमिट की गई एक operations research समस्या है, जिसमें Grenoble·Nice·Paris के directional distance matrices का उपयोग करके कुल cable length को न्यूनतम करना होता है
• network को distribution hub से शुरू होने वाले duplicate loops और उन loops पर मौजूद towers से निकलने वाली छोटी branches से बनाना होता है
  • सभी towers ठीक एक-एक बार आने चाहिए
  • कई structural constraints पूरी करनी होती हैं
  • cable segment का cost दिशा उलटने पर बदल सकता है
  • स्कोर जितना कम, समाधान उतना बेहतर
• human baseline वह C++ solver था जो अतीत में इस समस्या को हल करने के लिए एक हफ्ते में लिखा गया था

• search space का आकार

  • loops की संख्या और आकार, branches के reference points और क्रम अलग-अलग होने की वजह से पूरे search space को एक single closed-form formula से निकालना कठिन है
  • सिर्फ Paris के 532 terminals को बिना क्रम और बिना branches के 11 distribution hubs में assign करने की स्थिति में भी 11^532 संभावनाएं बनती हैं
  • अगर 28 terminals वाले 19 loops इस्तेमाल करने और branches हटाने वाले सीमित valid solutions ही गिने जाएं, तब भी search space लगभग 10^1223 तक पहुंचता है
  • 19 × 28 = 532 होने से सभी terminals शामिल हो जाते हैं
  • हर loop 30-terminal limit से कम रहता है
  • गणना का सूत्र (532! / 19!) × 11^19 ≈ 10^1223 है

मॉडल और रनिंग शर्तें

• Claude family के Fable 5·Opus 4.8·Sonnet 5 और GPT family के GPT-5.6 Sol·Terra·Luna की तुलना की गई
• हर मॉडल को सामान्य मोड और native /goal मोड में चलाया गया
  • optimization समय 30 मिनट
  • external agent time limit 1,900 seconds
  • reasoning settings हर मॉडल में उपलब्ध अधिकतम स्तर पर
  • execution environment Harbor 0.1.43, Docker और subscription authentication था
• पहले सभी मॉडलों के लिए बिना hint वाले 30-मिनट के सामान्य और /goal paired runs एक-एक बार किए गए
• मुख्य तुलना के लक्ष्य Fable 5 और GPT-5.6 Sol के लिए तब तक दोहराया गया जब तक प्रत्येक के 3 paired run pairs नहीं मिल गए
• पूरा code·prompt·results table·exclusion criteria·execution trace CLIArena में उपलब्ध हैं, और यह पिछले benchmark लेख का follow-up experiment है

Fable 5 और GPT-5.6 Sol के परिणाम

• अगर /goal स्कोर में से सामान्य मोड का स्कोर घटाने पर मान negative हो, तो /goal बेहतर परिणाम है
• Fable 5 के तीन runs के परिणाम इस प्रकार हैं
  • run 1: सामान्य 32,197 points, /goal 31,934 points, यानी 263-point सुधार
  • run 2: सामान्य 32,516 points, /goal 32,324 points, यानी 192-point सुधार
  • run 3: सामान्य 32,446 points, /goal 35,178 points, यानी 2,732-point गिरावट
• GPT-5.6 Sol के तीन runs के परिणाम इस प्रकार हैं
  • run 1: सामान्य 33,581 points, /goal 39,371 points, यानी 5,790-point गिरावट
  • run 2: सामान्य 35,539 points, /goal 32,703 points, यानी 2,836-point सुधार
  • run 3: सामान्य 33,663 points, /goal 33,313 points, यानी 350-point सुधार

• win rate और average अलग क्यों निकले

  • /goal ने 6 में से 4 बार जीत दर्ज की, लेकिन दोनों मॉडलों में छोटे सुधार अक्सर मिले और कभी-कभार बहुत बड़ा performance drop भी हुआ
  • Fable 5 का सामान्य मोड औसतन 32,386 points रहा, जबकि /goal औसतन 33,145 points पर पहुंचा, यानी 759 points खराब
  • median के आधार पर 192-point सुधार दिखा
  • GPT-5.6 Sol का सामान्य मोड औसतन 34,261 points और /goal औसतन 35,129 points रहा, यानी 868 points खराब
  • median के आधार पर 350-point सुधार दिखा
  • Fable 5 का सामान्य मोड औसतन Sol से 1,875 points बेहतर था, और /goal का average भी 1,984 points आगे रहा
  • stability में भी फर्क दिखा
    • Fable 5 के सामान्य मोड के तीनों परिणाम 319-point range के भीतर रहे
    • Sol का सामान्य मोड 1,958-point range में फैला रहा
  • Fable 5 /goal ने कुल सर्वश्रेष्ठ 31,934 points दर्ज किए
  • सबसे सुरक्षित configuration Fable 5 सामान्य मोड था

एक ही /goal, लेकिन अलग implementation

• Claude Code का अलग evaluation model

  • Claude Code का /goal session-scoped Stop hook की तरह काम करता है
  • main model हर turn खत्म करने पर default Haiku evaluation model goal condition और conversation पढ़ता है और कारण सहित yes या no लौटाता है
  • अगर no हो, तो नया turn शुरू होता है; अगर yes हो, तो goal हटा दिया जाता है
  • evaluation model tools का उपयोग नहीं कर सकता और न ही files inspect कर सकता है; वह सिर्फ conversation log में दिखने वाले evidence पर निर्णय लेता है
  • यह बहुत जल्दी काम खत्म कर देने की स्थिति पकड़ सकता है, लेकिन यह नहीं जान सकता कि solver को 10 million बार और चलाना लाभदायक होगा या नहीं
  • Claude Code open source नहीं है, इसलिए implementation की जानकारी Anthropic के goal दस्तावेज़ पर आधारित है

• Codex की persistent state और lifecycle tools

  • benchmark में इस्तेमाल किया गया Codex CLI 0.144.4 goal को thread से जुड़ी persistent state की तरह मानता है
  • TUI active thread का goal store करता है और SQLite state व budget usage रिकॉर्ड करता है
    • TUI implementation
    • SQLite schema
  • task model को create_goal, get_goal, update_goal tools मिलते हैं
  • goal सक्रिय रहते हुए thread idle हो जाए, तो goal और completion audit सहित follow-up turn inject किया जाता है
    • runtime implementation
    • follow-up prompt
  • Claude में completion judgment एक स्वतंत्र evaluation model को दिया जाता है, लेकिन वह मॉडल सिर्फ conversation log देख सकता है
  • Codex में task model files और tools का उपयोग करता है, खुद completion घोषित करता है, और persistent goal सक्रिय रहे तो फिर से काम जारी रखता है

/goal रणनीति को कैसे amplify करता है

• सामान्य coding tasks में अतिरिक्त turns से test ठीक करना या migration पूरा करना जैसी प्रगति को सत्यापित करना आसान होता है
• optimization में agent solver चुनने के बाद अतिरिक्त समय अच्छे और बुरे दोनों फैसलों को amplify कर सकता है
• /goal जिन मामलों में मददगार रहा, वे इस प्रकार हैं
  • Fable 5 के तेज compile-based portfolio को लगातार चलाना
  • Sol की सफल chain repartition strategy को जारी रखना
• इसके उलट, कुछ मामलों में इसने performance गिराई भी
  • Fable 5 ने धीमा solver बनाया और फिर उसे लगातार चलाता रहा
  • Sol सभी reference points को scan करने वाली exhaustive search पर अटक गया
• median में हल्का सुधार दिखा, लेकिन खराब परिणामों की tail बहुत ज्यादा बिगड़ गई, जिससे average performance घट गया

परिणामों की व्याख्या की सीमाएं

• प्रयोग का विषय सिर्फ एक अप्रकाशित NP-कठिन समस्या था, इसलिए इसे सामान्य coding leaderboard की तरह नहीं देखा जा सकता
• Fable 5 और Sol के लिए ही साफ-सुथरे matched paired runs के 3-3 सेट मिले
• दूसरे मॉडलों की तुलना में अलग-अलग prompts·wrapper versions·time limits मिले-जुले थे
• subscription service के जरिए sequential runs किए गए, इसलिए experiment के दौरान service state बदल गई हो सकती है
• task metadata में 1 CPU दर्ज था, लेकिन container में 8 CPUs expose थे, जिससे Fable 5 के parallel portfolio को फायदा मिला
• wrapper ने intermediate checkpoints और final validation मांगे, इसलिए score में शामिल Fable 5 और Sol के सभी outputs valid थे
• मापा गया विषय सिर्फ मॉडल नहीं, बल्कि model·CLI·prompt·subscription service·harness सहित पूरा system था

reproducibility सामग्री और निष्कर्ष

• CLIArena में benchmark tasks, wrappers, analysis scripts, chart generator और पूरा evidence memo सार्वजनिक है
• raw task directories आकार की वजह से Git से बाहर रखी गईं, लेकिन memo में सार्वजनिक किए जा सकने वाले सभी scores·city-wise results·elapsed time·strategies·exclusions·run IDs दर्ज हैं
• मुख्य execution commands इस प्रकार हैं

RUN_ID=article-kiro-YYYYMMDD-clean \
PHASE=nohint-all \
./scripts/run_subscription_article_matrix.sh
uv run python scripts/summarize_subscription_article_results.py RUN_ID...
uv run python scripts/analyze_subscription_article_results.py RUN_ID...

• /goal ने एक समान रूप से performance को न बढ़ाया, न घटाया; यह अधिकांश individual runs जीतते हुए भी observed average performance को खराब कर सकता है
• कठिन optimization में control loop की गुणवत्ता से ज्यादा महत्वपूर्ण वह रणनीति होती है जिसे वह loop बार-बार दोहराता है

[GN⁺]

Hacker News की राय

• ऊपर वाला chart थोड़ा भ्रमित करने वाला है। लिखा है “जितना कम, उतना अच्छा”, लेकिन y-axis उलटा है, इसलिए visually ऊपर बेहतर दिखता है और संख्याओं के हिसाब से कम होना बेहतर है

  • ऐसा नहीं लगता कि axis उलटा है। 32,000 नीचे है और 40,000 ऊपर, इसलिए शायद comment के बाद इसे ठीक किया गया हो

• Claude में कई हफ्तों तक चलने वाले long-running कामों में instructions भूलने की प्रवृत्ति है, चाहे आप उन्हें कितना भी महत्वपूर्ण बताएं। मैंने /goal इस्तेमाल नहीं किया, लेकिन शायद यह core instructions को सच में याद रखने में मदद करता है। यहां लगता है कि छोटे sessions की बात हो रही है, जहां यह समस्या कम होती है

  • Claude Code status bar में context usage जोड़कर देखा तो 50–60% से यह सच में “थकता” हुआ लगा। मैंने test environment में बदलाव और tests जोड़ने को कहा, तो उसने इसे “काफी infrastructure work” बताकर टाल दिया, लेकिन /compact के बाद फिर से कहा तो बिना शिकायत कर दिया
    हालांकि /compact में अक्सर errors आते हैं, इसलिए काम के बीच में इसकी सलाह नहीं दूंगा। संबंधित लेकिन नए काम पर जाते समय यह उपयोगी है, पर अभी-अभी लिखे code में deadlock जैसे fixes के लिए अच्छा नहीं है, जहां generation process का context चाहिए, क्योंकि यह reasoning process को फेंक देता है
  • यह pi के फायदों में से एक है। मैंने /protect command बनाया है, जो messages को compression से exclude करता है, और skills को भी auto-protect करता है। लंबे कामों में इसे /protect your goal is... की तरह इस्तेमाल करता हूं
  • कई execution environments में Claude और GPT को लंबे समय तक इस्तेमाल करने के बाद मैं सहमत हूं कि वजह context compression है। Codex का compression जादू जैसा natural continuity बनाए रखता है, लेकिन Claude में compression timing को बहुत सावधानी से manage करना पड़ा
  • quality compression तक पहुंचने से काफी पहले ही गिरने लगती है। compression notification “अगला petrol pump 100 miles” वाले signboard जैसा है, लेकिन तब तक आप पहले ही वीराने के बीच पहुंच चुके होते हैं
    बहुत जटिल process की जरूरत नहीं है, लेकिन बेहतर sequence है: काम को तोड़ना → नए context में plan बनाना → नए context में implement करना → नए context में /code-review → नए context में fix करना। Fable 5 में context 50% से ऊपर जाते ही quality बहुत गिर जाती है, कभी-कभी codebase में वही implementation चार-चार बार बन जाती है। उसी session में उससे अपना काम review करवाना ऐसा है जैसे student से अपनी answer sheet खुद check करवाना
  • लगभग 7 लाख token context पर Fable का judgement भी काफी गिर गया। OpenAI का Codex context को 4 लाख तक सीमित करने का फैसला सही हो सकता है, और यह ज्यादातर context को भरोसेमंद रखने का उचित point लगता है

• अगर search strategies की तुलना करनी है, तो Ultra mode शायद बेहतर होगा, इसलिए follow-up evaluation दिलचस्प होगी
  Ultra investigation agents को parallel में फैलाता है, तय checkpoints पर adversarial review करता है, और local optimum में फंसने से बचने के लिए कई techniques इस्तेमाल करता है। /goal single-path investigation या छोटे distributed/gathering tasks के लिए ज्यादा उपयुक्त है

  • Ultra mode के docs ज्यादा स्पष्ट लिखे जाने चाहिए या caution note लगना चाहिए। मेरे सहित कई developers ने इसे ऐसा all-purpose feature समझा कि model और मेहनत करेगा और बेहतर results देगा, लेकिन कई tasks में यह उल्टा worse performance दे सकता है और cost निश्चित रूप से ज्यादा होती है

• Anthropic coding क्षेत्र में OpenAI से काफी पीछे है। पिछले March तक मैंने Claude Code से कुल 4 लाख lines वाले repositories को basic plan पर manage किया, लेकिन यह बहुत slow था, और tests, observability, docs, layered architecture होने के बावजूद समस्याएं ठीक से fix नहीं कर पाया
  हम local government को deliver करने वाली 3-person team हैं, और Codex पर shift करने के बाद काम बहुत आसान हो गया और usage को लेकर चिंता भी खत्म हो गई। हर team member दो Codex Plus accounts से सब manage कर रहा है। Anthropic को डर फैलाने के बजाय efficient models बनाने चाहिए, और हर किसी को Fable की जरूरत नहीं है

  • मेरे लिए Opus 4.8 बेहद अच्छा रहा और Codex बस ठीक-ठाक लगा। शायद user और task पर depend करता है
  • problem domain और language के हिसाब से बहुत फर्क पड़ता है। GPT Elixir लिखने और open-ended tasks में काफी खराब था, अभी Opus Elixir में ज्यादा strong है, और Fable की problem domain को समझने की क्षमता दोनों से कहीं बेहतर है
    GPT पर switch करने के 6 हफ्तों में इसने लगातार गलत confidence दिया, इसलिए आखिर में मैंने पूरी तरह बंद कर दिया, और उस अवधि का काम लगभग waste हो गया। अब मैं Opus/Fable और DeepSeek Pro को मिलाकर इस्तेमाल करता हूं। DeepSeek cost efficiency और speed में जबरदस्त है और implementation tasks के 90% के लिए काफी है, लेकिन Elixir में compile time पर runtime functionality इस्तेमाल करने की कोशिश करते समय टूट जाता है। शुरुआती problem को Fable ने जल्दी साफ कर दिया
    हर model की अपनी अनोखी strengths हैं जिन्हें discover करना मुश्किल होता है, इसलिए निकट भविष्य में मुझे नहीं लगता कि मैं सिर्फ एक ही model इस्तेमाल करूंगा। quality चाहिए हो तो efficiency छोड़ने को तैयार हूं

• /goal ने मेरे काम में plan mode की जगह ले ली है, और मैं AI वाले 95% कामों में यह तरीका इस्तेमाल करता/करती हूँ
  पहले उसे कोई खास feature पढ़ने और यह पुष्टि करने को कहता/कहती हूँ कि उसने उसे पूरी तरह समझ लिया है; अगर summary में कोई detail छूट जाए तो इसे दोहराता/दोहराती हूँ। फिर मौजूदा समय पूछकर /goal के जरिए तय समय तक बिना अस्पष्टता वाला technical design document लिखवाता/लिखवाती हूँ, और carry_forward_requirements.md तथा testing_best_practices.md को स्पष्ट रूप से शामिल करने को कहता/कहती हूँ। इसमें इतने specific code/document references और changes डलवाता/डलवाती हूँ कि context न रखने वाला implementer भी इसे execute कर सके, और उसे पूरा समय review में लगाने व जल्दी खत्म न करने को कहता/कहती हूँ
  GPT को सिर्फ 10 मिनट तक design document लिखने के लिए मजबूर करने पर भी plan mode से कहीं ज्यादा मजबूत नतीजा मिला, जिससे draft सुधारने में लगने वाला समय बचा

  • समय के आधार पर रोकना कुछ ऐसा लगता है जैसे recursive function की termination condition को असल execution result के बजाय बीते हुए समय पर तय करना
    मैं /goal में agent के लिए स्पष्ट लक्ष्य डालता/डालती हूँ। Design और architecture को जिन conditions को satisfy करना है वे बताकर output को बार-बार उनसे मिलाना, और सब हासिल होने पर खत्म करना बेहतर है। 10 मिनट हों या 10 घंटे, किसी specific result को पूरा करना ही /goal का मूल है
  • Agent अगर लक्ष्य को भरोसेमंद तरीके से हासिल करे, तो hypothesis generation stage सबसे अहम लगती है। शुरुआत से ही सही search space में शुरू करना success का सबसे अच्छा predictor है, और model कितना भी मजबूत हो, उसे एक बड़े loop में सभी hypotheses को शुरुआत से पार करने देना practical कामों में dead end होने की संभावना रखता है
    जटिल domains में deep research को अलग tool call में delegate करना agent की नींव मजबूत करने का सबसे अच्छा तरीका रहा। अगर research मुख्य agent loop को सौंप दी जाए, तो RLHF की context preserve करने और जल्दी जवाब देने की tendency के कारण quality गिरती है। Tool के रूप में देने पर वह यह जाने बिना कि billions tokens खर्च हो रहे हैं, कई बार research कर सकता है, और independent hypothesis generation व validation में बहुत tokens waste होने पर भी environment बदलने से पहले search space को 10–100 गुना बढ़ा सकता है। कई cases में accuracy > time > cost की priority सही लगती है
  • LLM ने किसी चीज़ को “पूरी तरह समझ लिया” मानना अजीब है। यह “95% confident होने तक” जैसे prompt techniques जैसा है; जानना चाहूँगा/चाहूँगी कि असल काम पर इसका क्या असर पड़ता है। “जब तक पक्का समझ न आ जाए” लिखने से क्या बदलता है, यह भी सवाल है

• सोच रहा/रही हूँ कि /goal क्या है

  • Codex और Claude Code दोनों इसे देते हैं, लेकिन काम करने का तरीका थोड़ा अलग है
    Claude Code में Haiku conversation history पढ़कर तय करता है कि goal पूरा हुआ या नहीं; अगर पूरा नहीं हुआ तो बाकी काम main model में फिर inject करता है। Codex में main model द्वारा call किए जा सकने वाले tools और आसपास का execution environment साथ मिलकर काम करते हैं, और completion mark न हो तो फिर prompt करते हैं
    यह उस स्थिति को हल करने की feature है जहाँ model attention issues की वजह से काम का सिर्फ एक हिस्सा खत्म करके रुक जाता है। User के खुद “continue” कहकर push करने के बजाय यह automatically extra instruction देकर काम पूरा करवाने की कोशिश करता है
  • Claude में शुरू से /goal इस्तेमाल करने पर वह goal हासिल होने या prompt की संभावनाएँ खत्म होने तक नहीं रुकता। “यह तुम्हारा mission है, इसे करो” जैसा feel है, और मैं इसे हफ्ते में कुछ बार इस्तेमाल करता/करती हूँ
  • यह feature LLM को goal conditions पूरी होने तक repeat execution कराता है
  • सही कहें तो यह तब तक repeat करता है जब तक वह खुद न मान ले कि goal पूरा हो गया है
  • Structure ऐसा है कि agent खुद LLM को repeat execute करता है और तय करता है कि रुकना है या नहीं। /goal उसके ऊपर एक और parent agent रखने जैसा है, जो child agent के खुद को finished मानने तक बार-बार कहता है, “अभी खत्म नहीं हुआ, जारी रखो”

• Release के बाद से GPT 5.6 Sol Xhigh और Fable 5 काफी इस्तेमाल किया है। Intelligence 5.5 जैसी लगती है, लेकिन persistence को extreme level तक बढ़ाकर task completion rate और benchmark competitiveness बेहतर की गई लगती है। दूसरी ओर, असामान्य या dangerous तरीकों तक अपनाने की संभावना बढ़ जाती है, इसलिए लगातार monitor करना पड़ता है
  हाल में इसने task से unrelated production environment variables CLI से पढ़ने की कोशिश की, और SSH key access fail होने पर computer control permission मांगी। रोकने के बाद वजह पूछी तो बताया कि वह 1Password में सीधे खोजकर key ढूँढने वाला था; फिर सवाल करने पर माना कि production environment variables की जरूरत नहीं थी। उसके बाद से मैंने “approve for me” mode बंद कर दिया है और इसे सिर्फ simple changes व bug fixes के लिए इस्तेमाल कर रहा/रही हूँ
  Fable न सिर्फ ज्यादा intelligent है बल्कि उसमें insight भी ज्यादा है, intent अच्छी तरह समझता है और real-world knowledge के आधार पर domain-expert product manager की तरह act करता है। यह unexpected suggestions भी देता है, लेकिन GPT 5.6 को काफी ज्यादा literal instructions देने पड़ते हैं

  • Fable बड़ा model लगता है, इसलिए execution cost ज्यादा है; सामान्य software engineering में यह superior नहीं दिखता, लेकिन pure intelligence मांगने वाले tasks में size advantage हो सकता है
    DeepSWE 1.1 में 5.6-Sol xhigh का score Fable 5 से थोड़ा ज्यादा है, जबकि token आधे और cost करीब एक-तिहाई है। वहीं Artificial Analysis intelligence index में Fable 5 थोड़ा आगे है, लेकिन cost तीन गुना है
    Coding के समय मैं दोनों models को वही task भेजकर कई answers लेता/लेती हूँ; result subjective होता है, इसलिए predict करना मुश्किल है कि कौन जीतेगा। Original post के task की खूबी यह है कि उसे quantify किया जा सकता है, लेकिन बहुत से software tasks को इस तरह evaluate करना मुश्किल है

• GPT ने हाल में AtCoder heuristic contest में top human participants को हराया है, इसलिए ऐसे optimization problems में इसे ज्यादा मजबूत होना चाहिए। Anthropic शायद इस type पर relatively कम focus करता है

• सिर्फ final score नहीं, बल्कि समय के साथ best score भी देखना चाहूँगा/चाहूँगी। इससे /goal का effect judge करने में ज्यादा मदद मिलेगी

• हर model पर evaluation सिर्फ एक बार है, और problem space बहुत बड़ा है जिसमें अच्छे solution के लिए कई attempts चाहिए, इसलिए ज्यादातर results noise जैसे दिखते हैं

  • असल में prompts और execution time बदलकर ज्यादा runs किए थे, लेकिन हर बार /goal का असर छोटा या meaningful नहीं था