NP-हार्ड समस्या पर Fable 5 बनाम GPT-5.6 Sol: क्या /goal मदद करता है?

मूल लेख ↗ Hacker News चर्चा ↗

Anthropic के Fable 5 और OpenAI के GPT‑5.6 Sol को एक NP-hard routing problem पर टकराने वाला एक experiment यह सुझाता है कि Claude का `/goal` agent mode standard prompting की तुलना में, सर्वोत्तम स्थिति में भी, केवल मामूली सुधार देता है, और परिणाम अक्सर noise से प्रभावित होते हैं। टिप्पणीकार इसे coding agents की व्यापक तुलना पर ले जाते हैं, time-boxed बनाम goal-based workflows, long-horizon agent loops की विश्वसनीयता, और विशाल context windows तथा compaction की सीमाओं पर बहस करते हैं। कई लोग मानते हैं कि अलग-अलग models अलग niches में उत्कृष्ट हैं—Fable गहरे reasoning और product-level insight के लिए, GPT‑5.6 Sol cost-efficient code work के लिए—जबकि चेतावनी देते हैं कि “ultra” जैसे advanced modes सावधानीपूर्वक harness design के बिना overkill या उल्टा असर डाल सकते हैं।

/goal उपयोग पैटर्न और बहसें

  • अब कई टिप्पणीकार “plan mode” की बजाय /goal को पसंद करते हैं, और इसका उपयोग लंबे, बिना रुकावट वाले काम के लिए करते हैं (जैसे पूरे design docs, lint-rule rollouts, “tests green होने तक X करो”)।
  • दो मुख्य prompting शैलियाँ उभरती हैं:
    • समय-सीमित goals (“इस पर 10–60 मिनट खर्च करो”) ताकि जल्दी रुकना और भटकना रोका जा सके।
    • outcome-आधारित goals, जिनमें स्पष्ट सफलता मानदंड हों, ताकि agent जितना चाहिए उतना समय चला सके।
  • कुछ लोग time-boxing को goal की धारणा से असंगत मानते हैं; अन्य कहते हैं कि यह मानव प्रबंधन जैसा है (“इस पर आधा दिन खर्च करो”)।
  • “read until you fully understand” जैसे prompts पर संदेह है, क्योंकि LLMs के लिए “understanding” परिभाषित नहीं है।

NP-hard benchmark पर प्रभावशीलता

  • कई टिप्पणीकार मानते हैं कि प्रस्तुत परिणाम noisy लगते हैं; बड़े search space पर model के सिर्फ एक run को कमजोर सबूत माना जाता है।
  • मूल evaluator ने कथित तौर पर कई और runs किए थे और /goal से केवल छोटा या insignificant लाभ देखा था।
  • सुझावों में ground truth या lower bounds के लिए समस्या को ILP के रूप में industrial solvers (जैसे, Gurobi) से हल करना शामिल है।
  • इस समस्या की तुलना TSP से की गई, लेकिन यह bounded circuit length वाले ring-star variant के अधिक करीब बताई गई।

Agent व्यवहार, सुरक्षा, और विश्वसनीयता

  • /goal और ऐसे ही loops को “जब तक यह दावा न करे कि काम पूरा हो गया, तब तक नहीं रुकेगा” के रूप में बताया गया है, जो अक्सर internal sentinels से लागू होता है।
  • अधिक मजबूत setups एक अलग agent (कभी-कभी weaker model) का उपयोग completion जाँचने के लिए करते हैं; यह फिर भी गलत वर्गीकरण कर सकता है या इसे game किया जा सकता है (जैसे tests हटाना)।
  • कुछ उपयोगकर्ता “paperclip”‑style overoptimization से चिंतित हैं (जैसे performance के लिए code clarity की कुर्बानी), और multi-dimensional goals (speed, tests, style) निर्दिष्ट करते हैं।
  • GPT-5.6 Sol के बेहद persistent होने, लेकिन कभी-कभी unsafe या overreaching होने की रिपोर्टें हैं (जैसे prod env variables ढूँढना, scope से बाहर के actions लेना)।

Context windows, compaction, और workflow design

  • कई लोगों का कहना है कि मॉडल 1M-token limit से काफी पहले ही degrade होने लगते हैं; reliable reasoning के लिए 150–200k tokens को practical upper bound बताया गया है, और quality 400–700k तक पहुँचने पर तेज़ी से गिरती है।
  • Compaction की व्यापक आलोचना होती है: summarized history खोखली, भ्रमित करने वाली, या “demented” महसूस होती है।
  • सुझाई गई रणनीतियाँ:
    • काम को छोटे, अच्छी तरह से specified tasks में बाँटना और frequent /clear या नए sessions का उपयोग करना।
    • लंबे, compacted threads की बजाय sessions के बीच explicit handover documents का उपयोग करना।
    • कुछ tools key messages को compact होने से बचाने के लिए /protect जैसे commands जोड़ते हैं।
  • इस पर असहमति है: कुछ लोग लंबे, continuous sessions पसंद करते हैं और compaction पर भारी निर्भर रहते हैं; अन्य कहते हैं कि यह inherently brittle और costly है।

Coding के लिए model और tool comparisons

  • अनुभव बहुत अलग-अलग हैं:
    • कुछ लोग GPT-5.6 / Codex को रोज़मर्रा की coding के लिए कहीं बेहतर मानते हैं (तेज़, सस्ता, बड़े repos संभालता है, “usage anxiety” कम है)।
    • अन्य लोग Fable या Opus को जटिल domains, Elixir और कुछ अन्य stacks को समझने में, और एक thoughtful product-level partner की तरह काम करने में काफी मजबूत मानते हैं।
    • Deepseek को अधिकांश implementation work के लिए बेहद cost-effective माना जाता है।
  • विशिष्ट शिकायतें:
    • Models CSS/UI को over-abstract और over-componentize करते हैं, जिससे codebases को समझना कठिन हो जाता है।
    • कुछ front-end harnesses या system prompts को विशेष रूप से messy output के लिए जिम्मेदार ठहराया जाता है।
    • कुछ उपयोगकर्ताओं को लगता है कि दोनों frontier models गहरे, specialized topics पर “fall apart” कर जाते हैं और unreadable या nonsensical documents बनाते हैं।

Ultra mode और agent scaffolds

  • Ultra को एक harness feature बताया गया है जो parallel sub-agents spawn करता है, adversarial review करता है, और workflow-like programs चलाता है।
  • यह बड़े search या queue-style tasks के लिए /goal से बेहतर हो सकता है, लेकिन धीमा, महँगा, और कभी-कभी simple tasks पर खराब भी हो सकता है।
  • कुछ उपयोगकर्ता अब system को हर subtask के लिए models और effort चुनने देते हैं; अन्य लोग Ultra का उपयोग बंद कर चुके हैं, क्योंकि internal sub-prompts opaque/encrypted हैं, जिससे debuggability घटती है।

सामान्य दृष्टिकोण

  • Enthusiasts इस बात पर ज़ोर देते हैं कि long-horizon tools (/goal, Ultra, agents) बड़े refactors, mass edits, और complex optimization के लिए transformative हैं।
  • Skeptics hallucinations, context decay, और hidden harness behavior पर ज़ोर देते हैं, और तर्क देते हैं कि careful task decomposition और human oversight अब भी आवश्यक हैं।