Codex vs Claude Code, văzute prin fișierele de pe disc
Nu un verdict despre care scrie cod mai bun. O descriere a modului în care se comportă de fapt cele două, scrisă de cei care au trebuit să facă o singură fereastră să le conducă pe amândouă.
De ce această comparație e diferită de celelalte
Cea mai mare parte din ce se scrie despre Codex vs Claude Code este un benchmark făcut pe laptopul cuiva și devine învechit într-o lună, pentru că amândouă lansează modele mai repede decât poate scrie oricine despre ele. Această pagină nu face asta. Dacă unul scrie cod mai bun decât celălalt e o întrebare despre modelele din ziua în care o pui, și nu ne prefacem că o putem tranșa.
Ce îți putem spune este din ce sunt făcute cele două programe, pentru că Vobuda a trebuit să le citească pe amândouă ca să deseneze o bară de control deasupra oricăruia. Unde își ține fiecare sesiunile, cum numește reluarea uneia, unde se află lista lui de modele, cum anunță modul în care se află. Sunt fapte de pe propriul tău disc, se schimbă încet și sunt ele cele care determină cum se potrivește fiecare într-o zi de lucru.
Pe scurt: Claude Code este cel mai lizibil dintre cele două, văzut din afară. Își scrie modelele într-un fișier, își ține sesiunile într-un dosar pe proiect și acceptă un flag pentru a relua una. Codex păstrează mai multe lucruri pentru el. Își schimbă modelele printr-un selector propriu, deci lucrul cinstit este să deschizi acel selector și să citești ce arată, în loc să livrezi o listă care va fi greșită.
Unde ține fiecare ce
Tot ce e în acest tabel se află pe calculatorul din fața ta și poți merge să verifici.
| Claude Code | Codex | |
|---|---|---|
| Sesiuni anterioare | Un folder per proiect sub ~/.claude/projects | Un singur index, ~/.codex/session_index.jsonl, care numește fiecare fir de discuție |
| Deschiderea uneia vechi | --resume <id> | resume <id> |
| Reluarea ultimei | --continue | resume --last |
| Skill-uri | ~/.claude/skills, plus folderul corespunzător din proiect | ~/.codex/skills, plus folderul corespunzător din proiect |
| Lista de modele | Propriul fișier, scris după ce îi spune serverul lui, așa că un model nou apare în ziua în care iese | Propriul selector, pe care meniul îl deschide și îl citește rând cu rând |
| Setarea modelului | /model pentru model, /effort pentru nivel | Propriul selector /model, apoi un nivel pentru fiecare model |
| Setările lui | settings.json | config.toml |
| Ce arată linia lui de status | Opus 5.5 cu efort ridicat, Claude Max | gpt-5.6-terra medium |
| Cum arată procesul | claude | node, pentru că Codex rulează ca node |
Verificat în septembrie 2026 pe instalările curente ale ambelor. Documentația lor proprie e autoritatea; așa arată cele două dintr-o fereastră care trebuie să le conducă.
Două foldere, de unde se citește tot ce e în tabelul de mai sus
Niciun agent nu ascunde nimic din toate astea. Bara de control din Vobuda citește exact aceste fișiere, de aceea poate arăta o listă de modele pe care noi nu am scris-o niciodată.
settings.json model, efort, permisiuniprojects/ un folder per proiect <project>/ sesiunile lui, cea mai nouă la finalskills/ ale tale, plus cele proprii ale proiectuluihistory.jsonl ce ai scris, în ordineconfig.toml model și nivel de raționamentsession_index.jsonl fiecare fir de discuție, câte o linieskills/ ale tale, plus cele proprii ale proiectuluiTrei capcane în care am căzut ca să le poți recunoaște
Fiecare dintre acestea a fost mai întâi un defect în Vobuda și fiecare spune ceva adevărat despre cei doi agenți.
Cel mai adânc proces al unei sesiuni Claude e adesea codex
Claude Code rulează Codex ca propriul său ajutor. Așa că, luând cel mai adânc proces din arbore pentru a decide cărui agent îi aparține un bloc, dock-ul spunea CODEX peste o sesiune Claude și făcea ca „new” să repornească programul greșit. Agentul căruia îi aparține un bloc e cel pe care l-a pornit persoana, nu cel pe care l-a pornit el.
Codex nu e node_repl
Codex rulează ca node, iar un shell pornește un program făcând fork din sine și apoi înlocuindu-se cu acel program, deci lista de procese continuă să îl numească după numele vechi tot restul vieții lui, dacă executabilul nu e cerut explicit pe nume. Un bloc care rula Codex se numea odată node_repl.
Lista unui agent peste blocul altui agent
Două liste de modele și un flag continue au fost scrise când exista un singur agent și au rămas globale când au ajuns trei. Deschiderea unui bloc Codex oferea Opus, Sonnet, Haiku și Fable, iar continue trimitea codex --continue, la care Codex răspunde cu o eroare de utilizare. Tot ce se citește dintr-un program aparține acum acelui program și e cerut doar prin el.
Cuvintele din interfața unui agent se schimbă
Citirea răspunsului unui agent, sau a cererii care i-a fost dată, căutând anumite cuvinte în interfața lui eșuează la următoarea lansare a acelui agent. În schimb, ambele sunt recunoscute după formă: un agent e identificat după promptul de așteptare pe care îl pune înaintea a ceea ce scrii, nu după chenarul desenat în jurul lui, pentru că chenarul e o modă, iar promptul nu e.
Răspunsul pe care îl vor de fapt majoritatea e amândoi
În practică, nimeni nu alege unul și îl șterge pe celălalt. Unul e mai bun la ce faci în ora asta, celălalt are sesiunea în care făceai altceva, iar amândoi au limite de utilizare care apar în momente incomode. Ce contează e dacă rularea amândurora deodată îți costă ceva.
În Vobuda, nu. Două blocuri într-o filă, sau două file, fiecare cu propria bară care citește propriul agent, fiecare cu propriul model și efort afișate, iar modul de permisiuni al lui Claude Code alături. Amândoi trimit semnalele către fereastră în același fel, așa că o insignă, un sunet și o notificare înseamnă același lucru indiferent care dintre ei le-a declanșat, iar registrul a ce s-a întâmplat cât ai fost plecat îi listează unul lângă altul, grupați pe blocuri.
Niciunul nu este conectat printr-o secțiune de setări sau un comutator, pentru că un semnal pe care trebuie să-l configurezi înainte să funcționeze nu este o funcție, este temă pentru acasă. Se conectează singuri la pornire, iar butonul Integrare din bara de file pune legăturile la loc pentru un agent care rula deja. Hook-urile terților deja existente rămân unde sunt, iar orice ocupă deja un eveniment este apelat imediat după al nostru.
Codex și Claude Code, întrebări directe
Care e mai bun, Codex sau Claude Code?
În privința calității codului, e o întrebare despre ce modele rulează fiecare în ziua în care întrebi, iar orice răspuns scris devine învechit. În privința comportamentului lor ca programe, Claude Code e mai lizibil din exterior: își scrie lista de modele într-un fișier, ține sesiunile într-un folder per proiect și primește un flag pentru a relua una. Codex ține mai mult intern.
Pot rula Codex și Claude Code în paralel?
Da. Două blocuri în aceeași fereastră, fiecare cu propria bară de control care citește propriul agent. Amândoi anunță când termină sau au nevoie de permisiune și amândoi apar în aceeași înregistrare a ceea ce s-a întâmplat cât ai lipsit.
Cum listează Vobuda modelele Codex?
Întrebându-l pe Codex. Odată am livrat o listă de două modele pe care Codex nu le rulează, care era greșită chiar în ziua în care a apărut. Acum butonul de model deschide selectorul propriu al lui Codex, citește rândurile pe care le arată și apasă pe cel ales de tine, iar fiecare model oferă nivelurile pe care i le dă Codex.
Are vreunul dintre ei nevoie de cont la Vobuda?
Nu. Vobuda nu are niciun cont. Fiecare agent folosește abonamentul sau cheia pe care i le-ai dat deja. Vobuda folosește autentificarea lui Claude Code pentru un singur lucru, să ceară de la Anthropic limitele tale de utilizare, și nu o atinge niciodată pe cea a lui Codex.
Dar un model local, în loc de acestea?
Un model local prin Ollama e o intrare în agents.json și nu necesită cod. Primește un bloc și o bară cu tot ce poate declara sincer agentul respectiv despre sine.
O singură fereastră, ambii agenți
Gratuit, fără cont, iar fiecare bară citește agentul de dedesubt.
curl -fsSL https://vobuda.com/install.sh | sh