GPT-5.5 low vs medium vs high vs xhigh: open source रिपॉजिटरी के 26 वास्तविक कार्यों में दिखी reasoning curve

 (reddit.com)
5 पॉइंट द्वारा GN⁺ 8 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • जब GraphQL-go-tools के 26 वास्तविक कार्यों पर GPT-5.5 Codex को low, medium, high, xhigh सेटिंग्स के साथ चलाया गया, तो reasoning effort का अंतर test pass से अधिक human patch के साथ semantic equivalence और code review pass rate में स्पष्ट दिखा
  • test pass परिणाम low 21/26, medium 21/26, high 25/26, xhigh 24/26 रहे, लेकिन semantic equivalence 4/26 → 11/26 → 18/26 → 23/26 तक बढ़ी और code review pass भी 3/26 → 5/26 → 10/26 → 18/26 तक पहुँचा
  • high ने medium की तुलना में test pass, equivalence और review pass — तीनों में सुधार किया, जबकि औसत लागत $3.13 से बढ़कर $4.49 यानी 1.43 गुना हुई, इसलिए इस dataset में यह सबसे व्यावहारिक default setting लगती है
  • xhigh ने high की तुलना में equivalence और review quality को काफी बढ़ाया, लेकिन औसत लागत $9.77 और औसत execution time 753.3 सेकंड तक पहुँच गया, और इसने अधिक test, fixture, और expected-output बदलाव भी बनाए, जिससे footprint risk भी बढ़ा
  • reasoning effort का प्रभाव task-दर-task monotonic नहीं था; कुछ जगह high ने xhigh को पीछे छोड़ा, और कुछ ऊँची settings ने plausible लेकिन गलत implementation भी बनाए, इसलिए टीमों को global benchmark के बजाय अपने harness और अपने tasks पर मापना चाहिए

प्रयोग का उद्देश्य और evaluation method

  • GPT-5.5 Codex को उसी open source repository के 26 tasks पर low, medium, high, xhigh reasoning effort settings के साथ अलग-अलग चलाकर, केवल test pass ही नहीं बल्कि human-merged PR के साथ semantic equivalence और reviewability की भी तुलना की गई
  • target repository Go-आधारित GraphQL-go-tools है, और हर task किसी वास्तविक merged PR या commit से निकाला गया है
  • हर task में एक fixed repository snapshot, change request prompt, और Docker container के अंदर patch generate करने की एक single attempt शामिल थी
  • Stet generated patch को apply करता है और isolated container में task-specific tests चलाकर pass/fail की पुष्टि करता है
  • tests के बाद निम्न मानदंडों पर अतिरिक्त evaluation किया गया
    • equivalence: क्या candidate patch ने मूल human patch जैसा वही behavioral change हासिल किया
    • code review pass: correctness, bug introduction risk, maintainability, और edge cases को देखते हुए क्या reviewer इसे स्वीकार करेगा
    • footprint risk: human-made patch की तुलना में agent ने अतिरिक्त कितना code छेड़ा
    • craft/discipline rubric: clarity, simplicity, consistency, intentionality, robustness, instruction following, scope discipline, और diff minimality का मूल्यांकन
  • सभी models को प्रति task एक बार, single seed के साथ चलाया गया
  • LLM judge model GPT-5.4 था, और judge केवल patch और task देखता था; वह यह नहीं देखता था कि patch किस model या reasoning setting से बना है
  • representative examples को manually भी जाँचा गया, लेकिन इस task set के लिए अलग से human calibration नहीं थी, इसलिए एकल absolute score से अधिक बदलाव की दिशा पर भरोसा करना चाहिए
  • execution details
    • model: GPT-5.5
    • harness: Codex 0.128.0
    • dataset: वास्तविक GraphQL-go-tools tasks 26
    • मुख्य metrics: test pass, semantic equivalence, code review pass, footprint risk, craft/discipline custom evaluation, cost और execution time
  • interactive charts और task-by-task detailed analysis https://stet.sh/blog/gpt-55-codex-graphql-reasoning-curve पर उपलब्ध हैं
  • AGENTS.md को बेहतर बनाने वाले automated research loop में भी वही evaluation इस्तेमाल की गई
    • agent repository के लिए AGENTS.md improvement draft बनाता है, फिर Stet के साथ past tasks चलाता है, और कहाँ सुधार हुआ या गिरावट आई यह ढूँढकर iterate करता है

overall metrics और interpretation

  • overall metrics दिखाते हैं कि reasoning effort बढ़ने पर test pass की तुलना में semantic equivalence और review pass rate में बड़ा अंतर दिखता है
  • मुख्य परिणाम
    • test pass: low 21/26, medium 21/26, high 25/26, xhigh 24/26
    • human patch के साथ equivalence: low 4/26, medium 11/26, high 18/26, xhigh 23/26
    • code review pass: low 3/26, medium 5/26, high 10/26, xhigh 18/26
    • craft/discipline average: low 2.311, medium 2.604, high 2.736, xhigh 3.071
    • average task cost: low $2.65, medium $3.13, high $4.49, xhigh $9.77
    • average agent execution time: low 286.9 सेकंड, medium 411.0 सेकंड, high 579.0 सेकंड, xhigh 753.3 सेकंड
  • low और medium दोनों का test pass 21/26 था, लेकिन equivalence 4/26 से 11/26 तक बढ़ी, और review pass 3/26 से 5/26 तक पहुँचा
  • high ने medium की तुलना में test pass में +15.4%p, equivalence में +26.9%p, और review pass में +19.2%p का सुधार दिखाया, इसलिए व्यावहारिक सुधार का सबसे स्पष्ट स्तर यही था
  • xhigh में high की तुलना में test pass -3.8%p कम रहा, लेकिन equivalence +19.2%p और review pass +30.8%p बढ़े
  • इससे संकेत मिलता है कि reasoning effort केवल test pass rate नहीं बदलता, बल्कि Codex द्वारा बनाए जाने वाले patch के प्रकार को बदलता है
  • public benchmarks अक्सर binary task success पर रुक जाते हैं, लेकिन वास्तविक software engineering में यह भी महत्वपूर्ण है कि patch merge हो सके और बाद में maintain भी किया जा सके
  • Terminal-Bench मुख्यतः कठिन coding problems पर केंद्रित है, SWE-bench verified में यह संभावना है कि model पहले से answers देख चुका हो, और SWE-bench Pro उपयोगी है लेकिन अधिक general nature का है
  • इस प्रयोग का मुख्य सवाल यह है: “क्या agent ने मेरे codebase में वैसा ही बदलाव किया जैसा किसी human ने merge किया होता?” और “क्या मैं इस patch का आगे ownership लेना चाहूँगा?”

low से medium: heuristics से domain modeling की ओर

  • low और medium दोनों का test pass 21/26 था, इसलिए केवल tests देखें तो यह tie जैसा लगता है
  • लेकिन medium में semantic equivalence 4/26 से बढ़कर 11/26 हुई, और craft/discipline average भी 2.311 से 2.604 तक पहुँचा
  • इस दायरे में अगर केवल tests को मापा जाए, तो reasoning effort के अंतर का बड़ा हिस्सा छूट जाएगा
  • low में pass होने वाले patches भी कई बार heuristics या partial implementation तक सीमित रहे, जबकि medium repository और domain semantics को बेहतर model करने की दिशा में गया
  • PR #1297 उदाहरण
    • यह GraphQL Federation में nullable external @requires dependency को validate करने का task था
    • अगर nullable required field error के साथ null लौटे, तो उस contaminated entity को dependent downstream fetch तक नहीं भेजना चाहिए
    • task का सार केवल validation branch जोड़ना नहीं, बल्कि subtle federation data dependency rules को model करना था
    • low ने test pass किया, लेकिन required-field/error matching को heuristic तरीके से handle किया और structured nullable @requires metadata को miss कर दिया, इसलिए वह equivalent नहीं था और review भी pass नहीं कर सका
    • medium ने contaminated objects को track किया और downstream fetch input को filter किया, जिससे equivalence और review pass दोनों मिले, और craft/discipline quality 1.350 से बढ़कर 3.225 हो गई
    • high और xhigh भी लगभग इसी quality band में रहे, इसलिए यह task मुख्यतः low से medium की छलांग को दिखाता है

high: व्यावहारिक डिफ़ॉल्ट के सबसे करीब वाला बिंदु

  • high, medium की तुलना में test pass, semantic equivalence, और review pass — तीनों में सुधार दिखाता है, जबकि लागत बढ़ती तो है लेकिन अत्यधिक नहीं होती
  • high और medium की तुलना
    • test pass: 21/26 से बढ़कर 25/26
    • equivalence: 11/26 से बढ़कर 18/26
    • code review pass: 5/26 से बढ़कर 10/26
    • औसत footprint risk: 0.268 से बढ़कर 0.314
    • औसत craftsmanship/discipline: 2.604 से बढ़कर 2.736
    • औसत task cost: $3.13 से बढ़कर $4.49, यानी 1.43 गुना
    • औसत execution time: 411.0 सेकंड से बढ़कर 579.0 सेकंड
  • high वह बिंदु लगता है जहाँ अतिरिक्त tokens वास्तविक लाभ में बदलने लगते हैं, और integration details को सही बैठाने की दर भी बढ़ती है
  • PR #1209 उदाहरण
    • यह काम gRPC datasource को response JSON में GraphQL alias का सम्मान करने, referenced protobuf message type को पहले से validate करने, और union/interface mutation path की mapping coverage को अपडेट करने का था
    • low और medium दोनों ने test pass किए, लेकिन equivalence नहीं मिला और review भी fail हुआ
    • medium ने alias serialization और missing message validation का बड़ा हिस्सा संभाल लिया, लेकिन createUser mutation mapping update छूट गया और JSONPath पर response-key semantics का ज़रूरत से ज़्यादा भार डाल दिया
    • high ने explicit response-key/alias handling जोड़ी और planning तथा JSON marshaling में alias को end-to-end propagate करके पहला strict pass हासिल किया
    • high की custom quality 3.625 तक पहुँची, और यह सिर्फ़ ज़्यादा code जोड़ने का मामला नहीं था, बल्कि integration obligations को ठीक-ठीक पूरा करने का था
    • xhigh भी pass हुआ, लेकिन उसने task-level interpretation को बेहतर नहीं किया, और regenerated summary के आधार पर agent execution time high के 314.0s की तुलना में लंबा 790.7s रहा
  • PR #1155 उदाहरण
    • यह gRPC datasource hardening का काम था, जिसमें repeated scalar field support, null/invalid message panic से बचाव, gRPC status code propagation, datasource disabling, और dynamic client support शामिल थे
    • low और medium ने test तो pass किए, लेकिन equivalence नहीं मिला
    • medium ने robustness सुधारी, लेकिन invalid repeated field को empty array के रूप में serialize किया, aliased-root planning behavior को miss किया, और dynamic-client lifecycle risk छोड़ दिया
    • high ने अधिक सुरक्षित nil/invalid handling, status-code propagation, disabled-datasource behavior, और dynamic client-provider coverage के साथ equivalence और review दोनों pass किए
    • इस task में xhigh ने test pass किए, लेकिन disabled datasource semantics और invalid-list behavior को ग़लत संभालने के कारण equivalence नहीं मिला और review भी fail हुआ

xhigh: डिफ़ॉल्ट से ज़्यादा quality mode के करीब

  • xhigh ने high की तुलना में semantic और review quality बढ़ाई, लेकिन यह ऐसा मामला नहीं है जहाँ सिर्फ़ setting बढ़ा देने से सब कुछ बेहतर हो जाए
  • xhigh और high की तुलना
    • test pass: 25/26 से घटकर 24/26
    • equivalence: 18/26 से बढ़कर 23/26
    • code review pass: 10/26 से बढ़कर 18/26
    • औसत footprint risk: 0.314 से बढ़कर 0.365
    • औसत craftsmanship/discipline: 2.736 से बढ़कर 3.071
    • औसत task cost: $4.49 से बढ़कर $9.77, यानी 2.18 गुना
    • औसत execution time: 579.0 सेकंड से बढ़कर 753.3 सेकंड
  • xhigh ज़्यादा आधार-क्षेत्र कवर करता है, human intent से बेहतर मेल खाता है, और अधिक complete बदलाव बनाने की प्रवृत्ति रखता है, लेकिन इसके लिए काफ़ी ज़्यादा tokens खर्च होते हैं
  • review rubric में xhigh का औसत 3.365 और median 3.500 था, जो high के औसत 2.817 और median 2.750 से ऊँचा है
  • median भी average से ऊँचा है, इसलिए xhigh का सुधार सिर्फ़ एक-दो शानदार patches के कारण average बढ़ जाने जैसा नहीं लगता
  • xhigh semantic रूप से ज़्यादा complete है, लेकिन मानव-निर्मित patch की तुलना में ज़्यादा code छूता है, इसलिए footprint risk भी बढ़ता है
  • 26 tasks में xhigh ने कुल 13,144 lines जोड़ीं, जिनमें implementation code 5,918 lines और test·fixture·expected-output 7,226 lines थीं
  • high की तुलना में xhigh ने 2,631 अतिरिक्त lines जोड़ीं, जिनमें से 2,436 lines test·fixture·expected-output files में थीं
  • footprint में वृद्धि सिर्फ़ इसलिए नहीं है कि उसने बहुत बड़ा production code लिखा, बल्कि इसलिए भी कि xhigh ने validation और fixture coverage ज़्यादा बनाई
  • लेकिन test, fixture, और expected-output में बदलाव भी review और maintenance की दृष्टि से वास्तविक surface area ही हैं
  • PR #1076 उदाहरण
    • यह subscription handling को फिर से संरचित करने का काम था ताकि shared mutex race condition से बचा जा सके
    • requirements में per-subscription serialized write, per-subscription heartbeat control, race detector coverage, और WebSocket close semantics का सुधार शामिल था
    • medium ने tests pass किए, लेकिन equivalence नहीं मिला और review भी fail हुआ
    • high ने equivalence और instruction-following हासिल किया, लेकिन नई worker queue global subscription event loop को block कर सकती थी, shutdown अटके हुए worker के पीछे रुक सकता था, hung update अनbounded रह सकता था, और client-level unsubscribe अब भी internal subscription को skip कर रहा था, इसलिए review fail हुआ
    • xhigh पहला strict pass था और उसने custom quality को 3.475 तक बढ़ाया
    • concurrency-heavy tasks में xhigh review risk साफ़ करने के लिए quality mode की तरह काम करता है, यह उसका सबसे अच्छा उदाहरण था
  • PR #1308 उदाहरण
    • यह GraphQL @oneOf input object को implement करने का काम था
    • इसमें built-in directive जोड़ना, introspection exposure, operation literal और runtime variable validation, तथा undefined-variable source location को बेहतर करना ज़रूरी था
    • medium और high ने tests pass किए, लेकिन runtime variable, nullable variable, provided-null payload, और introspection shape से जुड़े महत्वपूर्ण @oneOf semantics miss कर दिए, इसलिए equivalence नहीं मिला और review भी fail हुआ
    • xhigh पहला strict pass था, और उसने robustness 3.7, instruction-following 4.0, custom quality 3.525 दर्ज की
    • फ़र्क सतही polish में नहीं, बल्कि कई system हिस्सों में फैली edge-case coverage में था
  • PR #1240 उदाहरण
    • यह GraphQL AST field-selection merging और inline-fragment selection merging को एक normalization walk में समेकित करने का काम था
    • low और high strict pass थे
    • xhigh semantic evaluation के हिसाब से equivalent था, लेकिन prioritized subpass को बनाए रखा, AbstractFieldNormalizer का क्रम बदल दिया, और पुराना field-merge registration छोड़ दिया, इसलिए review fail हुआ
    • ऊँची reasoning setting भी अधिक sophisticated और plausible refactoring बना सकती है, जबकि tests और reviewers जिस सटीक execution behavior को महत्व देते हैं, उसे फिर भी miss कर सकती है

निर्माण·अनुशासन, लागत, सीमाएँ और निष्कर्ष

  • निर्माण·अनुशासन custom evaluation भी review rubric की तरह reasoning effort बढ़ने पर कुल मिलाकर ऊपर जाता है
  • all-custom score में xhigh का औसत 3.071, median 3.087 रहा, जो high के औसत 2.736, median 2.688 से अधिक है
  • निर्माण और अनुशासन दोनों में median भी ऊँचा है, इसलिए इसे इस तरह समझा जा सकता है कि xhigh ने सिर्फ कुछ असाधारण उदाहरण ही नहीं बनाए, बल्कि कुल patch quality को भी बेहतर किया
  • औसत/median मेट्रिक्स
    • Craft aggregate: low 2.327 / 2.338, medium 2.618 / 2.525, high 2.781 / 2.787, xhigh 3.126 / 3.100
    • Discipline aggregate: low 2.295 / 2.325, medium 2.590 / 2.588, high 2.691 / 2.688, xhigh 3.015 / 3.013
    • All custom graders: low 2.311 / 2.338, medium 2.604 / 2.550, high 2.736 / 2.688, xhigh 3.071 / 3.087
  • विस्तृत व्याख्या
    • low में robustness और instruction following कमजोर हैं
    • medium, test pass की कुल मात्रा बढ़ाए बिना भी इस हिस्से को अर्थपूर्ण रूप से बेहतर करता है
    • high, वास्तविक accuracy और robustness में सुधार करता है
    • xhigh, scope और diff discipline सहित लगभग हर dimension में सुधार करता है
  • लागत और समय
    • low: औसत लागत $2.65, median $1.91, औसत execution time 286.9s, median 294.6s
    • medium: औसत लागत $3.13, median $2.87, औसत execution time 411.0s, median 371.8s
    • high: औसत लागत $4.49, median $3.99, औसत execution time 579.0s, median 572.9s
    • xhigh: औसत लागत $9.77, median $6.39, औसत execution time 753.3s, median 732.7s
  • लागत में low और खासकर xhigh पर skew दिखता है, और xhigh की औसत लागत कुछ महंगे tasks से प्रभावित है
  • median के आधार पर भी xhigh, high से अधिक महंगा और धीमा है
  • medium की तुलना में high की प्रति task लागत लगभग 1.43 गुना है, और high की तुलना में xhigh की लागत लगभग 2.18 गुना है
  • सीमाएँ
    • प्रति task केवल एक seed इस्तेमाल किया गया
    • इसमें सिर्फ GraphQL-go-tools के 26 वास्तविक tasks शामिल थे
    • LLM judge GPT-5.4 था, और वह patch·task देखता था लेकिन label नहीं देखता था
    • इस task set के लिए grader calibration नहीं था
    • इसे सांख्यिकीय रूप से महत्वपूर्ण सार्वभौमिक निष्कर्ष या दूसरे repositories पर सीधे लागू होने वाला परिणाम नहीं माना जा सकता
  • संबंधित तुलना
    • Voratiq का वास्तविक task leaderboard भी, भले methodology अलग हो, मिलती-जुलती दिशा दिखाता है
    • Voratiq में GPT-5.5 xhigh 1994 और GPT-5.5 high 1807 रहा, यानी +187 points, +10.3% की बढ़त
    • लागत $4.23 बनाम $2.52 रही, यानी +67.9%, और समय 11.9m बनाम 7.8m रहा, यानी +52.6%
    • Stet experiment में high → xhigh पर equivalence +19.2%p, relative +27.8%, code review pass +30.8%p, relative +80.0% के साथ अधिक बड़ा अंतर दिखा, और निर्माण/अनुशासन aggregate +12.2% के साथ समान रहा
    • Voratiq ongoing work के लिए preference/selection शैली का leaderboard है, जबकि यह experiment 26-task repository slice पर आधारित है, इसलिए दोनों की सीधी तुलना नहीं की जा सकती
  • व्यावहारिक निष्कर्ष
    • xhigh उन tasks के लिए उपयुक्त है जो अस्पष्ट हों, कई क्षेत्रों में फैले हों, concurrency-केंद्रित हों, या जिनमें review risk अधिक हो
    • इस dataset में high, default daily driver के रूप में सबसे व्यावहारिक setting लगती है
    • medium या उससे नीचे की settings तब उपयुक्त हैं जब लागत अधिक महत्वपूर्ण हो और task नियमित या अच्छी तरह परिभाषित हो
    • reasoning effort का प्रभाव task के अनुसार smooth या monotonic नहीं है; कुछ मामलों में high, xhigh को हरा देता है, या ऊँची setting देखने में ठीक लगने वाली लेकिन गलत implementation बना देती है
    • टीमों को global benchmark defaults की नकल करने के बजाय अपने harness और अपने tasks पर मापना चाहिए
  • सार्वजनिक जानकारी
    • वे Stet.sh बना रहे हैं, और इसी local evaluation tool से experiment चलाया गया
    • product version में coding agent, AGENTS.md improvement जैसे candidate changes बनाता है, और Stet के जरिए पुराने repository tasks पर उनका evaluation किया जाता है
    • अगर coding agents का ज़्यादा उपयोग करने वाली टीमों के सामने high vs xhigh, Codex vs Claude Code, AGENTS.md updates, या कौन से tasks सुरक्षित रूप से delegate किए जा सकते हैं जैसे ठोस निर्णय हैं, तो वे ऐसी टीमों की तलाश में हैं जो repository-specific trials साथ में चलाना चाहें
    • Stet, LLM subscription का उपयोग करके पूरी तरह local रूप से चलता है, और waitlist https://www.stet.sh/private पर है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 8 시간 전
Reddit की राय
  • यह तुलना अच्छी है और 5.4 के साथ तुलना भी देखना चाहूँगा
    अब तक के अनुभव के हिसाब से 5.5 अतिरिक्त लागत के लायक नहीं लगता। 5.4-high, 5.5 के ज़्यादातर reasoning चरणों से बेहतर करता है, लागत आधी है, और वास्तविक समय भी काफ़ी कम लगता है। 5.5-medium काम को अंत तक पूरा नहीं कर पाया, और 5.5-high ने overengineering करके bugs और regressions बना दिए
    • पिछले हफ्ते मैंने 5.4 high और 5.5 high की तुलना पर एक पोस्ट डाली थी: https://www.reddit.com/r/codex/comments/1t0xt5m/gpt55_vs_gpt54_vs_opus_47_on_56_real_coding_tasks/
      संक्षेप में, 5.5 में 5.4 की तुलना में थोड़ा सुधार हुआ है और कीमत भी थोड़ी बढ़ी है। token efficiency कुछ बेहतर लगती है, इसलिए यह अतिरिक्त input लागत को कुछ हद तक संतुलित करती दिखती है
    • डिफ़ॉल्ट रूप से मैं medium इस्तेमाल कर रहा हूँ
  • ज़्यादातर गंभीर काम के लिए high ठीक लगता है
    उससे ऊपर के स्तर पर मिलने वाला सुधार लागत के मुकाबले लगभग diminishing returns जैसा है
  • Pro अकाउंट पर मैं 5.5 xHigh Codex Terminal CLI को मुख्य lead के तौर पर और Codex Desktop App 5.5 xhigh को सहायक lead के तौर पर चला रहा हूँ
    दोनों को खतरनाक स्तर की full access दी हुई है और दोनों एक ही project पर काम करते हैं। हर एक के साथ औसतन 6 के करीब 5.5 sub-agents जुड़े रहते हैं, और CLI या app यह तय करता है कि किस स्तर के sub-agent इस्तेमाल होंगे। मिश्रण रहता है, लेकिन CLI आमतौर पर 5.5 Medium लगाता है
    CLI के पास admin अधिकार हैं और GitHub, Supabase, Vercel, Clerk, Linear, Symphony जैसी चीज़ों के साथ push, merge, PR, deploy जैसी कार्रवाइयाँ सिर्फ CLI संभालता है। मैं खुद कुछ नहीं करता, और P0/P1/P2 issues भी शून्य हैं। GitHub, Vercel, Supabase सब हरे हैं, कोई issue नहीं, code और product साफ़-सुथरे हैं, और सिर्फ एक reference image से frontend हैरान कर देने वाला निकल आता है
    कमी बस यह है कि यह दिन में साप्ताहिक सीमा का 30% जला सकता है
    • यह प्रयोग देखने के बाद मैंने कुछ कामों में xhigh आज़माया, और यह काफ़ी असरदार था, लेकिन tokens पागलों की तरह खर्च करता है
      अभी मैं फिर से high पर लौट आया हूँ
  • 5.5 xhigh को लेकर मेरी सबसे बड़ी शिकायत यह है कि यह पूछे बिना ही अपने आप काम आगे बढ़ा देता है
    इसकी वजह से ऐसा लगता है कि कुछ साल की उम्र और काफ़ी tokens बच गए
    • मैं ज़्यादातर high इस्तेमाल करता हूँ, और यह भी बिल्कुल ऐसा ही करता है
      मैं लगातार यह ढूँढ रहा हूँ कि agents.md में कौन-सी पंक्ति लिखूँ ताकि यह मनमानी assumptions न करे। कभी-कभी किसी चीज़ पर coding निर्देश देने से पहले इसे और जानकारी चाहिए होती है, इसलिए जब मैं सवाल पूछता हूँ तो जवाब देने के बजाय यह coding शुरू कर देता है। काम खत्म होने के बाद अपने response में सवाल का जवाब भी डाल देता है, लेकिन लगता है कि इसने मेरी बात पर ध्यान तो दिया, पर यह नहीं समझा कि अगर मैं सवाल पूछ रहा हूँ तो इसका मतलब है कि अभी coding शुरू नहीं करनी चाहिए
  • जानना चाहूँगा कि क्या आपने उसी PR पर कई बार run करके देखा है
    मैं समझना चाहता हूँ कि model के runs के बीच variability कितनी है। ऊपर वाले मामले में अगर high ने coding बेहतर की हो, फिर भी अगर runs के बीच variability बहुत ज़्यादा है तो xhigh इस्तेमाल करना बेहतर हो सकता है
    एक और प्रयोग के तौर पर, run के बाद काम के नतीजे पर feedback दिया जाए, फिर मानव द्वारा किए गए edits से तुलना करके AGENTS.md, skills, rules वगैरह को update कराया जाए, और उसके बाद fresh session में high/xhigh के साथ फिर चलाया जाए तो अच्छा होगा। इस प्रक्रिया को कुछ बार दोहराने के बाद अगर सभी effort levels पर फिर से प्रयोग किया जाए, तो AGENTS.md और skills/rules को ठीक से कसकर कुल output quality को ऊपर ले जाया जा सकता है
    • मैंने हर variant को कई बार run नहीं किया। मुख्य वजह लागत और token limits हैं। मेरी जेब अनंत नहीं है, लेकिन आगे के research के लिए यह अच्छा विचार है
      AGENTS.md optimization मुझे सच में बहुत पसंद आई, और असल में मैंने इसे Stet पर करवाया भी, जिसे मैंने experiments चलाने के लिए बनाया था। यह कुछ tasks पर Codex चलाता है, scores और failure patterns देखता है, फिर AGENTS.md को modify करके दोबारा run करता है—सब कुछ पूरी तरह autonomous तरीके से। यह AGENTS.md के लिए automated research की तरह काम करता है, और data-driven सुधारों को AGENTS.md में वापस आते देखना काफ़ी दिलचस्प है
  • अब तो कीमतों की inflation के लिए CPI index भी चाहिए। मासिक CPI लगभग 100% जैसा महसूस होता है