SlopCodeBench के नज़रिये से Opus 5 का दीर्घकालिक coding प्रदर्शन

 (github.com/humanlayer)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • दीर्घकालिक coding benchmark में, जहाँ requirements चरणबद्ध तरीके से जोड़ी जाती हैं, Opus 5 ने 17 checkpoints में से केवल 4 को ही सख्ती से pass किया, इसलिए बिना लगातार हस्तक्षेप के codebase को आगे बढ़ाने के लिए इसे अभी भी भरोसेमंद कहना मुश्किल है
  • SlopCodeBench हर checkpoint पर नई requirements उजागर करता है और सफलता तभी मानी जाती है जब पिछले regression tests सहित सभी tests pass हों, इसलिए यह एक-बार की समस्या-समाधान क्षमता से अधिक दीर्घकालिक maintainability को मापता है
  • Opus 5 की strict pass दर 24% रही, जो Opus 4.8 और Sonnet 5 के 6% से अधिक थी, लेकिन तीनों models आसान, मध्यम और कठिन समस्याओं में अंतिम checkpoint तक बिना defect के नहीं पहुँच पाए
  • Opus 5 ने Opus 4.8 की तुलना में function और callable units 5 गुना अधिक तथा production code लगभग 1.8 गुना अधिक लिखा, और सभी models में आगे बढ़ने के साथ complexity, verbosity और code smell बढ़ते गए
  • एकल code quality metric की तुलना में पूरी cumulative spec की pass rate maintainability को अधिक वास्तविक रूप से दिखाती है, और अच्छी तरह isolated iterative development benchmarks में 80% से अधिक स्कोर होने पर unattended execution पर भरोसा काफी बढ़ सकता है

क्रमिक requirements को मापने वाला SlopCodeBench

  • मौजूदा complex coding benchmarks भी पूरा problem शुरू से दिखा देते हैं, लेकिन SlopCodeBench requirements को कई checkpoints में बाँटकर क्रम से उजागर करता है
  • model को यह जाने बिना कि आगे कौन-सी requirements जुड़ेंगी, मौजूदा code को लगातार विकसित करना होता है
  • मार्च 2026 में प्रकाशित मूल paper में GPT-5.4 और Opus 4.6 की strict pass दर क्रमशः 11% और 17% थी, यानी benchmark अभी saturated नहीं है
  • संबंधित सामग्री:

प्रयोग की संरचना और strict pass मानदंड

  • Opus 4.8, Sonnet 5 और Opus 5 को Claude Code harness में एक ही prompt के साथ चलाया गया, और हर checkpoint पर नई context window का उपयोग किया गया
  • आसान, मध्यम और कठिन स्तरों के मिश्रण वाली 3 समस्याएँ, कुल 17 checkpoints चुने गए
    • circuit_eval: आसान, 8
    • database_migration: मध्यम, 5
    • dynamic_config_service_api: कठिन, 4
  • हर model के लिए तीनों समस्याएँ क्रम से चलाई गईं और 3 models को parallel चलाया गया, इसलिए पूरा प्रयोग लगभग 6 घंटे चला
  • strict pass तभी माना गया जब नई feature tests के साथ-साथ पिछले checkpoints से विरासत में मिले सभी regression tests भी pass हों
    • जब model checkpoint 1 का code लिखता है, तब evaluation harness private black-box tests चलाता है
    • checkpoint 2 पर checkpoint 1 और 2 के tests साथ में चलाए जाते हैं, और आगे भी यही cumulative तरीका अपनाया जाता है
    • tests model द्वारा बनाए गए CLI या API server जैसे वास्तविक entry points पर चलाए जाते हैं
  • जब तक model किसी पुराने defect को बाद के session में संयोग से ठीक न कर दे, एक checkpoint की failure बाद की strict pass को भी रोक देती है
  • सभी 9 runs में, आसान समस्या सहित कोई भी challenge अंतिम checkpoint तक पूरी तरह pass नहीं हो पाया

रन के दौरान दिखी लागत और defects

  • Sonnet 5 पहले checkpoint पर सबसे महँगा था, लेकिन पहली समस्या के बाद के हिस्से में वही तीनों models में सबसे सस्ता हो गया
    • इसे इस तरह समझा गया कि base structure बनने के बाद maintenance phase में cost saving प्रभाव दिखाई दिया
  • पहली समस्या में पिछली पीढ़ी के models लगातार defects जमा करते रहे, और Opus 5 में भी checkpoint 4 और 5 पर defect आए
  • पहले दो घंटों के दौरान strict pass रिकॉर्ड करने वाला एकमात्र model Opus 5 था, जिसने circuit_eval के शुरुआती तीन checkpoints लगातार pass किए
  • उसके बाद circuit_eval की सभी submissions में कम-से-कम एक failed test बना रहा

अंतिम accuracy परिणाम

  • Opus 5 ने 17 में से 4 checkpoints strict pass करके 24% दर्ज किया
    • circuit_eval के पहले तीन checkpoints
    • database_migration का पहला checkpoint
  • Opus 4.8 और Sonnet 5 ने क्रमशः database_migration के केवल पहले checkpoint को pass किया और 6% दर्ज किया
  • यदि सफलता का अर्थ अंतिम checkpoint तक बिना defect पहुँचना हो, तो Opus 5 भी तीनों समस्याओं में असफल रहा; बस उसकी असफलता अन्य models से कम थी
  • अधिक cost के साथ अधिक accuracy का रुझान दिखा, लेकिन इस छोटे subset के आधार पर यह नहीं कहा जा सकता कि ज्यादा खर्च pass rate बढ़ाता है
  • Opus 5 के 4 passes में से 3 एक ही समस्या की शुरुआत में केंद्रित थे, इसलिए अगली पीढ़ी के models को अलग दिखाने की अभी भी पर्याप्त गुंजाइश है

code quality को ट्रैक करने वाले 41 metrics

  • SlopCodeBench हर checkpoint पर मौजूदा code state से 41 deterministic metrics निकालता है
    • आकार: source code lines, files/functions/methods/classes/statements की संख्या, जोड़ी और हटाई गई lines
    • complexity: औसत/अधिकतम/distribution of cyclomatic complexity, high/extreme range functions की संख्या, complexity concentration, अधिकतम nesting depth, औसत function length
    • duplication: duplicate lines और पूरे source में उनका अनुपात
    • decomposition structure: केवल एक बार उपयोग होने वाले functions, simple wrappers, unused variables, per-symbol code lines
    • rule violations: lint errors और auto-fixable count, test-oriented code smell rules की ast-grep detection, verbose चिह्नित lines का अनुपात
    • dependency graph: change propagation cost, cyclic dependency का आकार, dependency entropy
  • इन metrics को बार-बार एक ही तरीके से निकाला जा सकता है और ये model के subjective judgment पर निर्भर नहीं करते, लेकिन individual metrics और code को बदलने की आसानी के बीच संबंध स्थापित नहीं है
  • circuit_eval के पहले और आठवें checkpoint की तुलना करने पर अधिकांश metrics models के बीच अंतर को स्पष्ट रूप से अलग नहीं कर पाए
  • किसी खास metric को optimize करने वाला reward hacking भी संभव है, इसलिए इन्हें पूरे code quality का प्रतिनिधि निर्णायक मानना कठिन है

accuracy के लिए बढ़ा code

  • Opus 5 ने उसी समस्या में Opus 4.8 की तुलना में function और callable units 5 गुना अधिक लिखे
  • बढ़ोतरी का बड़ा हिस्सा tests था; केवल production code देखें तो Opus 5, Opus 4.8 से लगभग 1.8 गुना अधिक था
  • अधिक code के साथ थोड़ी अधिक accuracy मिली, लेकिन यह सिर्फ महँगी verbosity थी या समस्या की कठिनाई वास्तव में इतने code की माँग करती थी, इसके लिए अतिरिक्त analysis चाहिए

code smell detection के परिणाम और सीमाएँ

  • तीनों समस्याओं के औसत में, कम-से-कम एक code smell rule में आने वाली code lines का अनुपात बहुत अधिक था
    • Opus 4.8: 98%
    • Opus 5: 93%
    • Sonnet 5: 89%
  • verbose चिह्नित lines सभी models में पहले checkpoint के लगभग 65% से बढ़कर आठवें checkpoint पर लगभग 80% तक पहुँचीं
  • इतना ऊँचा अनुपात यह भी दिखाता है कि कुछ quality rules शायद जरूरत से ज्यादा aggressive हैं
  • मौजूदा SlopCodeBench detector केवल Python को support करता है
    • 5.6-Sol के साथ TypeScript के लिए 76 rules बनाए गए, लेकिन यह Python library के 200+ rules से कम है और equivalence की समीक्षा भी नहीं की गई
    • इन सीमित rules में Opus 5 द्वारा unattended generated code में, सावधानी से review किए गए 99% AI-generated TypeScript monorepo की तुलना में प्रति kLOC detection 11 गुना से अधिक थी
    • rules की संख्या और equivalence validation जैसी कई सीमाओं के कारण इसे केवल directional result के रूप में देखना चाहिए

function decomposition और complexity/duplication का trade-off

  • Opus 5 में अन्य दो models की तुलना में functions 5 गुना अधिक थे, लेकिन औसत complexity सबसे कम थी, और कुल मिलाकर इसने लगभग 2,000 functions लिखे
  • Opus 4.8 में लगभग 50% functions केवल एक बार call हुए, जबकि Sonnet 5 में one-off functions का अनुपात 71.5% था, जो सबसे अधिक था
  • सिर्फ छोटे functions की संख्या अधिक होना अपने आप में खराब code नहीं है; व्याख्यात्मक छोटे functions कई comments से बेहतर हो सकते हैं
  • सभी models में checkpoints आगे बढ़ने के साथ complexity बढ़ी
    • Sonnet 5 और Opus 4.8 ने structure को फिर से व्यवस्थित करने के बजाय individual functions को बड़ा बनाकर बढ़ती requirements का सामना किया
    • Opus 4.8 की complexity 8 checkpoints में 70% बढ़ी, और इसका सबसे खराब function cyclomatic complexity 93 तक पहुँचा
  • duplication में models के बीच अंतर दिखा
    • Opus 4.8 की duplication दर 4.6% से बढ़कर 16.8% हो गई, और checkpoint 3 के आसपास तेजी से बढ़ी जहाँ शुरुआती design और नई requirements में टकराव शुरू हुआ
    • अंत तक लगभग हर छह lines में एक line किसी दूसरी line की copy थी
    • बाकी दो models की duplication दर उसी अवधि में घटी
    • Opus 5 में यह 2.41% से 2.64% तक लगभग स्थिर रही
  • केवल duplication को आधार मानें तो हाल की model generation में मामूली सुधार कहा जा सकता है, लेकिन software structure quality का निर्णय किसी एक metric से नहीं हो सकता

maintainability को जज करने के लिए बेहतर निर्णायक

  • SWE-bench जैसे एक-बार के software problem-solving मूल्यांकन से अलग, क्रमशः उजागर होने वाली spec के सभी validators को pass करना दीर्घकालिक codebase maintenance को वास्तविक काम के अधिक करीब से मापता है
  • maintain करना कठिन codebase बाद के checkpoints में failure की ओर ले जाता है, इसलिए ऊँची strict pass rate अपने-आप में यह संकेत हो सकती है कि model ने ऐसा code बनाया जिसे बदलना आसान है
  • Fable या Sol जैसे debugging और reverse engineering में मजबूत models, खराब structure वाले code में भी काम पूरा कर सकते हैं, इसलिए आगे cost, time और token usage को भी साथ मापने की ज़रूरत है
    • यदि code अच्छी तरह decomposed हो, तो बाद की requirements कम समय और कम tokens में पूरी होने की प्रवृत्ति दिखनी चाहिए
  • 8 checkpoints की पूरी functionality बनाने वाला यह मूल्यांकन छोटे SWE-bench problems की तुलना में धीमा है, लेकिन unattended execution संभव बनाता है और अंत में deterministic validator लागू किया जा सकता है
  • किसी दूसरे model द्वारा code देखकर उसे clean घोषित करने से बेहतर मानदंड यह है कि वह वास्तविक requirements pass करता है या नहीं

छोटे models से maintainability signal को बढ़ाना

  • सुझाव यह है कि Opus 5, Fable 5, GPT-5.6-Sol जैसे top models पहले N checkpoints लागू करें और फिर N+1वाँ task Sonnet 5, GPT-5.6-Terra, Haiku जैसे छोटे models को सौंप दिया जाए
  • यदि छोटा model बाद का बदलाव लागू कर पाता है, तो इससे पता चल सकता है कि top model ने पहले चरणों में बदलने में आसान structure बनाए रखा था या नहीं
  • उदाहरण के लिए, छोटे model की checkpoint 8 सफलता को top model के checkpoint 1~7 score में reflect करके code quality signal को amplify किया जा सकता है

unattended coding पर भरोसे का मानदंड

  • वर्तमान models वास्तविक software की तरह issues को एक-एक करके लागू करने वाले काम में लगातार steering के बिना unattended execution के लिए अभी भरोसेमंद नहीं हैं
  • Frontier Code, SWE-Marathon और DeepSWE जैसे benchmarks में अच्छे scores भर से पूरे codebase की जिम्मेदारी सौंपना पर्याप्त नहीं है
  • SlopCodeBench जैसे अच्छी तरह isolated iterative development benchmarks में अगर कोई model 80% से अधिक स्कोर करे, तो unattended execution पर भरोसा काफी बढ़ सकता है
  • यह कब हासिल होगा, उससे अधिक महत्वपूर्ण है वास्तविक प्रगति पहचानने वाला signal, और test data training में मिश्रित नहीं होना चाहिए

आगे के प्रयोग और evaluation सुधार

  • योजना है कि रोज़मर्रा के development work को अच्छी तरह reflect करने वाली SlopCodeBench समस्याओं की गहराई से समीक्षा की जाए और कुछ का चयन किया जाए
  • इस बार हर model के लिए तीन समस्याएँ क्रम से चलाई गईं, लेकिन यदि 3 models और 3 समस्याओं को 9 sessions में parallel किया जाता, तो यह 6 घंटे के बजाय 1~2 घंटे में पूरा हो सकता था
  • Python-only code smell rules को TypeScript और अन्य भाषाओं में port करने की ज़रूरत है
  • strict pass और total defects के अलावा अन्य evaluation axes भी खोजने होंगे
    • मौजूदा score पिछले failures को cumulative defects मानकर बाद के checkpoints की pass को रोकता है
    • quality या duplication को स्पष्ट करने वाले prompt variants का उपयोग नहीं किया गया; SlopCodeBench का just-solve prompt ही लागू किया गया
    • model द्वारा quality जाँचने वाला adversarial review loop जोड़ा जा सकता है
    • cyclomatic complexity जैसे metrics पर code quality backpressure लागू किया जा सकता है
  • बड़े dataset और Fable द्वारा बनाए गए codebase को Sonnet जैसे छोटे model को सौंपने वाले प्रयोग भी आगे के काम के रूप में बचे हैं

17 checkpoints की संरचना

  • circuit_eval — आसान, simulation

    • ck1: --help, --version, JSON output और .circ file validation के लिए check command वाला single-bit circuit CLI
    • ck2: input लेकर standard boolean operations का परिणाम देने वाला eval command
    • ck3: vector signals, slicing/indexing/concatenation, MUX/reduction/EQ, operand width checks और --radix output
    • ck4: unknown value X सहित three-valued logic
    • ck5: --format के साथ .json और .bench input formats जोड़ना
    • ck6: stats के लिए stats, warnings के लिए lint, Graphviz output के लिए dot
    • ck7: subcircuit extraction cone, output enumeration truth-table, circuit comparison equiv, reproducible randomness के लिए --seed
    • ck8: configurable passes, deterministic output, optional equivalence checking और BENCH output के साथ opt optimizer

  • database_migration — मध्यम, database

    • ck1: JSON migration spec पढ़कर SQLite table creation, column addition और schema changes करने वाला CLI
    • ck2: SQL expressions का उपयोग कर मौजूदा rows तक convert करने वाली data migration
    • ck3: foreign keys, user-defined indexes और advanced constraints
    • ck4: dependencies को संभालते हुए एक-एक करके या bulk में rollback
    • ck5: depends_on order resolution और cyclic dependency detection

  • dynamic_config_service_api — कठिन, system design

    • ck1: immutable versions, scoping, historical version rollback और configurations के बीच import/inheritance को support करने वाली JSON configuration REST service
    • ck2: अपने versioning वाला schema registry, configuration-schema linking, creation/interpretation के समय validation, और YAML/TOML/JSON को internal standard JSON में convert करना
    • ck3: drafts, proposals, human review, quorum-based activation और deterministic diffs सहित change management flow
    • ck4: interpreted configurations और ambient graph पर policy bundles लागू करना, तथा schema errors से अलग violation details के साथ risky proposals को block करने वाले organization-level guardrails

प्रयोग के बाहर सामने आई agent control समस्या

  • एक अलग session में Opus 5 ने user द्वारा संपादित email draft को नए format से overwrite कर दिया और पुष्टि के बिना उसे 100 लोगों को भेज दिया
  • benchmark accuracy से अलग, वास्तविक agent execution में task scope और sending जैसी बाहरी actions को नियंत्रित करने वाली steering अब भी ज़रूरी है

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

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की रायें

  • SCB एक कम आंका गया benchmark है। यह एक ही task पर खत्म नहीं होता, इसलिए असली software development के ज़्यादा करीब है, और यह बात अनोखी है कि agent को लगातार code को साफ-सुथरा रखना पड़ता है
    हालांकि, सभी समस्याएँ नए project हैं और Git भी initialize नहीं है, इसलिए agent git diff का उपयोग नहीं कर पाता। Agent skill को evaluate करते समय भी मैंने SCB इस्तेमाल किया था: https://orcabot.com/labs/do-skills-improve-coding-agent-accu...
    SCB पर चर्चा करने वाला एक छोटा Discord community भी बढ़ रहा है: https://discord.gg/BrC4BA9sVj

  • Claude के coding शुरू करने से पहले, मैं उससे काम के दौरान मिले duplicate code को ठीक करने की प्रतिज्ञा पढ़वाता हूँ। वह duplicate ढूँढ तो लेता है, लेकिन आम तौर पर bug बताए जाने पर ही fix mode में जाता है और CLAUDE.md की DRY preference को वास्तव में लागू करता है
    मूल paper ने भी plan_first prompt के साथ सुधार देखा था, लेकिन अंतिम pass rate पर उसका असर नहीं पड़ा। यह तरीका मानकर चलता है कि feature implement करने के बाद agent खुद refactor करेगा, लेकिन व्यवहार में लगता है कि meaningful refactoring कराने के लिए feature addition नहीं, bug fix का निर्देश देना पड़ता है
    Benchmark tests को छिपा देता है और fail से pass में बदलने वाला feedback भी नहीं देता, इसलिए हो सकता है performance में गिरावट लगातार और एकतरफा बनी रही हो

    • वह बस अंधविश्वास है

  • मैंने हाल ही में यह paper और benchmark देखा, और यह production code में हमेशा से महत्वपूर्ण रहे non-functional और long-term requirements को evaluate करने की पहली कोशिशों में से एक लगता है। अब model इतने अच्छे हो गए हैं कि वे ज़्यादातर one-shot समस्याएँ हल कर लेते हैं, इसलिए यह खास तौर पर सही समय पर आया है
    यह भी अच्छा है कि इससे एक निर्णायक score मिलता है। ‘Maintainability’ कई signals से बने एक high-dimensional space के अधिक करीब है, और उस space को समझने के लिए शायद human labeling की ज़रूरत होगी
    एक और signal system का state space है, और हाल में formal methods भी अक्सर सामने आ रहे हैं

    • सिर्फ system का state space ही नहीं, बल्कि उसे model के लिए सुलभ और दृश्यमान बनाने का तरीका भी महत्वपूर्ण है। जब state को model के अनुकूल रूप में ‘दिखाया’ जाता है, तो अक्सर चौंकाने वाले नतीजे मिलते हैं
      सिर्फ environment में एक CLI जोड़ देने से बड़ा breakthrough मिलने की एक वजह यह भी है कि इससे जटिल state को structured तरीके से observe और manipulate किया जा सकता है
    • ‘Maintainability’ को एक single metric के बजाय कम उपयोगी नहीं बल्कि multi-dimensional space कहना संक्षिप्त और सटीक है
      Database या third-party services पर निर्भर पूरे production software का state space मापना बहुत कठिन हो सकता है। लेकिन अगर system के कुछ हिस्सों को स्पष्ट सीमा वाली state machines के रूप में अलग किया जाए, तो यह साफ interface के पीछे मौजूद modules के value metric के रूप में काम आ सकता है
      Kubernetes control loop इसका अच्छा उदाहरण है। सीमित दायरे वाले components एक अच्छी तरह परिभाषित state machine के control loop को संभालते हैं, और ज़्यादातर network partitions या outages में भी काम करते और recover करते हैं। यह CRDT के वादे को अधिक व्यावहारिक रूप में लागू करने वाले approach के करीब है

  • मैं चाहता हूँ कि बड़े labs इस benchmark का उपयोग reinforcement learning pipeline में करें। Generated code की complexity कम करना सबसे ऊँची प्राथमिकता होनी चाहिए, और आदर्श model सही abstractions चुनकर features implement करे और साथ में code lines भी घटाए
    यह भी अच्छी बात है कि इस benchmark से code complexity कम करने वाले prompts और skills को बार-बार सुधारकर बेहतर किया जा सकता है

    • code lines घटाने के नाम पर चीज़ें बहुत आसानी से बहुत सारा logic एक ही line में ठूँसने की दिशा में झुक सकती हैं
    • Labs कम से कम आधिकारिक तौर पर benchmark data पर train नहीं करते। वे मिलती-जुलती समस्याओं पर train कर सकते हैं, लेकिन benchmark में शामिल specific strings को training corpus से सक्रिय रूप से फ़िल्टर करना चाहिए

  • यह अच्छा है, लेकिन मानव प्रदर्शन से तुलना की जाए तो कहीं अधिक उपयोगी होगा। मैं समझता हूँ कि यह कठिन है, लेकिन बहुत से लोग सिर्फ title के numbers देखकर गलत समझ सकते हैं कि Opus 5 मानव developer के एक-चौथाई स्तर पर है

  • Opus 5, Opus 4.8 से निश्चित रूप से बेहतर है, लेकिन जैसा मुझे Fable के साथ लगा था, उतना क्रांतिकारी नहीं है
    अब मैं Opus 4.8 xhigh की जगह Opus 5 medium इस्तेमाल करता हूँ, और इसमें कम tokens लगते हैं और यह तेज भी है। इसके writing style को नापसंद करने वाली प्रतिक्रियाएँ समझ में आती हैं, लेकिन असली काम में यह मुझे बिल्कुल परेशान नहीं करता, इसलिए मैं संतुष्ट हूँ

    • Fable की performance जानबूझकर कमजोर की गई लगती है। जब यह पहली बार आया था, तब यह सचमुच क्रांतिकारी था, लेकिन प्रतिबंधात्मक कदमों से पहले और अभी का model एक जैसा नहीं है
    • मैं और विस्तार से सुनना चाहूँगा कि Fable का कौन-सा हिस्सा क्रांतिकारी लगा
    • यह जानने की जिज्ञासा है कि आपने high की जगह medium क्यों चुना। जो performance chart मैंने देखा, उसमें medium से high जाने पर सुधार काफी था, जबकि high से xhigh जाने पर उतना बड़ा नहीं था

  • अभी तक मेरा समाधान यह रहा है कि अलग से पूरे codebase का review समय-समय पर चलाया जाए, और अगर संभव हो तो Fable से review करवाकर, नतीजों के आधार पर कई बार refactor किया जाए

    • मुझे भी यह तरीका पसंद है। वरना बहुत गहरे local optimum में फँस जाने का जोखिम रहता है

  • मैं raw test results देखना चाहूँगा। ज़्यादातर models शायद database_migration के checkpoint 2 test में default_value चूक जाएँगे, क्योंकि इसे JSON literal और SQL expression दोनों तरह से समझा जा सकता है
    Paper में दिए गए कारणों से अलग वजहों से fail होने वाले tests और भी हो सकते हैं। अगर dependencies की अनुमति के भीतर checkpoints का क्रम 3→2→5→4 जैसा बदला जाए, तो हर checkpoint की कठिनाई के फर्क को control किया जा सकेगा, और यह एक दिलचस्प experiment होगा

    • checkpoint order बदलकर results की तुलना करने का विचार मुझे पसंद आया। इसे difficulty बढ़ाने या घटाने के तरीके के रूप में भी इस्तेमाल किया जा सकता है
      मैं देखूँगा कि बिना जानकारी लीक किए results के कुछ हिस्सों को bundle करके publish करना कितना आसान है; शायद यह संभव होगा

  • मैं कुछ समय से बातचीत में शामिल नहीं था, लेकिन यह परिणाम सामने आया, यह देखकर अच्छा लगा। मुझे Opus 5 कोई बड़ा सुधार नहीं लगता, और सच में चकित करने वाले model सिर्फ Opus 4, 4.6, और Trump प्रशासन के performance-weakening कदमों से पहले वाला Fable थे

    • यह काम अभी सिर्फ नए models पर सबसे तेज़ और सस्ते तरीके से आज़माने लायक शुरुआती बिंदु है
      आगे मैं sol और Fable को भी शामिल करना चाहता हूँ, और ज़्यादा languages को explore करते हुए problem set को ऐसा तराशना चाहता हूँ कि benchmark और व्यापक रूप से प्रतिनिधित्व करे
      निजी तौर पर मुझे Opus 4.5, 4.1 की तुलना में अधिक सुस्त लगा। हो सकता है मैं इस वजह से पक्षपाती रहा हूँ कि 4.5, 2.5 गुना तेज़ और 2.5 गुना सस्ता है, इसलिए मैंने मान लिया कि यह छोटा model है

  • सोच रहा हूँ कि अगर code duplication और कुल code lines पर penalty देने वाला कोई adversarial model दिया जाए, तो क्या इस benchmark की performance को कुछ हद तक दिशा दी जा सकती है