Claude Code vs Codex: Sedm protokolových rozdílů, na které jsme narazili, když jsme oba enginy připojili do stejného vzdáleného systému

Zveřejnění zájmu: Vyvíjíme PandaNpc — systém, který umožňuje, aby kódovací agenti jako Claude Code a Codex byli přístupní vzdáleně a sdílení pro více lidí. Protože musíme tyto enginy podporovat současně na stejné stránce a ve stejném řetězci zpráv, museli jsme jejich chování na úrovni protokolů jedno po druhém sjednotit. Tento článek popisuje rozdíly, na které jsme v tomto procesu skutečně narazili, není to benchmarkové srovnání — neprováděli jsme srovnávací benchmarkové testy, takže v článku nenajdete žádná testovací čísla typu rychlost či míra úspěšnosti. Další plány jsou vysvětleny na konci článku.

Poznámka: Codex v tomto článku označuje nástroj příkazové řádky OpenAI Codex, nikoli jiné produkty stejného jména.

Závěr jednou větou: při lokálním použití v terminálu je rozdíl v uživatelském zážitku mezi oběma mnohem menší, než byste čekali; jakmile je ale chcete připojit do vlastního systému (vzdálené ovládání, synchronizace napříč zařízeními, obnova relací, schvalování nástrojů), rozdíly se téměř všechny soustředí do protokolové vrstvy — a tyto rozdíly jsme v té době nedokázali předem zjistit z dokumentace, narazili jsme na ně všechny až v praxi.

Pokud hledáte Codex vs Claude Code a chcete vědět, „který si vybrat", tento článek pravděpodobně není tím srovnáním, které hledáte — nesrovnává, kdo píše lepší kód, ale odpovídá na mnohem konkrétnější otázku: na co narazíte, když je chcete integrovat jako programovatelný backend.

Pro koho je tento článek

Pro vývojáře, kteří chtějí podporovat oba enginy současně, nebo přecházet z jednoho na druhý
Pro ty, kdo chtějí stavět okolní nástroje, jako je vzdálené ovládání / synchronizace napříč zařízeními / sdílení relací
Pro ty, kdo chtějí vědět, „v čem se vlastně liší modely relací těchto dvou CLI"

Pokud jen chcete psát kód na vlastním počítači a neplánujete integraci, hodnota tohoto článku je omezená — rychlejší bude podívat se přímo do oficiální dokumentace obou stran.

Nejdřív společné rysy: proč „vypadají stejně"

Než se pustíme do rozdílů, je nutné říct jasně: mentální model obou nástrojů je vysoce podobný — oba běží v terminálu, pracují po relacích, oba umí volat nástroje pro úpravu souborů a spouštění příkazů, oba vyžadují potvrzení uživatele u nebezpečných operací a oba zvládnou v jedné relaci průběžně zpracovávat více kol úkolů. Právě proto při integraci snadno vznikne úsudek, že „stačí napsat jednu adaptační vrstvu" — a přesně tak jsme začali.

Rozdíly nejsou ve vrstvě schopností, ale v protokolové vrstvě. To znamená, že chování, které vidíte v terminálu, může být téměř stejné, ale rámce, které vysílají, pořadí rámců a způsob uspořádání polí se liší. To je přesně důvod, proč se tyto rozdíly obtížně odhalují předem: když je používáte na vlastním počítači, nikdy na ně nenarazíte.

Rychlý přehled sedmi rozdílů

#	Dimenze	Chování Claude Code	Chování Codex	Koho to kousne, když se to nevyřeší
1	Identifikátor zpráv asistenta	Má stabilní id	Může ho nemít	Ty, kdo dělají perzistenci zpráv / synchronizaci napříč zařízeními
2	Kontrola živosti relace	Dávková forma, jedna dávka na skupinu	Očekává id jedné relace	Ty, kdo zobrazují online status
3	Pořadí přehrávání historie	Odpovídá skutečnému časovému pořadí	Rámce aktivit podvláken jsou hromadně na konci	Ty, kdo dělají pohledy subagentů / vícevláknové pohledy
4	Struktura příkazů volání nástrojů	Kompletní	Může být fragmentovaná	Ty, kdo dělají UI pro schvalování nástrojů
5	Odběr událostí kanálu	Je vykonavatelem přepnutí relace	Nemůže provádět přepnutí zároveň	Ty, kdo dělají vícenásobný relay
6	Kvóta online připojení	Sdílí s Codex stejný počítací fond	Stejně jako vlevo	Ty, kdo zavádějí omezení kvót
7	Výkon u dlouhé historie	Lineární	Při nesprávném zpracování degeneruje na nelineární	Ty, kdo dělají mobilní klienty

Níže každý bod podrobně rozebereme, každý je psaný ve formátu „příznak → jak lokalizovat → jak opravit".

1. Má zpráva asistenta stabilní id — určuje vaši strategii deduplikace

Příznak: Otevřete relaci Codex, hned po rozhovoru je vše v pořádku; po odhlášení a opětovném otevření se stejná odpověď asistenta změní na 2, 3 zprávy, a čím častěji vstupujete, tím více jich je. Zprávy od uživatele ovlivněny nejsou, množí se jen odpovědi asistenta. U relací Claude Code se to neděje.

Jak to lokalizovat: Tento příznak je velmi snadné chybně diagnostikovat jako problém s renderingem na klientovi nebo jako duplicitní načítání historie, a pak se pustit do pátrání ve frontendu. Správný první krok je podívat se přímo do cache na serveru, kolik záznamů tam skutečně je — pokud jich v cache skutečně je N, pak je problém v datové vrstvě a s renderingem nemá nic společného. Právě tímto krokem jsme tenkrát vrátili směr pátrání z klienta zpět.

Kořenová příčina: Zprávy asistenta v Claude Code mají stabilní identifikátor, takže při přehrávání a u zpráv doručených v reálném čase lze přímo deduplikovat podle id. Zprávy asistenta na straně Codex nemají zaručeno, že takový identifikátor ponesou. Když se použije stejná logika „deduplikace podle id", je stejná odpověď zapsána jako dvě různé zprávy.

Jak to opravit: U zpráv bez stabilního id přejděte na skládání podle „kotvy kola + obsah" — kotva je hash nejbližší předcházející uživatelské zprávy před touto odpovědí.

⚠️ Tady je past, o které stojí za to mluvit zvlášť: Naše první verze skládala podle čistého textu. Po nasazení jsme při procházení historických dat zjistili, že omylem smazala 691 stejných odpovědí napříč koly. Důvodem je extrémně vysoká míra opakování krátkých odpovědí u Codex (typu „Dobře." „Hotovo."), a množina pro deduplikaci byla na úrovni relace — jakmile se hash nějaké věty jednou zaznamenal, jakákoli stejná věta v dalších kolech této relace byla spolknuta. To je ztráta obsahu, což je závažnější než duplicity. Vrstvu kotvy nelze vynechat.

2. Kontrola živosti: jeden chce jednotlivě, druhý dávkově

Příznak: Relace zjevně běží, ale v rozhraní se zobrazuje jako offline.

Jak to lokalizovat: Tento rozdíl vypadá velmi univerzálně — názvy polí jsou na obou stranách podobné, a při psaní snadno uvěříte, že jedna sada kódu zvládne obojí. Způsob určení je jednoduchý: pošlete tam dávkovou strukturu a podívejte se, jestli návrat odpovídá tvaru, který očekáváte.

Kořenová příčina: Rozhraní pro zjištění, „je daná relace stále živá", mají na obou stranách jiný tvar. Na straně Claude Code používáme dávkovou formu, která najednou nese skupinu id relací; na straně Codex se očekává id jedné relace.

Jak to opravit: Oddělte dvě cesty volání a nesnažte se je sdílet. Tento rozdíl sám o sobě není obtížné zpracovat; problém je v tom, že neohlásí chybu — špatná struktura nevyvolá výjimku, jen dostanete sémanticky nesprávnou odpověď.

3. Pořadí rámců při přehrávání historie je jiné — stav subagenta se zasekne

Toto je nejzapeklitější místo z hlediska postupu při hledání příčiny.

Příznak: Indikátor stavu subagenta na bočním panelu stále dýchá oranžově jako „běží", i když ve skutečnosti už dávno skončil nebo byl přerušen. Ani po obnovení stránky se to nevrátí — každé obnovení to přehraje znovu. Objevuje se pouze u relací Codex.

Jak to lokalizovat: „Ani po obnovení se to nevrátí" je klíčové kritérium. Ukazuje, že problém není v real-time pushi, ale v samotném přehrávání historie — každé přehrání zapíše stav znovu špatně.

Kořenová příčina: Při přehrávání se nejprve rozloží všechny položky rodičovského vlákna (včetně notifikačních rámců, které označují, že „subagent skončil"), a poté se rámce aktivit každého podvlákna hromadně připojí na konec. Pořadí, které klient obdrží, je tedy: nejdřív uvidí notifikaci „přerušeno" a poté časově starší rámce aktivit. Logika, která zapisuje stav, neporovnává časová razítka, a tak poslední dávka starších rámců bezpodmínečně přepíše konečný stav zpět na „běží".

Jak to opravit: Přidejte do větve, která zapisuje stav, stráž konečného stavu — pokud je stav již konečný (dokončeno/selháno/zastaveno), může ho přepsat pouze novější rámec. Dejte pozor, aby kritéria sdílela stejné mapování stavů jako ostatní části, ať nevznikne druhá sada — jinak se pochopení „co je konečný stav" na dvou místech začne rozcházet.

Společným rysem takových problémů je: každý jednotlivý rámec je sám o sobě v pořádku, špatné je jejich relativní pořadí. Takže při sledování logů pouze jednotlivých rámců problém nikdy neuvidíte.

4. Struktura příkazů volání nástrojů: může se fragmentovat

Příznak: V kartách nástrojů relace Codex se příkazy zobrazují jako fragmenty typu 1,220p nebo /pid=…/ {print}, někdy je celý skript rozřezán, a dokonce po skončení odpovědi visí v rozhraní spousta neukončených karet nástrojů.

Jak to lokalizovat: Podívejte se na skutečnou strukturu pole příkazu v surovém rámci, ne na výsledek renderingu. Pokud podle cesty polí z Claude Code zjišťujete, „jaký příkaz uživatel spustil", dostanete rozřezané fragmenty.

Jak to opravit: Napište pro Codex zvlášť vrstvu pro rekonstrukci příkazů, která fragmenty slepí zpět do kompletního příkazu a teprve pak je předá UI.

Tento rozdíl je obzvlášť kritický pro ty, kdo dělají schvalování nástrojů: uživatel má na mobilu klepnout na „Povolit / Odmítnout", ale příkaz zobrazený na kartě je rozbitý — to je jako nechat člověka podepsat naslepo. To, že bezpečnostní funkce ztratí smysl, je mnohem závažnější než ošklivé zobrazení.

5. Plocha odběru událostí kanálu je jiná

Příznak: Dva uživatelé se navzájem odhazují z připojení.

Kořenová příčina: Pokud obě relay spojení odebírají a provádějí události typu „přepnutí relace", každá strana odhodí jednoho postiženého, čímž vznikne dvojité vyhození. Přepínací akce musí mít jediného vykonavatele.

Jak to opravit: Naším řešením je, že spojení na straně Codex odebírá pouze události vyhození a zneplatnění cache, nikdy neodebírá události přepnutí, a právo provádět přepnutí je pevně svázáno s druhou cestou.

Taková rozhodnutí typu „záměrně něco nedělat" v kódu obvykle zanechají jen jeden řádek komentáře, ale ten se přidává až poté, co na to jednou spadnete — a jakmile tuto omezující podmínku později někdo „mimochodem doplní", nehoda se vrátí. Proto je v komentáři nutné jasně napsat, proč se to nedělá, ne jen to, že se to nedělá.

6. Kvóta a počítání připojení jsou sloučené

Příznak: Uživatel si myslí, že ještě má kvótu, ale ve skutečnosti už ji překročil.

Kořenová příčina: Pokud stejně jako my omezujete počet online připojení, pozor na to, že připojení obou engin spadají do stejného počítacího fondu. Když má uživatel současně otevřené relace Claude Code a Codex, čerpají ze stejného limitu.

Toto není chyba, je to designové rozhodnutí — z pohledu uživatele se „kolik relací můžu mít současně otevřených celkem" chápe lépe než „kolik jich můžu mít pro každý engine". Pokud ale vaše implementace počítá zvlášť podle enginů, zbývající limit zobrazený na frontendu nebude odpovídat skutečnému odečtu na backendu.

Jak to opravit: Nejprve si jasně rozmyslete, kterou interpretaci chcete, a pak zajistěte, aby frontend a backend používaly stejnou. Míchání dvou interpretací je horší než zvolení špatné interpretace.

7. Výkonnostní charakteristiky při růstu rozsahu historie jsou jiné

Příznak: Na mobilu se otevření relace s dlouhou historií zasekne.

Kořenová příčina: Na iOS jsme jednou narazili na znatelné zamrznutí; příčinou byla operace při zpracování historie, která rostla kvadraticky s počtem zpráv. Je nutné říct, že to není problém enginu samotného, ale to, že jeho struktura historie nesedí s naším původním způsobem zpracování — stejný způsob zpracování se u druhého enginu neprojevil.

Jak to opravit: Nahraďte opakované skenování, které roste s počtem zpráv, jednorázovým indexem. Důležitější je navrhnout dopředu: dlouhá historie musí být zohledněna od samého začátku, nemůžete na to přijít až ve chvíli, kdy se uživatelům nashromáždí tisíce zpráv.

Takže který si vybrat

Nejprve vysvětlení: následující doporučení jsou z pohledu integrace, nikoli hodnocení kódovacích schopností. Neprováděli jsme srovnávací benchmarky, žádné tvrzení typu „tohle je o tolik rychlejší" z tohoto článku nepochází.

Kdy se více hodí zvolit Codex

Váš tým už je v ekosystému OpenAI — účty, kvóty a fakturace jsou na jednom místě, odpadne jedna správa účtů a pověření; tuto úsporu práce nelze podceňovat.
Vaše procesy už jsou postavené kolem jeho modelu relací a úkolů — kvůli migraci předělávat okolní nástroje obvykle není výhodné; sedm rozdílů výše je v opačném směru právě migračním nákladem.

Kdy se více hodí zvolit Claude Code

Chcete si stavět vlastní okolní nástroje — z našich integračních zkušeností plyne, že stabilní identifikátory zpráv výrazně usnadňují perzistenci a synchronizaci napříč zařízeními; rozdíly 1, 3 a 4 se na této straně zpracovávají snadněji.
Chcete dělat interakce typu schvalování nástrojů — struktura příkazů je kompletní, při tvorbě UI pro schvalování není potřeba žádné dodatečné skládání, a neexistuje tedy riziko „podpisu naslepo".

Případ, kdy nezvolit ani jeden

Pokud je vaším cílem jen „změnit model pro stejné interakce", pak je lepší vyměnit modelový backend než měnit engine. To je zčásti i důvod, proč jsme dělali PandaCode: interakční vrstva zůstává beze změny, mění se model.

Pokud migrujete: rozsah úprav odpovídající sedmi rozdílům

Mnoho lidí hledá tato dvě jména proto, že ve skutečnosti zvažují, „kolik to bude stát, když už jeden používám a vyměním ho za druhý". Níže přepočítáme sedm rozdílů výše na migrační náklady.

Je třeba vysvětlit: Tato sekce je rozsah úprav odvozený ze sedmi rozdílů výše, nikoli záznam z toho, že bychom sami provedli kompletní migraci — naše cesta byla „současné připojení", ne „přechod z jednoho na druhý". Berte to tedy jako kontrolní seznam, ne jako odhad člověkohodin.

Při migraci z Claude Code na Codex se úpravy soustředí na tato místa:

Logiku deduplikace je třeba přepsat (bod 1) — to je místo, které se nejsnáze podcení. Původní kód pro deduplikaci podle id nelze použít přímo, a když se splete, neohlásí chybu, jen tiše přidává nebo tiše ztrácí zprávy. Pokud máte perzistenci zpráv, musíte si před migrací promyslet, jakou kotvu zvolit.
Kontrola online stavu musí změnit tvar volání (bod 2) — práce je malá, ale pokud to nezapracujete, dojde k tomu, že „běží, ale ukazuje offline", a nevyvolá to výjimku.
Vše, co závisí na časovém pořadí historie, je třeba znovu ověřit (bod 3) — pohled subagentů, progress bary, jakákoli logika „odvození aktuálního stavu z historie" patří do této kategorie.
UI pro schvalování nástrojů potřebuje přidat vrstvu rekonstrukce příkazů (bod 4) — pokud váš produkt má schvalovací funkci, tato část se nesmí vynechat, jinak to znamená nechat uživatele podepisovat naslepo.

Opačným směrem (z Codex na Claude Code) je to obvykle snazší: deduplikaci lze zjednodušit zpět na deduplikaci podle id, struktura příkazů nepotřebuje vrstvu rekonstrukce. Ale pozor, neodstraňujte rovnou kompatibilní vrstvu napsanou pro Codex — pokud si chcete zachovat schopnost současné podpory, je tato vrstva logiky aktivum, ne závazek.

V obou směrech je třeba znovu ověřit: interpretaci kvóty (bod 6) a výkon u dlouhé historie (bod 7). Tyto dvě položky nemají k enginu tak přímý vztah, ale jsou to části, které se po výměně enginu nejsnáze zapomene otestovat znovu.

Jedno doporučení: Pokud už máte systém v provozu a existující data relací, spusťte před migrací novou logiku na stávajících datech pro srovnání, nepřepínejte přímo. Přesně tak vzniklo naše poučení z onoho omylem smazaného počtu 691 záznamů — logika sama o sobě vypadala v pořádku, teprve procházení historických dat odhalilo, že polyká obsah. To, že je nová logika správná, ≠ to, že je bezpečná pro stávající data.

Náš přístup: nevybíráme, připojíme oba

Protože chceme podporovat obojí současně, naším konečným závěrem je absorbovat rozdíly v prostřední vrstvě — směrem nahoru vystavujeme jednotný model zpráv a relací, směrem dolů přizpůsobujeme podle enginu. Cenou je, že s každým přidaným enginem je třeba znovu sjednotit všech sedm typů chování výše; přínosem je, že uživatel může v jednom rozhraní volně přepínat enginy a zážitek z relací, historie a schvalování je konzistentní.

Kontrolní seznam pro připojení nového enginu

Pokud se chcete vydat stejnou cestou, doporučujeme ověřovat v tomto pořadí: první čtyři položky rozhodují, jestli to vůbec funguje, poslední tři rozhodují, jestli v provozu dojde k nehodě:

Identifikátory zpráv — mají zprávy asistenta stabilní id? Pokud ne, jaká je vaše kotva pro deduplikaci?
Živost relace — přijímá rozhraní kontroly živosti jednotlivé položky, nebo dávku? Při chybné struktuře ohlásí chybu, nebo tiše vrátí špatnou odpověď?
Pořadí přehrávání historie — odpovídá pořadí rámců z přehrávání skutečnému časovému pořadí? Zejména když jsou ve hře podvlákna.
Struktura volání nástrojů — je pole příkazu při načtení kompletní? Může být rozřezané?
Plocha odběru událostí — které události musí mít jediného vykonavatele? Co se stane při vícenásobném provedení?
Interpretace kvóty — počítá se zvlášť podle enginů, nebo sloučeně? Je frontend a backend konzistentní?
Výkon u dlouhé historie — když se počet zpráv desetkrát zvýší, roste doba zpracování lineárně, nebo rychleji?

U každé položky doporučujeme nejprve ověřit na malém množství dat a pak na velké historii — položky 3 a 7 se projeví, teprve když objem dat naroste.

Zpětné dohledání podle příznaku: na kterou jste narazili

Pokud už jste do něčeho spadli, zpětné odvození od příznaku je obvykle rychlejší než pročítání dokumentace:

Příznak, který vidíte	S největší pravděpodobností	Jednokroková metoda určení
Po odhlášení a opětovném vstupu se odpovědi asistenta množí	Bod 1 (identifikátory zpráv)	Podívejte se přímo, kolik záznamů je uloženo v cache na serveru — hned uvidíte, jestli je to datová, nebo renderingová vrstva
Relace běží, ale zobrazuje offline	Bod 2 (kontrola živosti)	Zkontrolujte, jestli požadavek kontroly živosti posílá jednotlivou, nebo dávkovou strukturu
Stav subagenta visí na „běží", ani obnovení to nevrátí	Bod 3 (pořadí přehrávání)	„Ani obnovení to nevrátí" je samo o sobě kritériem: problém je v přehrávání, ne v real-time pushi
Příkaz na kartě nástroje je rozbitý / po skončení odpovědi stále visí karty nástrojů	Bod 4 (struktura příkazů)	Dívejte se na strukturu pole příkazu v surovém rámci, ne na výsledek renderingu
Dva uživatelé se navzájem odhazují z připojení	Bod 5 (plocha odběru)	Zkontrolujte, jestli událost přepnutí zpracovávají současně dva vykonavatelé
Frontend ukazuje zbývající kvótu, backend už ji překročil	Bod 6 (interpretace kvóty)	Ověřte, jestli frontend a backend počítají zvlášť podle enginů, nebo sloučeně
Otevření dlouhé relace na mobilu zamrzne	Bod 7 (dlouhá historie)	Porovnejte dobu trvání u relací s dvojnásobným počtem zpráv a sledujte, jestli to není nelineární

Jedno univerzální kritérium: pokud se příznak při každém obnovení spolehlivě opakuje, je problém s největší pravděpodobností v přehrávání historie nebo v datové vrstvě; pokud se vyskytuje jen občas při interakci v reálném čase, pak se teprve jděte dívat na push cestu. Toto kritérium nám ušetřilo hodně času — body 1 a 3 byly původně oba chybně diagnostikovány jako problémy klienta.

Časté dotazy (FAQ)

Je Codex CLI a OpenAI Codex to samé? Codex, o kterém tento článek pojednává, označuje nástroj příkazové řádky od OpenAI. Na trhu existují i jiné produkty s názvem Codex (včetně některého softwaru z oblasti práva a compliance), takže při vyhledávání snadno dojde k záměně; přidání kvalifikátoru „CLI" nebo „OpenAI" výsledky výrazně zpřesní.

Mění se tyto rozdíly s verzemi? Ano. Každá položka výše je chování, na které jsme narazili v konkrétním časovém okamžiku, a oba enginy se rychle vyvíjejí. Proto je důležitější ten kontrolní seznam — konkrétní rozdíly se mění, dimenze, které je třeba ověřit, se příliš nemění.

Je možné připojit oba enginy současně? Ano, přesně to děláme. Klíčové je absorbovat rozdíly v prostřední vrstvě, ne je nechat proniknout do UI vrstvy — jinak se logika rozhraní s každým přidaným enginem rozdvojí.

Další kroky

Plánujeme doplnit sadu srovnávacích úloh (stejná dávka úloh, pevné verze, veřejná metodika i surové výstupy) a výsledky pak aktualizujeme do tohoto článku. Do té doby tento článek neobsahuje žádná čísla o výkonu nebo míře úspěšnosti — co jsme netestovali, nebudeme psát, jako bychom testovali.

Tento článek vychází z našich skutečných inženýrských zkušeností s připojením Claude Code a OpenAI Codex do stejného systému vzdáleného přístupu. Naposledy aktualizováno 2026-08-26. Oba enginy se průběžně aktualizují, konkrétní chování se řídí oficiální dokumentací jednotlivých produktů.