मैं यहाँ इस काम के चरण इसलिए लिख रहा हूँ कि ये मिलकर एक ऐसा तरीका बनाते हैं जिसे किसी दूसरे गेम और किसी दूसरे model के साथ दोहराया जा सकता है। आख़िर में मैं इसी ढाँचे पर बना दूसरा project दिखाता हूँ: Centurion: Defender of Rome का DOS से JavaScript में port। दोनों सीखने के लिए बनाए गए निजी projects हैं: मूल गेम, उनके graphics और उनका sound copyright के तहत ही हैं, और मैं इन्हें बाँटता नहीं हूँ।

Unity में title screen। तस्वीर गेम की मूल files से run time पर decode होती है।

Disk image से decompiled code तक

Agent ने शुरुआत files को पहचानने से की। Amiga की disk image (ADF) sectors की कच्ची नक़ल होती है, इसलिए उसके अंदर की चीज़ें निकालने के लिए Python की कुछ दर्जन lines काफ़ी थीं। गेम का program एक overlay executable निकला: उसका मुख्य हिस्सा memory में बना रहता है, और code के तीन और segments ज़रूरत पड़ने पर disk से पढ़े जाते हैं। Ghidra, जो एक मुफ़्त decompiler है, इस format को अपने आप नहीं समझता। Agent ने एक script लिखी जो सारे segments को एक ही image में तय addresses पर रखती है और overlays में जाने वाले 45 indirect jumps को सामान्य calls में बदल देती है। इसके बाद decompiler को करीब 630 functions एक ही program की तरह दिखे।

गेम के data में एक हैरानी छिपी थी। .rez extension वाली files की बनावट Macintosh resources जैसी है, क्योंकि Amiga वाला version ख़ुद Mac से किया गया port था। Format पहचान में आते ही agent ने 210 texts, strings की 82 lists, छह युगों के शहरों का data, तस्वीरें, animations, sprites और sounds निकाल लिए। Code का सबसे अच्छा नक्शा ये texts ही साबित हुए: "text दिखाओ" वाली routine को जो string number दिया जाता है, उसी से पता चल जाता है कि कोई function गेम की कौन-सी screen सँभालता है।

तेरह agents code पढ़ते हैं, नौ उसे दोबारा लिखते हैं

Decompiled code करीब 29 हज़ार lines का था, और उसमें functions या variables के कोई नाम नहीं थे। मुख्य agent ने उसे करीब 2 हज़ार lines के टुकड़ों में काटा और हर टुकड़ा एक अलग agent को एक ही लिखित brief के साथ दिया। हर agent को एक file लिखनी थी जिसमें उसके टुकड़े के हर function का ब्योरा हो: सटीक formulas, constants, random ranges, दिखाए जाने वाले texts के numbers, और पढ़े व लिखे जाने वाले global variables। Brief में एक वाक्य था जो आगे चलकर अहम साबित हुआ: ग़लत formula उस कमी से बदतर है जिस पर निशान लगा दिया गया हो। इसलिए agents को वह सब चिह्नित करना था जो वे तय नहीं कर पाए, और अस्पष्ट जगहों को assembly में जाँचना था। यहाँ decompiler ने functions के बहुत-से arguments खो दिए थे, क्योंकि 35 साल पुराना compiler 16-bit वाला int type इस्तेमाल करता था।

दूसरे चरण में भी बँटवारा वैसा ही था। नौ agents ने गेम के नियम C# में दोबारा लिखे, हर एक ने अपनी address range के लिए। इससे करीब 16 हज़ार lines का code बना, और गेम की state एक byte array में गई जिसे ठीक उसी तरह address किया जाता है जैसे मूल गेम की memory को। यह देखने में सुंदर नहीं लगता, लेकिन गलतियों की एक पूरी श्रेणी ख़त्म कर देता है। पुराना code structures को बेझिझक एक-दूसरे के ऊपर रख देता है और tables को उनकी शुरुआत से एक byte पहले से पढ़ लेता है। Memory image पर बने port को line दर line translate करके assembly से मिलाया जा सकता है, और constants की tables वहीं रहती हैं जहाँ code उन्हें ढूँढता है। Drawing, sound और controls की जगह एक interface के calls आ गए, जिसे engine अलग से implement करता है।

Oracle: processor emulator में मूल code

Decompiled code पढ़ लेने से यह साबित नहीं होता कि port मूल गेम जैसा ही बर्ताव करता है। इसलिए agent ने तुलना करने वाला एक tool बनाया। Motorola 68000 processor का मूल machine code Unicorn emulator में चलता है। System routines, यानी menus, text boxes, input पढ़ना और drawing, की जगह Python functions लगाए गए। ये functions गेम के हर सवाल का जवाब एक सीधे-सादे decision generator के हिसाब से देते हैं और गेम ने जो कुछ दिखाया उसे दर्ज करते जाते हैं। C# port को फ़ैसलों का ठीक वही क्रम एक "scripted player" के ज़रिए मिलता है, जो Unity के बाहर चलता है। आख़िर में दोनों records की line दर line तुलना होती है। Texts में सोना, crew की संख्या, तारीखें और शहरों के नाम होते हैं, इसलिए records का मेल खाना नियमों की एक मज़बूत परीक्षा है।

पहले पूरे माप में 802 में से 800 runs मेल खाए। दोनों गड़बड़ियों की वजह एक ही थी: floating-point arithmetic। गेम एक software library इस्तेमाल करता है जो आज के processors की तरह round नहीं करती। उसमें 81 का वर्गमूल 8.999999999999998 आता है, और गेम नतीजों को काटकर पूर्णांक बना देता है, इसलिए सोने और crew के कुछ अनुपातों पर port में crew का morale एक अंक ज़्यादा निकल रहा था। इलाज यह था कि library की routines को instruction दर instruction दोबारा लिखा जाए: 1,572 instructions, 43 routines, और मूल code से निकाले गए 21,701 test vectors, जिनमें कोई अंतर नहीं मिला। इस बदलाव के बाद सभी 802 runs मेल खाते हैं, और 120 अतिरिक्त runs में duel, समुद्री सफ़र और समुद्र व ज़मीन की लड़ाइयों में गेम की state को frame दर frame मिलाया गया।

तुलना से 1990 के मूल गेम के दो bugs भी सामने आए: किसी शहर पर तिरछी दिशा से हमला करते समय null pointer के ज़रिए नक्शे को पढ़ना, और crew के शून्य हो जाने पर शून्य से भाग। ऐसी जगहों पर port को कोई एक बर्ताव चुनना पड़ता है, और तुलना वाले tool में एक switch है जो मूल code को भी उसी रास्ते पर चला देता है। नतीजे की सीमाएँ भी हैं। Tool न drawing की तुलना करता है, न sound की, और शादी, पूरा किया गया ख़ज़ाने का नक्शा या सबसे ऊँचे ranks जैसे दुर्लभ रास्ते बहुत कम परखे गए।

Presentation और वे चीज़ें जो 1990 में नहीं थीं

जो layer खिलाड़ी को दिखती है, वह Unity में code से बनाई गई, बने-बनाए scenes के बिना। तस्वीरें और animations मूल resources से decode होते हैं, sprites अपने रंग मौजूदा screen की palette से लेते हैं, और music को गेम के चार-channel वाले sequencer को emulate करके audio files में render किया गया। Agent चलते हुए गेम को command line से चलाता था, screenshots लेता था और उन्हें देखता था। इससे कई ऐसी खामियाँ पकड़ में आईं जिन्हें नियमों का कोई test नहीं पकड़ता, जैसे browser version में sound का न होना, क्योंकि audio conversion के लिए ffmpeg program चाहिए था और वह install नहीं था।

नक्शे पर समुद्री सफ़र। Background 160 गुणा 200 cells की terrain grid और मूल tiles से बना है।

पहली बार खेलने के बाद मैंने तीन बदलाव करवाए। ख़ज़ाने वाले बेड़े के पहुँचने की तारीख वाला सवाल मूल गेम का copy protection था और उसके लिए छपा हुआ manual चाहिए था; अब quiz बनी हुई है, लेकिन सही जवाब "कप्तान के notes" में दिखता है। शहरों की list सिर्फ़ शहर का data दिखाती थी, क्योंकि गेम मानकर चलता था कि खिलाड़ी के पास छपा हुआ नक्शा है; अब चुना हुआ शहर Caribbean के chart पर चिह्नित होता है। Duel screen को दोनों पक्षों की force, morale और weapon वाली एक table मिली, जिसका layout मूल गेम जैसा है। इन additions को बंद किया जा सकता है, और तुलना वाले tests इनके बिना चलते हैं, इसलिए records अब भी 1990 के code से मेल खाते हैं।

मूल गेम में duel। Screenshot का स्रोत: OpenRetro Game Database।

वही screen port में। Table के आँकड़े duel की state से live पढ़े जाते हैं।

मूल गेम में जोड़ी गई चीज़: Caribbean के chart पर चुना हुआ शहर।

Centurion: वही ढाँचा JavaScript में, बढ़ाए गए gameplay के साथ

दूसरा project है Centurion: Defender of Rome, 1990 का एक DOS गेम, जिसे बिना किसी emulator के JavaScript और Canvas element पर लाया गया। चरण वही थे, बस नाम अलग थे। Executable को पहले unpack करना पड़ा, क्योंकि वह EXEPACK tool से compress किया गया था। गेम के पाँच modules (ज़मीनी लड़ाई, gladiator arena, रथ दौड़, नौसैनिक लड़ाई और intro) एक overlay file में थे और एक ही data segment साझा करते थे। Campaign की state उस segment के 64 kilobytes की एक जीवित copy पर चलती है, क्योंकि गेम का engine 16-bit overflow, integer division और signed bytes पर टिका है, जिन्हें JavaScript के floating-point numbers अपने आप नहीं दोहराते। Save किया हुआ गेम मूल format से byte दर byte मेल खाता है, और tests इसकी जाँच करते हैं।

Browser में Centurion की title screen, मूल graphics के साथ।

यहाँ मैं हूबहू port से आगे गया। मैंने बढ़ाए गए नियमों के लिए एक switch जोड़ा, जो default रूप से बंद रहता है: legions को मिलाना और एक province में कई legions, हल्के velites, युद्ध के हाथी और समुद्र से landing। इस port का code Pirates वाले models से अलग models ने लिखा: ज़्यादातर Gemini 3.8 Flash ने, और कुछ हिस्सा Codex के ज़रिए चलाए गए OpenAI के gpt-6.1-sol ने। यह चुनाव उन tools से तय हुआ जो मेरे पास मौजूद थे, models की किसी तुलना से नहीं।

Options menu। पहली entry उन बढ़ाए गए नियमों को चालू करती है जो मूल गेम में नहीं थे।

Games के menu के साथ province की screen।

Centurion में Gemini को किन दिक्कतों का सामना करना पड़ा

ज़्यादातर समय उन जगहों पर गया जहाँ decompiled code या files के नाम कुछ और इशारा करते थे और गेम असल में कुछ और करता था। Project के notes से पाँच उदाहरण:

• बिना data के overlays। गेम के पाँचों modules एक ही file, OVL0.OVL, में रहते हैं और एक ही address पर load होते हैं, लेकिन सभी एक साझा data segment इस्तेमाल करते हैं। इसलिए किसी overlay का code अकेले Ghidra में खोलने पर न strings दिखती थीं, न tables। एक script ने हर overlay को data segment के साथ जोड़कर पाँच synthetic executables बनाए, और तभी जाकर decompiler ने minigames के code को campaign के structures से जोड़ा।
• जीते हुए provinces की सीमाएँ। Mouse से click होने वाले regions के नक्शे से province की रूपरेखा खींचने पर दाँतेदार रेखाएँ बनती थीं, जो हाथ से बने नक्शे पर ठीक नहीं बैठती थीं। Code में एक अलग ही तरीका निकला: नक्शे की तस्वीर में हर province का गहरे रंग का, एक pixel चौड़ा छिपा हुआ path है, और data की एक table 27 provinces में से हर एक के लिए एक शुरुआती बिंदु देती है। गेम उस path को शुरुआती बिंदु से शुरू करके साम्राज्य के रंग में दोबारा रंग देता है, और port भी यही करता है।
• पीछे की ओर खिसकते frames। मूल game loop 9–12 Hz पर चलता था, जबकि browser एक second में 60 बार draw करता है। तीन जगहों पर sprite एक पल के लिए एक frame पीछे चला जाता था। Intro वाला globe 10 steps में palette के 14 रंग खिसकाकर घूमता है, लेकिन table में पहले step का मान शून्य है; हर step पर palette खिसकाने से महाद्वीप हर चक्कर में एक बार झटका खाते थे। Marching करती cohorts और gladiators के वारों में क्रम को हूबहू दोहराना पड़ा: पहले बीच वाला frame, फिर स्थिति का बदलाव।
• भ्रामक file names। BB1.CBM और BB2.CBM bitmaps लड़ाई के banners जैसे लगते थे, और screen के ऊपरी हिस्से में draw करने पर पूरे युद्धक्षेत्र को ढक लेते थे। Code इन्हें तभी load करता है जब computer में VGA card न हो: ये पुराने EGA और CGA cards के लिए पूरी screen वाले backgrounds हैं। इसी routine से यह भी पता चला कि लड़ाई से पहले की तैनाती के दो चरण होते हैं। Formation चुनने पर उपलब्ध tactics की list बदल जाती है, और Cannae वाला दाँव wedge चुनने के बाद ही दिखता है।
• मुश्किल से सुनाई देने वाला music। AdLib sound card के driver के 17 tracks और 24 instruments decode करने के बाद धुनें सही थीं, लेकिन करीब −55 dB पर बज रही थीं। Driver को disassemble करने पर पता चला कि वह हर note पर, instrument में दर्ज attenuation में से note की velocity का एक चौथाई हिस्सा घटाता है। Code की एक line ने करीब 32 dB वापस ला दिए। दूसरी खामी browser की तरफ़ थी: बहुत छोटे notes पर Web Audio API में पहले से schedule किए गए volume changes को रद्द करने से वह attack भी मिट जाता था जो अभी चल ही रहा था, और note चुप हो जाता था।

लड़ाई से पहले तैनाती का दूसरा चरण: wedge formation के लिए उपलब्ध tactics।

Circus Maximus की रथ दौड़ अपने आप में एक अलग काम थी। वहाँ रथ कोई एक तस्वीर नहीं है। रथ की तीन classes, सारथी के चार रंग, चार actions, मोड़ में झुकाव के सोलह कोण और सरपट दौड़ के तीन frames, इन सबके हर मेल के लिए अलग bitmap रखने का मतलब होता 2,300 से ज़्यादा frames, इसलिए गेम बनाने वालों ने memory में 16-byte वाले nodes का एक tree बनाया। हर node उसी level के अगले element की ओर और अपने पहले child की ओर इशारा करता है, और उसमें एक frame index, animation के एक के बाद एक आने वाले frames के offsets की table, और visibility का एक flag होता है। Root चार घोड़े हैं। रथ के hull में एक अतिरिक्त horizontal offset है, जिसमें मोड़ काटने की physics 0 से 15 pixels का झुकाव लिखती है, और सारथी उसका child है, इसलिए उसे वही स्थिति विरासत में मिलती है। यही वजह है कि मोड़ पर सारथी hull के साथ झुकता है, जबकि घोड़े track की धुरी पर ही दौड़ते रहते हैं। टूटते axle और लुढ़कते मलबे वाली शाखाएँ हर समय मौजूद रहती हैं; बस उनका visibility flag बंद रहता है।

गेम के data से दोबारा तैयार किया गया रथ का sprite tree। Diagram इसी project में मूल, decode किए गए resources से बनाया गया।

Track भी tiles से नहीं बना है। गेम coordinates के 72 stored जोड़ों को फैलाकर 368 control points बनाता है और track की चौड़ाई में स्थिति को 16 lanes में बाँटता है। Lane से मोड़ की सुरक्षित speed तय होती है, जिसका हिसाब (lane number + 15) × 4 से लगता है: अंदरूनी दीवार के पास यह 60 है, बाहरी barrier के पास 116–120। अंदर वाली lane सबसे छोटा रास्ता है, लेकिन इस सीमा से ऊपर की speed पर hairpin में घुसने से hull झुक जाता है, रथ बाहर की ओर धकेला जाता है और crash के लिए पासा फेंका जाता है; सीमा जितनी ज़्यादा लाँघी जाए, crash की संभावना उतनी बढ़ती जाती है। Speed bar पर लाल marker खिलाड़ी को यही सीमा दिखाता है।

Track के 368 points और lane के हिसाब से मोड़ की सुरक्षित speed।

Games के अलावा इस काम से क्या बचा

मैंने इस तरीके को एक skill के रूप में लिख लिया है, यानी निर्देशों का ऐसा set जिसे agent मिलता-जुलता काम मिलने पर load कर लेता है। इसमें दोनों projects से निकले तीन सिद्धांत हैं। गेम के नियम हूबहू port किए जाते हैं, और presentation की जगह एक interface आता है। Port मूल गेम का memory layout बनाए रखता है। नतीजे पर तब तक भरोसा नहीं किया जाता जब तक वह मूल code के साथ तुलना में पास न हो जाए। Skill में analysis और porting करने वाले agents के briefs और Pirates project की scripts भी शामिल हैं।

सबसे दिलचस्प नतीजा agents के बारे में नहीं, fans के बारे में है। जिसके पास कोई पसंदीदा गेम है और जिसे उसमें बरसों से किसी चीज़ की कमी खलती रही है, वह आज source code के बिना, जल्दी और कम ख़र्च में उसे अपने हिसाब से बदल सकता है। Pirates में जिस quiz के लिए छपा हुआ manual चाहिए था, वह अब ख़ुद जवाब बता देता है, और एक नक्शा जुड़ गया जो गेम में कभी था ही नहीं। Centurion में मैंने वे नियम जोड़े जो original में नहीं थे: legions को मिलाना, जंगी हाथी और समुद्र से उतरना। जब गेम के नियम C# या JavaScript का आम code बन जाते हैं, तो अगला बदलाव code का एक आम बदलाव होता है, binary को patch करना नहीं। इसी तरह गेम को किसी तेज़ engine या दूसरे platform पर भी ले जाया जा सकता है: Centurion browser में चलता है, और Pirates Linux और browser के लिए build होता है। यह तरीक़ा सिर्फ़ पुराने गेम तक सीमित भी नहीं है। Decompiler, processor emulator और records की तुलना किसी नए program पर भी वैसे ही काम करते हैं; ज़्यादा code का मतलब ज़्यादा काम है, कोई अलग तरीक़ा नहीं।

स्रोत

• दोनों projects की मेरी अपनी सामग्री: code analysis के notes, agents के लिए briefs, तुलना वाले tool की report (802 runs, मिले हुए अंतरों की list), और specifications के साथ Centurion port का विवरण। ये प्रकाशित नहीं हैं।
• National Security Agency, Ghidra, reverse engineering का वह suite जिससे दोनों गेम decompile किए गए।
• Unicorn Engine, वह processor emulator जिसमें मूल 68000 code चलाया गया।
• OpenRetro Game Database, Amiga पर Pirates! का page, मूल गेम के screenshot का स्रोत।

लेकिन इस व्याख्या के लिए यह जाँचना ज़रूरी है कि इंसान का लंबा काम सचमुच AI के लिए उसी हिसाब से कठिन task है या नहीं। अगर किसी दायरे में tasks agent के लिए लगभग बराबर कठिन हैं, तो उसकी सफलता में मामूली सुधार भी नतीजे को मिनटों के बड़े दायरे के पार खिसका सकता है।

तब agent चुनते समय हमें एक और जानकारी चाहिए: उन्हीं tasks को पूरा करने की संभावना कितनी बदली। अगर हम benchmark के ठीक उस हिस्से की तुलना कर रहे हों जहाँ समय कठिनाई में कम फ़र्क़ करता है, तो समय का multiplier अकेले versions के बीच के अंतर को बढ़ा-चढ़ाकर दिखा सकता है।

METR ऐसे माप को time horizon कहता है। 50% threshold वाले रूप में यह इंसान के काम का वह समय है जिस पर fit किया गया curve अनुमान लगाता है कि agent की आधी कोशिशें सफल होंगी। यह किसी तय समय वाले tasks का औसत है, उनमें से हर एक के लिए गारंटी नहीं। यहाँ हम ख़ुद AI के चलने का समय नहीं नापते।

Preprint On the estimation and validity of AI time horizons—a statistical look at the METR plot में Drew T. Nguyen और William Fithian समय को कठिनाई में बदलने के इसी रूपांतरण का विश्लेषण करते हैं। AI evaluation और statistics के क्षेत्र का यह पेपर पहली बार 8 अक्टूबर 2026 को प्रकाशित हुआ। यह METR के data में इंसान के काम के 2 से 30 मिनट के बीच एक लगभग सपाट हिस्सा दिखाता है। इस दायरे के tasks, जाँचे गए agents के लिए, औसतन लगभग बराबर कठिन थे।

संभावना में छोटा बदलाव threshold को दूर तक खिसका सकता है

नीचे का उदाहरण समझाने के लिए किया गया मेरा अपना सरलीकरण है, किसी शोध का नतीजा नहीं। हमारे पास तीन tasks हैं: A, B और C, जिनमें इंसान को क्रमशः 3, 10 और 30 मिनट लगते हैं। दोनों agents में से हर एक, हर task को एक ही environment में 100 बार करता है। हम सफलता या असफलता दर्ज करते हैं।

बात साफ़ रखने के लिए इन आवृत्तियों को ठीक-ठीक मालूम संभावनाएँ मान लेते हैं और बिंदुओं को घटते हुए curves से जोड़ देते हैं। पुराना agent 50% को 3 मिनट पर काटता है, नया 30 मिनट पर। Horizon दस गुना बढ़ जाता है, जबकि हर task पर सफलता सिर्फ़ 2 percentage points बढ़ी। हर agent की 300 कोशिशों में सफलताओं की संख्या 147 से 153 हुई।

तीनों tasks और सारी असफलताएँ माप में बनी रहती हैं। हम सिर्फ़ वह जगह चुनते हैं जहाँ curve threshold को काटता है; न कुछ छाँटते हैं, न किसी चीज़ को इनाम देते हैं। इस काल्पनिक test की लागत agent की 600 पूरी कोशिशें है। असली प्रयोग में इतनी संख्याओं के आधार पर 2 percentage points के अंतर को पक्का नहीं माना जा सकता। Curve fit करना पड़ता है और अनिश्चितता का अनुमान लगाना पड़ता है।

यह उदाहरण दिखाता है कि लगभग सपाट curve से horizon कैसे पढ़ा जाता है। शोध में उसकी शक्ल पहले बहुत-से tasks और systems से तय करनी पड़ती है। अगर किसी दूसरे दायरे में curve कहीं तेज़ी से गिरता है, तो horizon के उसी multiplier के लिए सफलता की संभावना में ज़्यादा बढ़ोतरी चाहिए। इसीलिए 3 से 30 मिनट तक का और 30 मिनट से 5 घंटे तक का सफ़र परिभाषा से ही तरक़्क़ी के बराबर हिस्से नहीं हैं।

इंसान के समय को AI के लिए कठिनाई से मिलाना पड़ता है

शुरुआती बिंदु नतीजों की तालिका है: किस agent ने कौन-सा task किया, कितनी बार और किस नतीजे के साथ। हमें इंसान का समय और task का परिवार भी मालूम है। हमें ऐसी कोई एक वस्तुनिष्ठ संख्या मालूम नहीं जो AI के लिए उसकी कठिनाई बताए।

लेखकों का baseline मानता है कि इंसान के समय का हर अगला दोगुना होना कठिनाई को एक जैसे क़दम से बढ़ाता है। वह सभी agents के लिए curves का एक साझा slope इस्तेमाल करता है; agents आपस में क्षमता के स्तर में अलग होते हैं। यह हर system के लिए अलग regression से, जो शुरू में इस्तेमाल होता था, ज़्यादा मज़बूत संदर्भ बिंदु है।

पहला प्रस्ताव तय क़दम की जगह data से सीखा गया, monotonic, spline क़िस्म का curve रखता है: आसानी से जुड़े हुए टुकड़े, जो तेज़ या धीमे बढ़ सकते हैं। लंबा समय अब भी अनुमानित कठिनाई को घटाता नहीं, लेकिन बढ़ोतरी का एक समान होना ज़रूरी नहीं।

दूसरा प्रस्ताव, जिसे पेपर में Model 2 कहा गया है, item response theory, IRT का इस्तेमाल करता है। यह सफलताओं और असफलताओं के pattern से agents की क्षमता और tasks की कठिनाई का एक साथ अनुमान लगाता है। यह एक ही परिवार के tasks की समानता और कोशिशों के नतीजों के अतिरिक्त बिखराव को भी ध्यान में रखता है। इससे एक ही agent–task जोड़े की कई दोहराई गई कोशिशों को पूरे benchmark के बारे में उतनी ही नई, स्वतंत्र जानकारियाँ नहीं मान लिया जाता।

पहला क़दम जिसमें baseline और नए तरीके अलग होते हैं, इंसान के समय को कठिनाई में बदलना है। Agents के input नतीजे वही रहते हैं। यानी नई fit, AI का एक भी जवाब बदले बिना, horizon को बदल सकती है।

GPT-4o के उन्हीं नतीजों से अलग horizon निकला

लेखक METR Time Horizon 1.1 के दर्ज नतीजों का दोबारा विश्लेषण करते हैं: 228 tasks और 26 AI systems। चित्र 1 में GPT-4o का horizon साझा slope वाले baseline के हिसाब से 7.2 मिनट है और Model 2 के हिसाब से 4.4 मिनट। ये उन्हीं कोशिशों से निकले दो अनुमान हैं; न यह GPT-4o के काम में गिरावट है, न उसके inference की लागत की तुलना।

ज़्यादा लचीला curve बस noise पर बेहतर fit हो सकता था। इसलिए लेखक tasks के उन पूरे परिवारों पर नतीजों के अनुमान को जाँचते हैं जो fit में इस्तेमाल नहीं हुए। पाँच हिस्सों वाले validation में वे 79 परिवारों को बाँटते हैं, एक ही task की अलग-अलग कोशिशों को नहीं। Measure और नतीजों को weight देने के तरीके के सभी 12 मेलों में दोनों नए तरीकों के point estimates बेहतर हैं। इसका मतलब सफलता के अनुमान में कम ग़लती है, ख़ुद agents की सफलता में बढ़ोतरी नहीं। §2.4–2.5 और चित्र 2

यह बढ़त बराबर नहीं बँटती। Fit सबसे ज़्यादा GPT-4 के दौर के systems के लिए सुधरती है, जिनके horizons बताए गए सपाट दायरे से होकर गुज़रते हैं। सबसे ताक़तवर systems के लिए तुलना किए गए curves लगभग एक-दूसरे पर आ जाते हैं। अलग-अलग systems के अनुमान भी कुल नतीजे के मुकाबले कहीं कम निर्णायक हैं। परिशिष्ट A

लंबे tasks के लिए scale को दोबारा जाँचना ज़रूरी है

पेपर सपाट हिस्से की वजह तय नहीं करता और यह नहीं दिखाता कि वह हर benchmark में दिखेगा। वह यह भी साबित नहीं करता कि METR के tasks programmer के पूरे काम का प्रतिनिधित्व करते हैं। लेखक तरक़्क़ी के देखे गए exponential trend पर सवाल नहीं उठाते; वे यह जाँचते हैं कि इंसान के काम के समय वाले axis पर फ़ासलों का क्या मतलब है।

व्यावहारिक उपयोग यह है कि horizon के साथ tasks के तय दायरों के लिए सफलता की संभावना का chart भी रखा जाए। इससे दिखता है कि horizon की छलाँग भरोसेमंदी में किसी साफ़ बदलाव से मेल खाती है या नहीं। अपने benchmark में लंबे tasks जोड़ते समय, अब तक के curve को आगे बढ़ाने से पहले, अलग रखे गए परिवारों पर यह जाँच लेना ठीक रहेगा कि उनका समय अब भी agent के लिए कठिनाई का अनुमान देता है या नहीं।

स्रोत

• Drew T. Nguyen, William Fithian, On the estimation and validity of AI time horizons—a statistical look at the METR plot, preprint, 2026, v1। arXiv:2610.12466; DOI: 10.48550/arXiv.2610.12466। पूरा पाठ।
• METR, Task-Completion Time Horizons of Frontier AI Models, माप की परिभाषा, evaluation की प्रक्रिया और सीमाएँ। Page पर लिखा है कि chart अब सक्रिय रूप से update नहीं किया जाता।

उनके माप के मुताबिक, agents के काम में tokens के जो अनुपात उन्होंने माने हैं, उन पर Opus 5.5 वाला Claude, API की दरों के हिसाब से, GPT-6.1 Sol वाली OpenAI की तुलना में रखी गई subscriptions से करीब पाँच गुना ज़्यादा मूल्य देता है। यह उपलब्ध इस्तेमाल का माप है; काम पूरा करने में models कितने कारगर हैं, इसकी तुलना यहाँ नहीं की गई।

लेख यह भी दिखाता है कि OpenAI के नए Pro 200 में tokens का कोटा आधा कर देने का क्या असर पड़ा, और एक पकड़े गए A/B test का ब्योरा देता है, जिसमें एक account की limits करीब 20% कम थीं। यानी subscription का मूल्य इस पर भी निर्भर करता है कि usage गिनने के नियम कैसे बदलते रहते हैं।

बिचौलिया सेवाओं की अंतिम तुलना सिर्फ़ paid subscribers के लिए उपलब्ध है।