$ entry

Subagenti v OpenAI Codex - paralelní agenti pro kódování (a jak se liší od Claude Code)

OpenAI Codex přidal subagenty — specializované paralelní agenty pro revizi kódu, průzkum repozitářů a dávkové zpracování. Jak fungují a čím se liší od subagentů v Claude Code?

Rychlé body

  • Codex od OpenAI nově podporuje subagenty, specializované paralelní agenty řešící problém degradace kontextu u složitých úloh
  • Subagenti se spouštějí výhradně na pokyn uživatele a každý běží ve vlastním kontextovém okně s vlastním modelem
  • Vlastní agenti se definují v TOML souborech s volbou modelu (gpt-5.4 nebo gpt-5.3-codex-spark) a úrovně uvažování
  • Experimentální funkce spawn_agents_on_csv umožňuje dávkové zpracování stovek podobných úloh
  • Claude Code nabízí obdobný koncept s definicí agentů v markdownu a automatickou delegací, ale s odlišnými kompromisy
  • Subagenti u obou nástrojů násobí spotřebu tokenů, což se promítá do nákladů i rychlosti dosažení limitů

OpenAI přidala do svého Codexu podporu subagentů — paralelně běžících specializovaných agentů, kteří řeší konkrétní dílčí úkoly a vracejí hlavnímu agentu stručné shrnutí. Je to reakce na poslední vývoj. Agentní kódovací nástroje přecházejí od jednovláknového modelu práce k orchestraci více specializovaných agentů.

Podobný koncept ostatně nějakou dobu má i Claude Code od Anthropicu, ale s odlišným přístupem ke konfiguraci i orchestraci. Zatímco Codex definuje vlastní agenty v TOML souborech a vyžaduje jejich explicitní spuštění uživatelem, Claude Code používá markdownové soubory s YAML hlavičkou a umí agenty delegovat i automaticky na základě popisu úkolu. My se ovšem nyní budeme věnovat právě představeným agentům v CODEXu od OpenAI.

Proč subagenti — problém jednovláknového agenta

Když agentní nástroj zpracovává složitější úkol v jednom vlákně — například zkoumá strukturu repozitáře, píše kód, spouští testy a analyzuje výsledky — kontextové okno se postupně plní průzkumovými poznámkami, záznamy z testů, výpisy chyb a mezivýsledky. Tento jev se v odborné literatuře označuje dvěma termíny. Prvním je znečištění kontextu(context pollution), kdy se užitečné informace pohřbí pod vrstvou šumu z mezikroků. Druhým je degradace kontextu(context rot), kdy se výkon modelu postupně zhoršuje, protože narůstající množství méně relevantních dat vytlačuje z pozornosti to podstatné. O problému degradace kontextu podrobněji pojednává výzkum společnosti Chroma.

Subagentní architektura tento problém řeší přesunutím hlučné práce mimo hlavní vlákno. Hlavní agent se soustředí na požadavky, rozhodnutí a finální výstupy. Specializovaní subagenti paralelně provádějí průzkum, testy nebo analýzu logů. Každý běží ve vlastním kontextovém okně a hlavnímu agentu vrací jen stručné shrnutí, nikoli surový mezivýstup. Kromě čistšího kontextu to přináší i úsporu času, protože nezávislé úkoly běží souběžně.

Jak subagenti v Codexu fungují

Codex obsluhuje celou orchestraci: spouštění nových subagentů, směrování instrukcí, čekání na výsledky a ukončení agentních vláken. Když uživatel požádá o paralelní zpracování, Codex počká, dokud nejsou k dispozici všechny výsledky, a poté vrátí konsolidovanou odpověď.

Zásadní vlastností je, že Codex nikdy subagenty nespouští automaticky — vždy vyžaduje explicitní pokyn od uživatele. Formulace typu „spusť tři agenty” nebo „deleguj tuto práci paralelně” slouží jako spouštěč. Subagenti jsou aktuálně viditelní v desktopové aplikaci Codex a v příkazové řádce (CLI), podpora v IDE rozšíření zatím chybí.

Typický příklad promptu pro revizi pull requestu vypadá takto: uživatel zadá šest bodů k prověření (bezpečnost, kvalita kódu, chyby, souběhy, nestabilní testy, udržovatelnost) a instruuje Codex, aby na každý bod spustil jednoho agenta, počkal na všechny a shrnul výsledky. V CLI se lze mezi aktivními agentními vlákny přepínat příkazem /agent a přímo ovládat běžící subagenty — zastavit je, přesměrovat nebo uzavřít dokončená vlákna.

Co se týče bezpečnosti a sandboxu, subagenti dědí aktuální nastavení sandboxu od rodičovské session. V interaktivním CLI režimu se schvalovací požadavky z neaktivních agentních vláken zobrazují i při práci v hlavním vlákně. V neinteraktivních režimech akce vyžadující nové schválení selže a Codex chybu propaguje zpět do rodičovského workflow.

Vestavění a vlastní agenti

Codex obsahuje tři předdefinované agenty:

  • default — obecný agent jako záložní volba
  • worker — zaměřený na implementaci a opravy kódu
  • explorer — pro čtení a průzkum kódové základny

Pro specializovanější potřeby si uživatel definuje vlastní agenty jako samostatné TOML soubory. Projektoví agenti se ukládají do adresáře .codex/agents/ v repozitáři, osobní agenti do ~/.codex/agents/. Pokud vlastní agent sdílí jméno s vestavěným, vlastní agent má přednost.

Každý soubor vlastního agenta musí obsahovat tři povinná pole:

PoleTypPovinnéÚčel
nameřetězecanoJméno, pod kterým Codex agenta identifikuje a spouští
descriptionřetězecanoPopis pro uživatele, kdy má Codex agenta použít
developer_instructionsřetězecanoHlavní instrukce definující chování agenta

Volitelná pole zahrnují model (volba modelu), model_reasoning_effort (úroveň uvažování), sandbox_mode (režim sandboxu, například jen pro čtení), mcp_servers (připojení MCP serverů) a skills.config (napojení na dovednosti). Vynechaná pole se dědí z rodičovské session.

Příklad vlastního agenta pro bezpečnostní revizi v souboru .codex/agents/reviewer.toml:

name = "reviewer"
description = "PR reviewer focused on correctness, security, and missing tests."
model = "gpt-5.4"
model_reasoning_effort = "high"
sandbox_mode = "read-only"
developer_instructions = """
Review code like an owner.
Prioritize correctness, security, behavior regressions, and missing test coverage.
Lead with concrete findings, include reproduction steps when possible.
"""
nickname_candidates = ["Atlas", "Delta", "Echo"]

Pole nickname_candidates je volitelné a slouží čistě pro přehlednější zobrazení v uživatelském rozhraní — když běží více instancí stejného typu agenta, uživatel v UI vidí rozlišující přezdívky místo opakujícího se názvu.

Volba modelu a úrovně uvažování

Codex nabízí dva hlavní modely pro subagenty a tři úrovně intenzity uvažování. Pokud uživatel model ani úroveň explicitně nezadá, Codex se pokusí vybrat vhodnou kombinaci sám na základě povahy úkolu.

ModelCharakteristikaTypické použití
gpt-5.4Nejnovější model OpenAI, silné kódování, uvažování i práce s nástrojiHlavní agent, koordinace víceúčelových úloh, bezpečnostní analýza
gpt-5.3-codex-sparkOptimalizovaný pro rychlost (vyvinutý ve spolupráci s Cerebras), aktuálně jen pro Pro uživatelePrůzkum kódu, skenování, rychlé shrnutí, pracovní subagenti

Úroveň uvažování (model_reasoning_effort) ovlivňuje hloubku analýzy, dobu odezvy i spotřebu tokenů:

ÚroveňKdy použít
highSložitá logika, trasování okrajových případů, bezpečnostní audit
mediumVyvážený výchozí režim pro většinu agentů
lowRychlost je důležitější než hloubka — jednoduché skenování, formátování

Doporučený vzor je provozovat hlavního agenta na gpt-5.4 s vysokou úrovní uvažování a pracovní subagenty na gpt-5.3-codex-spark se střední nebo nízkou úrovní. Tím se dosáhne rozumného kompromisu mezi kvalitou výstupu a rychlostí.

Praktické příklady použití

Dokumentace Codexu uvádí několik vzorových konfigurací, které ilustrují různé scénáře nasazení subagentů.

Revize pull requestu se třemi agenty. Tato konfigurace rozděluje práci mezi tři specializované agenty: pr_explorer (model gpt-5.3-codex-spark, střední uvažování, režim jen pro čtení) mapuje dotčené cesty v kódu a shromažďuje důkazy. Agent reviewer (gpt-5.4, vysoké uvažování, jen pro čtení) hledá skutečná rizika v oblasti bezpečnosti, korektnosti a testovacího pokrytí. Agent docs_researcher (gpt-5.3-codex-spark, střední uvažování, jen pro čtení) využívá MCP server s dokumentací k ověření API a chování frameworků. Uživatel pak Codexu jedním promptem zadá, aby pr_explorer zmapoval kód, reviewernašel rizika a docs_researcher ověřil frameworková API.

Dávkové zpracování přes CSV. Experimentální funkce spawn_agents_on_csv umožňuje zpracovat velké množství podobných úloh najednou. Codex přečte CSV soubor, na každý řádek spustí jednoho pracovního subagenta, počká na dokončení celé dávky a exportuje výsledky zpět do CSV. Šablona instrukce pro pracovníka může používat zástupné symboly z názvů sloupců (například {path} nebo {owner}). Každý pracovník musí volat report_agent_job_result přesně jednou — pokud tak neučiní, Codex řádek označí chybou. Tato funkce je užitečná pro opakované audity, kontrolu seznamu incidentů nebo generování strukturovaných shrnutí pro velké množství položek.

Ladění frontendových chyb. Třetí vzorová konfigurace kombinuje agenta code_mapper pro mapování kódových cest (gpt-5.3-codex-spark, jen pro čtení), agenta browser_debugger s přístupem k prohlížečovým nástrojům přes MCP server (gpt-5.4, vysoké uvažování) a agenta ui_fixer pro implementaci nejmenší možné opravy (gpt-5.3-codex-spark).

Konfigurace a limity

Globální nastavení subagentů se definuje v sekci [agents] konfiguračního souboru:

ParametrVýchozí hodnotaÚčel
agents.max_threads6Maximální počet souběžně otevřených agentních vláken
agents.max_depth1Hloubka vnořování (přímý potomek může spustit subagenta, ale hlubší vnořování ne)
agents.job_max_runtime_seconds1800Výchozí timeout na pracovníka pro CSV dávkové úlohy

Výchozí limit šesti souběžných vláken a hloubka 1 znamená, že Codex záměrně zabraňuje nekontrolovanému množení agentů. Subagenti nemohou spouštět další subagenty (s výjimkou přímého potomka při hloubce 1), čímž se předchází nekonečnému vnořování.

Kdy subagenty nepoužívat

Subagenti nejsou univerzální řešení a dokumentace Codexu explicitně varuje před třemi scénáři. Zaprvé, paralelní zápisy do stejných souborů vedou ke konfliktům — pokud dva agenti editují tentýž soubor, výsledky se přepíšou nebo se stanou nekonzistentními. Zadruhé, sekvenční úkoly, kde krok 2 závisí na výstupu kroku 1, nedokáží agenti koordinovat za běhu — pro takové případy je lepší použít jednoho agenta s postupným zpracováním. Zatřetí, pro jednoduché jednorázové změny v jednom souboru je režie paralelního spuštění zbytečná.

K tomu přistupuje ekonomický aspekt: každý subagent provádí vlastní volání modelu a práci s nástroji nezávisle, takže spotřeba tokenů je výrazně vyšší než u srovnatelného jednovláknového běhu. Dokumentace neuvádí přesný násobitel, ale z povahy věci jde minimálně o lineární nárůst s počtem subagentů plus režie koordinace.

Srovnání: subagenti v Codexu a v Claude Code

Claude Code od Anthropicu nabízí koncepčně podobný mechanismus subagentů, ale s řadou implementačních rozdílů.

Definice agentů. Codex používá TOML soubory, Claude Code markdownové soubory s YAML frontmatter. V praxi je markdown přístup o něco přívětivější pro čtení a editaci, protože systémový prompt agenta tvoří přirozený obsah dokumentu za hlavičkou. TOML je naopak striktnější a méně náchylný k chybám v parsování.

Vestavění agenti. Codex má tři: default, worker a explorer. Claude Code má rovněž tři, ale s odlišným zaměřením: Explore (optimalizovaný na čtení, ve výchozím nastavení běží na Haiku pro úsporu), Plan (průzkum pro plánovací režim) a General-purpose (komplexní úkoly vyžadující jak čtení, tak modifikaci).

Spouštění. Codex vyžaduje výhradně explicitní pokyn od uživatele. Claude Code umí agenty delegovat i automaticky na základě shody popisu agenta s aktuálním úkolem — i když praxe ukazuje, že automatická delegace zatím není spolehlivá a explicitní invokace zůstává jistějším postupem.

Paralelismus. Codex umožňuje až 6 souběžných vláken (konfigurovatelné), Claude Code podporuje až 10 paralelních úloh prostřednictvím Task Tool, přičemž úlohy zpracovává v dávkách.

Volba modelu. V Codexu lze pro každého agenta zvolit jiný model (gpt-5.4, gpt-5.3-codex-spark) i úroveň uvažování. V Claude Code lze rovněž specifikovat model na úrovni agenta (Opus, Sonnet, Haiku), případně odlišný model pro subagenty přes proměnnou prostředí CLAUDE_CODE_SUBAGENT_MODEL.

Dávkové zpracování. Codex má specifickou funkci spawn_agents_on_csv pro hromadné zpracování CSV dat, což Claude Code v této podobě nenabízí.

VlastnostOpenAI CodexClaude Code
Formát definiceTOMLMarkdown + YAML frontmatter
Vestavění agentidefault, worker, explorerExplore, Plan, General-purpose
Spouštěnípouze explicitníexplicitní i automatické
Max. paralelních vláken6 (konfigurovatelné)až 10 (Task Tool)
Hloubka vnořováníkonfigurovatelná (výchozí 1)subagenti nemohou spouštět další
Dávkové CSV zpracováníano (experimentální)ne
Volba modelu na agentaano (gpt-5.4, spark)ano (Opus, Sonnet, Haiku)
MCP servery na agentaanoano
Přezdívky pro UIano (nickname_candidates)barevné rozlišení

Cenový kontext

Subagentní workflow je z podstaty dražší než jednovláknový běh. U Codexu závisí cena na zvoleném tarifu. Plán Plus stojí 20 dolarů měsíčně a nabízí 45–225 lokálních zpráv a 10–60 cloudových úloh za pětihodinové okno. Plán Pro za 200 dolarů měsíčně poskytuje zhruba šestinásobek těchto limitů. Nad rámec zahrnutých limitů se platí kredity — průměrná cena lokální zprávy je přibližně 5 kreditů u modelu gpt-5.3-codex, cloudové úlohy přibližně 25 kreditů. Model gpt-5.3-codex-spark je dostupný pouze na Pro tarifu. Kompletní přehled cen je na stránce s cenami Codexu.

Při použití subagentů se spotřeba limitů a kreditů násobí, protože každý subagent spotřebovává tokeny nezávisle. Dokumentace Codexu doporučuje přepnout rutinní úkoly na model gpt-5.1-codex-mini (přibližně čtvrtinová spotřeba) a omezit počet MCP serverů a rozsah AGENTS.md, aby se kontext zbytečně nezvětšoval.

Pro srovnání, Claude Code na plánu Max (100 dolarů měsíčně za Sonnet, 200 dolarů za Opus) poskytuje neomezené použití v rámci férové politiky. Subagentní workflow ale podle nezávislých odhadů spotřebovává čtyřikrát až sedmkrát více tokenů než standardní jednovláknová session, takže i při „neomezených” limitech se uživatel snáze dostane k regulaci rychlosti.

Mimochodem, používání agentů je hlavním důvodem, proč se lidem subjektivně rychleji vyčerpávají limity u Claude Code (tím druhým hlavním důvodem bývá Opus model). Za stejnou dobu běhu z pohledu uživatele totiž běží najednou několik agentů, kteří každý konzumuje tokeny…

Hodnocení a závěr

Subagenti řeší reálný a dobře zdokumentovaný problém degradace kontextu. Architektura, kde hlavní agent koordinuje a specializovaní pracovníci zpracovávají hlučnou práci ve vlastních kontextových oknech, je logickým krokem vpřed oproti jednovláknovému modelu, který u složitějších úloh naráží na limity kontextového okna.

Oba hlavní agentní kódovací nástroje — Codex od OpenAI i Claude Code od Anthropicu — konvergují ke stejnému vzoru, i když s odlišnými implementačními detaily. Codex je v konfiguraci explicitnější a strukturovanější (TOML, povinná pole, číslovaná hloubka vnořování), což vyhovuje týmům, které chtějí přesnou kontrolu. Claude Code je flexibilnější (markdown, automatická delegace, větší volnost v definici), ale za cenu menší předvídatelnosti automatického routování.

Z praktického hlediska stojí za zmínku tři omezení, která se týkají obou platforem. Zaprvé, násobení tokenové spotřeby je reálné a nekontrolované používání subagentů může rychle vyčerpat limity nebo rozpočet. Zadruhé, paralelní zápisy do společných souborů zůstávají neřešeným problémem — žádný z nástrojů nemá vestavěný mechanismus pro řešení konfliktů. A zatřetí, pozorovatelnost je zatím slabá: u obou nástrojů chybí přehledný nákladový rozpis na úrovni jednotlivých subagentů a trasování jejich činnosti v reálném čase.

Subagenti nejsou revoluční funkce — jsou přirozeným důsledkem toho, že kontextová okna jazykových modelů mají praktické limity i při stovkách tisíc tokenů. Pro vývojáře, kteří s agentními nástroji pracují na složitějších projektech, představují užitečný nástroj pro paralelizaci a izolaci kontextu. Pro jednoduché úkoly jsou zbytečnou režií.

Kompletní dokumentace subagentů v Codexu je na developers.openai.com/codex/subagents, konceptuální přehled na developers.openai.com/codex/concepts/subagents. Dokumentace subagentů v Claude Code je na code.claude.com/docs/en/sub-agents.

— Patrick Zandl