- Realaus pasaulio bandymuose su sudėtingomis stebimumo problemomis GPT-5 ir GPT-5.1 Codex buvo vieninteliai modeliai, kurie pateikė integruotą, kompiliuojamą kodą, paruoštą diegti gamyboje.
- „Claude Code“ pasižymėjo architektūra ir išsamia dokumentacija, tačiau jos sprendimai apėmė kritines klaidas ir nebuvo integruoti į esamą projektavimo procesą, todėl reikėjo atlikti vėlesnį rankinį darbą.
- „GPT-5.1 Codex“ patobulino „GPT-5“ greičio, architektūrinio švarumo ir žetonų efektyvumo požiūriu, todėl tai pačiai užduočiai atlikti sprendimas buvo žymiai pigesnis nei „Claude“.
- „GPT-5.1-Codex-Max“ prideda glaudinimo ir gilaus samprotavimo režimus, todėl tai yra agentų variklis, galintis valandų valandas dirbti didelėse saugyklose neprarandant sekų.
Jei dienas leidžiate programuodami, tikriausiai pastebėjote tikrą dirbtinio intelekto programavimo įrankių laviną pastaruoju metu : GPT-5.1 Codex, GPT-5 Codex, Claude Code, Kimi K2 Thinking, Sonnet 4.5, Haiku... Sąrašas auga beveik kas savaitę, ir kiekvienas tiekėjas teigia turintis geriausią kūrimo asistentą. Tačiau kai imatės prie bazinių įrankių ir juos naudojate realiuose projektuose, skirtumai tampa akivaizdūs.
Pastarosiomis savaitėmis kelios komandos lygino GPT-5.1 kodeksą, GPT-5 kodeksą, Claude'o kodą ir Kimi K2 mąstymą griežtomis sąlygomis: didelės saugyklos, integracija su realaus pasaulio vamzdynais, apkrovos testavimas ir sudėtingos stebimumo problemos. Čia nėra jokių supaprastintų programavimo kata, o veikiau klaidos ir funkcijos, kurios gali sutrikdyti gamybą, jei joms nepasiseks. Remiantis visais šiais duomenimis, iškyla gana įtikinama žinia: „OpenAI“ kodeksai, o ypač GPT-5.1 kodeksas, pateikia daugiausiai „iš tikrųjų diegiamą kodą“.
GPT-5.1 kodeksas prieš Klodo kodeksą: trumpa dvikovos apžvalga
Kai kas nors kalba apie „GPT-5.1 Codex ir Claude Code etaloną“, iš tikrųjų lyginamos dvi gana skirtingos kodo valdymo filosofijos . GPT-5.1 Codex (ir jo evoliucija – GPT-5.1-Codex-Max) nuo pat pradžių buvo sukurtas kaip variklis agentams, kurie ilgas valandas dirba toje pačioje saugykloje: jis supranta kontekstą, redaguoja failus, atlieka testus ir taiso savo klaidas. Kita vertus, Claude Code puikiai paaiškina kodą, kuria architektūras ir generuoja dokumentaciją, tačiau jam dažnai nepavyksta iš tikrųjų integruoti pakeitimų į esamą kodų bazę.
Realiuose bandymuose su stebimumo projektais šis skirtumas buvo aiškiai matomas: „Codex“ modeliai buvo vieninteliai, kurie generavo integruotą ir gamybai paruoštą kodą , o Claude'as ir Kimi kūrė įspūdingas architektūras, kūrybingas idėjas ir daugybę eilučių... bet su kritinėmis klaidomis, integracijos nesėkmėmis ar tiesiog kodu, kuris net nebuvo kompiliuojamas.
Kaip buvo atliktas lyginamasis testas: tikros problemos, o ne žaislai
Kad etalonas būtų prasmingas, buvo visiškai išvengta tipinio pratimo „parašyti funkciją, kuri apverčia eilutę“. Vietoj to, stebimumo platformoje buvo pasirinkti du sudėtingi iššūkiai , turintys labai konkrečius našumo ir patikimumo reikalavimus bei laikantis geros testavimo ir diegimo praktikos programinės įrangos inžinerijoje :
Pirmasis iššūkis: sukurti ir įdiegti statistinę anomalijų aptikimo sistemą , gebančią išmokti bazinius klaidų dažnius, apskaičiuoti z balus ir slenkamuosius vidurkius, aptikti pokyčių greičio smailes ir apdoroti daugiau nei 100 000 žurnalų per minutę su mažesniu nei 10 ms delsos laiku. Visa tai turi būti integruota į esamą srautą.
Antras iššūkis: išspręsti paskirstytą įspėjimų deduplikaciją, kai keli procesoriai beveik vienu metu aptinka tą pačią anomaliją. Reikėjo išvengti dublikatų, tarp kurių būtų mažiau nei 5 sekundžių, toleruoti iki 3 sekundžių trukmės laikrodžio vėlavimus ir valdyti procesoriaus gedimus neužšaldant sistemos.
Keturi išbandyti modeliai – GPT-5 Codex, GPT-5.1 Codex, Claude Code ir Kimi K2 Thinking – gavo tuos pačius raginimus toje pačioje IDE (žymeklyje) ir toje pačioje saugykloje. Buvo matuojamas sugaištas laikas, sunaudoti žetonai, kaina doleriais, kodo kokybė, kritinių klaidų skaičius ir, svarbiausia, ar rezultatas buvo tikrai susijęs su esama kodo baze, ar liko „lygiagrečiu prototipu“.
1 bandymo rezultatai: statistinis anomalijų aptikimas
Pirmojo bandymo tikslas buvo, kad kiekvienas modelis pateiktų gamybai paruoštas statistinis anomalijų detektorius: dažnio skaičiavimai, slankiojantys langai, z balai, pokyčių šuoliai, kruopštus dalybos iš nulio apdorojimas ir integravimas į klasę AnomalyDetector ir tikrame vamzdyne.
Klodas Kodas Jis buvo paleistas su trenksmu: tūkstančiai naujų kodo eilučių, išsami dokumentacija, keli statistiniai mechanizmai (z balas, EWMA, valiutos kurso patikrinimai) ir net sintetiniai etalonai. Teoriškai tai skambėjo kaip vadovėlinė inžinerija. Tačiau paleidus kodą, pasirodė kita pusė: valiutos kurso funkcija, kuri grąžino Infinity kai ankstesnis langas buvo nulis, o tada toFixed() apie tą vertę, kuri sukėlė Tiesioginė diapazono klaidaBe to, bazinė sistema nebuvo visiškai riedanti, o testai buvo nedeterministiniai (naudojant Math.random()Ir visa tai vainikuoja Niekas iš to nebuvo prijungtas prie tikrojo vamzdynoRezultatas: įspūdingas prototipas, bet tokio, koks yra, neįmanoma pradėti gaminti.
Bandymas GPT-5 kodeksas Tai buvo daug pragmatiškiau. Maždaug per 18 minučių tai sugeneravo gerai integruotas kodas, kurio grynieji pakeitimai sudaro tik kelis šimtus eilučių, tiesiai ant klasės AnomalyDetector ir tikruosius įėjimo taškus. Jie pasirūpino kraštutiniais atvejais (pavyzdžiui, Number.POSITIVE_INFINITY prieš skambinant toFixed()), įdiegė inkrementinę statistiką slenkančiuose languose su O(1) sudėtingumu ir suderino laiko intervalus su sieniniu laikrodžiu, kad būtų užtikrintas nuspėjamumas. Vieneto testavimas Jie buvo deterministiniai, o rezultatas sistemoje veikė beveik neliesdamas nieko kito.
Dėl GPT-5.1 kodeksasJis pasirinko dar švaresnį architektūrinį požiūrį. Vietoj laikinų kibirų jis naudojo pavyzdžius atitinkančius riedėjimo langus su priekinės/uodegos rodyklėmis ir specialia klase. RollingWindowStats atlikti sumas ir kvadratų sumas. Jis kruopščiai kontroliavo dalybą iš nulio, naudodamas tokias konstantas kaip MIN_RATE_CHANGE_BASE_RATE, apribojo bazinio atnaujinimo dažnumą, kad taupytų išteklius, ir rašė deterministinius testus su kontroliuojamomis laiko žymomis. Per 11 minučių jis sukūrė daugiau grynojo srauto linijų nei GPT-5, tačiau pasižymėjo paprastesne architektūra, geresniu atminties valdymu ir ta pačia „diegimui paruošta“ kokybe..
Ketvirtasis žaidėjas, Kimi K2 Thinking , pasirinko kūrybišką sprendimą, kuris apjungė srautinio žurnalo palaikymą ir paketines metrikas, pridėdamas aptikimus pagal MAD ir EMA. Teoriškai tai neatrodė blogai, tačiau esmė buvo sugedusi: prieš vertinant kiekvieną reikšmę buvo atnaujinama bazinė vertė, todėl z balas artėjo prie nulio, o anomalijos praktiškai niekada nebuvo suaktyvinamos . Be to, „TypeScript“ kalboje atsirado kompiliavimo klaida ir pasikartojo ta pati dalybos iš nulio problema kaip ir Claude'o atveju. Dar blogiau, kodas net nebuvo kompiliuojamas ir nebuvo tinkamai susietas su sistema.
Šio pirmojo etapo išvada gana aiški: du kodeksai (GPT-5 ir GPT-5.1) buvo vieninteliai, kurie pateikė funkcionalų, integruotą ir pakankamai patikimą kodą . GPT-5.1 kaina atitiko Claude kainą (apie 0,39 USD šiame teste), bet per trumpesnį laiką ir su švaresne architektūra.
2-ojo bandymo rezultatai: paskirstytų įspėjimų deduplikacija
Antrasis iššūkis iškėlė klasikinę paskirstyto koordinavimo problemą : keli procesoriai galėjo aptikti tą pačią anomaliją beveik vienu metu. Reikėjo užkirsti kelią pasikartojantiems įspėjimams, kai jie aptinkami per 5 sekundžių laikotarpį, tuo pačiu toleruojant tam tikrą laikrodžio desinchronizaciją ir galimus procesų gedimus.
Klodas vėl sužibėjo dizaino srityje. Jis pasiūlė trijų lygių architektūra: L1 talpykla, duomenų bazės patariamieji užraktai kaip L2 ir unikalūs apribojimai kaip L3. Buvo naudojamas NOW() iš duomenų bazės, kad nebūtų priklausoma nuo procesoriaus laikrodžių, ji gerai susitvarkė su užrakto atrakinimu nutrūkus ryšiui ir pateikė beveik 500 testų eilučių, apimančių konfliktų, laikrodžio iškraipymų ir gedimų scenarijus. Tačiau, kaip ir pirmajame teste, Prie tikrojo procesoriaus niekas nebuvo prijungta, o kai kurios įgyvendinimo detalės (pvz., pernelyg stori užrakto raktai arba visiems aktyviems įspėjimams taikomas laiko langas) sumažino praktinį naudingumą.
Lygiagrečiai, GPT-5 kodeksas Jis pasirinko sprendimą, pagrįstą deduplikacijos lentele su rezervacijomis ir galiojimo pabaiga, koordinuojama per operacijas ir FOR UPDATE. Kodas jis buvo tiesiogiai integruotas į processAlertJis naudojo serverio laiką ir gana gerai susidorojo su susidūrimais, nors sąlygoje buvo nedidelė lenktynių konkurencija. ON CONFLICT kuris ekstremaliomis sąlygomis galėjo leisti dviem procesoriams praeiti tą patį patikrinimą prieš patvirtinant. Tai nebuvo tobula, bet labai artima tam, ką būtų galima įdiegti atlikus nedidelį pakeitimą.
Persikėlimas GPT-5.1 kodeksas Jis buvo dar minimalistiškesnis ir efektyvesnis: vietoj papildomų lentų jis rėmėsi PostgreSQL konsultavimo spynos su funkcija acquireAdvisoryLock kuris sugeneravo raktus naudodamas SHA-256 poroje service:alertTypeUžrakintame lange patikrinama, ar per 5 sekundžių laikotarpį yra aktyvių įspėjimų, o jei ne, įterpiama nauja. Jei panašus įspėjimas jau egzistavo, atnaujinamas jo svarba, jei naujasis įspėjimas yra svarbesnis. Visa tai atliekama naudojant... nuoseklus serverio laiko žymų naudojimas iškraipymams valdyti ir tinkamai išvalyti blokai finallyRezultatas: paprastesnė logika, be pagalbinių lentelių ir be lenktynių, kurias užsitęsė GPT-5.
Šiame bandyme kimi Taip, jam pavyko integruoti savo logiką į processAlert ir naudoti atskirus 5 sekundžių intervalus su atominiais įterpimais ir pakartotiniais bandymais su atgaline data. Pati idėja nebuvo bloga, tačiau įgyvendinimas vėl nepavyko dėl svarbių detalių: kai du vienu metu atlikti įterpimai turėjo tą patį createdAtvėliavos skaičiavimas isDuplicate Jis buvo atšaukiamas, o įspėjimai buvo neteisingai pažymėti; be to, užklausoje net nebuvo taikomas kaupiklio perskaičiavimas atidėjimo metu, todėl Jie vis bandė išspręsti tą patį konfliktąTrumpai tariant, gera intuicija, prastas įgyvendinimas.
Vėlgi, šiame antrajame etape išskleidžiamą kodą sukūrė GPT-5 ir GPT-5.1 Codex , o GPT-5.1 turėjo aiškų pranašumą dėl švaros ir lenktynių sąlygų nebuvimo, o visa tai kainavo apie 0,37 USD, palyginti su 0,60 USD GPT-5.
Kainos: kodėl „Codex“ yra pigesnis nei „Claude“
Jei žiūrėtumėte tik į kainą už milijoną žetonų, galėtumėte manyti, kad „Claude Sonnet 4.5“ ir „GPT-5.1“ yra toje pačioje lygoje. Tačiau, atidžiau panagrinėjus šių etalonų skaičius, tampa aišku, kad „Codex“ siūlo daugiau už mažesnę kainą . Abiejuose testuose kartu išlaidos buvo maždaug tokios:
- Klodas: iš viso apie 1,68 USD.
- GPT-5 kodeksas: apie 0,95 USD (43 % pigiau nei Claude).
- GPT-5.1 kodeksas: maždaug 0,76 USD (maždaug 55 % mažiau nei Claude'o).
- kimi: Apytiksliai 0,51 USD, tačiau dėl sąnaudų suskirstymo trūkumo yra daug netikrumo.
Svarbiausia, kad „Claude“ už išvesties žetoną ima daugiau (15 USD/M, palyginti su 10 USD/M GPT-5.1) ir, be to, dėl savo „mąstyk garsiai“ stiliaus ir išsamios dokumentacijos linkęs generuoti daug papildomo teksto. Kita vertus, „Codex“ naudoja konteksto kaupimą savo komandinėje eilutėje (CLI), pakartotinai panaudodama didelius įvesties žetonų kiekius, jų dar kartą neapmokestindama viso mokesčio. Pridėkite prie to tai, kad GPT-5.1 buvo efektyvesnis pagal naudojamų žetonų skaičių nei GPT-5, ir rezultatas yra vedlys, kuris ne tik generuoja daugiau tinkamo naudoti kodo, bet ir taupo jūsų pinigus.
Fiksuotos kainos planų, tokių kaip „20 eurų per mėnesį“, pasaulyje tai reiškia kažką labai apčiuopiamo: su „Codex“ galite dirbti su kodu daug ilgiau, kol pasieksite ribą . Tuo tarpu su „Claude“ planais gana dažnai pažengę vartotojai pasiekia ribą net ir turėdami brangiausias prenumeratas, o su „Codex Pro“ retai kas ją viršija, išskyrus atvejus, kai naudojamasi itin intensyviai.
Ką siūlo GPT-5.1-Codex-Max: agentai, dirbantys visą dieną
Virš GPT-5.1 Codex yra variantas, specialiai sukurtas labai ilgam ir detaliam kodo bazės darbui : GPT-5.1-Codex-Max. Šis modelis nėra skirtas „bendriniams pokalbiams“, o veikiau yra skirtas veikti kaip agento variklis Codex ekosistemoje ir OpenAI Codex CLI . Didžiulių saugyklų skaitymas, daugybės failų modifikavimas, testų rinkinių vykdymas ir kontrolės išlaikymas valandų valandas yra jo DNR dalis.
Pagrindinis skirtumas yra suspaudimas . Užuot pasikliavęs vien didžiuliu kontekstiniu langu, modelis gali apibendrinti ir suspausti senesnes sesijos dalis, išlaikydamas svarbias detales. Tai tarsi „suspaudžia“ jau atliktus veiksmus, kad atsirastų vietos naujoms komandoms, nepamirštant svarbių sprendimų. Dėl to jis gali dirbti su didžiulėmis monorepozitorijomis, vienu metu sąveikauti su keliomis paslaugomis ir vis tiek atsiminti prieš daugelį valandų priimtus dizaino sprendimus.
Kitas įdomus aspektas – samprotavimo lygiai . „Vidutinis“ režimas tinka kasdienėms užduotims (įprastiems bilietams, mažoms funkcijoms, nedideliems pertvarkymams) su gera delsa. „xHigh“ režimas suteikia modeliui daugiau vidinio skaičiavimo laiko ir ilgesnius mąstymo procesus, aukodamas greitį dėl didesnio patikimumo sudėtingose problemose: masyviuose pertvarkymuose, senuose vamzdynuose, kuriuose gausu spąstų, sunkiai atkuriamose lenktynėse ir pan. Toms užduotims, kurios paprastai užtruktų visą popietę vyresniajam kūrėjui, šis režimas tai kompensuoja.
Agentams skirtuose etaloniniuose testuose „GPT-5.1-Codex-Max“ gerokai patobulina standartinį „GPT-5.1 Codex“: daugiau užduočių atliekama „SWE-bench Verified“ ir „Lancer“, geresnis našumas „Terminal Bench“ ir, svarbiausia, didesnis gebėjimas išlaikyti ramybę ilgų sesijų metu nenukrypstant nuo temos. Daugeliui komandų šis skirtumas reiškia, kad agentas gali tvarkyti visą užklausą nuo pradžios iki galo, o ne tik retkarčiais generuoti pataisas.
Saugumas, smėlio dėžės testas ir atsakingas modelio naudojimas
Kai suteikiate agentui prieigą prie savo terminalo ir saugyklos, normalu, kad kyla su saugumu susijusių problemų. „Codex“ ir „GPT-5.1-Codex-Max“ sukurti taip, kad visada veiktų „ smėlio dėžės“ aplinkoje . Debesyje agentas veikia konteineryje, kuriame pagal numatytuosius nustatymus išjungtas tinklas, o siunčiamas srautas leidžiamas tik tuo atveju, jei jis aiškiai įjungtas. Vietoje to, jis naudoja „macOS“, „Linux“ arba „Windows“ (arba WSL) „smėlio dėžės“ mechanizmus, kad apribotų, prie kurių failų jis gali prisijungti.
Visose „Codex“ platformose galioja dvi taisyklės: tinklas neatsidaro, nebent jūs jam nurodote , ir agentas negali redaguoti failų už sukonfigūruotos darbo srities ribų. Tai, kartu su specialiais mokymais, siekiant išvengti žalingų komandų, padidina tikimybę, kad modelis apdairiai išvalys katalogą, nei ištrins pusę projekto, neteisingai interpretuodamas tokią frazę kaip „išvalyti tai“.
Kalbant apie greito įpurškimo atakas (pavyzdžiui, kenkėjišką tekstą, kuriuo bandoma apgauti dirbtinį intelektą (DI), kad jis ignoruotų jo taisykles ir nutekintų paslaptis), „Codex“ mokymuose pabrėžiama, kad visas išorinis tekstas turi būti laikomas nepatikimu, o tai patvirtina automatinio DI modelių testavimo praktika . Praktiškai tai reiškia, kad atmetami duomenų nutekėjimo prašymai, atsisakoma įkelti privatų kodą į išorines svetaines ir pirmenybė teikiama sistemos ir kūrėjo instrukcijoms, o ne bet kokiai informacijai, pateiktai dokumentuose ar tinklalapiuose.
GPT-5.1 kodeksas, palyginti su Claude ir kitais kasdien naudojamais modeliais
Peržiūrėjus konkrečius „Codex-Max“ etalonus ir galimybes, bendras vaizdas tampa gana aiškus: kiekvienas modelis turi savo idealią nišą , ir protinga neapsiriboti vienu modeliu viskam, bet žinoti, kada naudoti kiekvieną įrankį.
GPT-5.1 kodeksas (ir jo „Max“ variantas) ypač tinka, kai reikia integruoto kodo, atsižvelgiant į periferinių juostų apsaugą ir mažą klaidų tikimybę . Abiejuose stebimumo testuose jis, kartu su GPT-5, buvo vienintelis, pateikęs įgyvendinimus, kuriuos buvo galima įdiegti gamyboje neperrašant pusės failo. Be to, užduoties kaina buvo mažiausia iš visų, efektyvumas padidėjo, palyginti su GPT-5, o kainos ir kokybės santykis buvo sunkiai įveikiamas.
„Claude Sonnet 4.5“ / „Claude Code“ sužiba, kai reikia architektūrinio projekto, išsamios dokumentacijos ir aiškių paaiškinimų . Pagalvokite apie architektūros apžvalgas, išsamius techninius dokumentus, perkėlimo vadovus... Jų sprendimai paprastai būna labai gerai pagrįsti ir gerai paaiškinti, su gynybos sluoksniais ir kompromisų analize, kurią malonu skaityti. Kaina, kurią reikia mokėti: prototipai, kuriuos vėliau reikia prijungti rankiniu būdu, daugiau kritinių klaidų nei iš pradžių matyti, ir žymiai didesnė kaina už žetoną.
„Kimi K2 Thinking“ pasižymi dideliu kūrybiškumu ir alternatyviais metodais . Eksperimentuose buvo išbandytos įdomios idėjos, pavyzdžiui, langai, naudojantys laikinus segmentus deduplikacijai arba MAD ir EMA maišymas anomalijų aptikimui. Be to, jos komandinė eilutės sąsaja (CLI) yra nebrangi, nors ir šiek tiek neišvystyta. Problema ta, kad ji dažnai stringa pagrindinėse logikos detalėse: statistikos atnaujinimo tvarkoje, dalyboje iš nulio, apverstuose žymėjimuose ir kt. Tai puikiai tinka įkvėpimui, tačiau reikia skirti daug laiko tobulinant ir testuojant tai, ką ji sukuria.
Galiausiai, bendrieji GPT-5.1 modeliai (momentinis ir mąstantis) ir tokie modeliai kaip „Gemini“ ar „Llama“ yra mišrių užduočių (dokumentacijos, duomenų analizės, vartotojo sąveikos) pagrindas , tačiau kai užduotis yra grynai pagrįsta kodu ir agentais, „Codex“ paketas šiuo metu siūlo gana sunkiai prilygstantį gylio, kainos ir įrankių derinį .
Žvelgiant į viską kartu – du stebimumo etalonus, ilgalaikį naudojimą IDE, tokiose kaip „VS Code“ ir „Cursor“, „Codex-Max“ kompaktiškumą, samprotavimo režimus ir kainų skirtumus – bendras įspūdis gana aiškus: kalbant apie „DI, kuris iš tikrųjų programuoja ir pateikia tinkamas „pull request“ užklausas“, GPT-5.1 „Codex“ užsitarnavo savo vietą kaip pagrindinė priemonė . „Claude Code“ išlieka puikiu architektūrinio planavimo ir išsamios dokumentacijos rengimo partneriu, o „Kimi“ ar panašūs modeliai siūlo kibirkštį ir alternatyvas, tačiau kai reikia sukurti kodą, kuris kompiliuojasi, integruojasi ir neužstringa iš pirmo karto, „Codex“ pusė paprastai galiausiai laimi.
