Claude Code के 29 Tools बनाम Codex के 7 Tools: Design Philosophy बिल्कुल उलट है

Claude Code और Codex दोनों के weekly updates को track करते-करते थक गया था, तो मैं first principles पर वापस गया। मैंने हर SDK type definition, हर system prompt, हर settings schema खोला जो मुझे मिल सका। मैं यह समझना चाहता था कि हर tool क्या करता है, बल्कि यह भी कि tool counts इतने नाटकीय रूप से क्यों अलग हैं।

Claude Code 29 tools expose करता है। Codex 7 tools। यह ratio मुझे परेशान करता रहा, क्योंकि यह महज़ एक feature gap नहीं हो सकता। दो well-funded teams जिनमें top-tier engineers हों, वे गलती से 4:1 के ratio पर नहीं पहुंचतीं। यह अंतर जानबूझकर है, और इसके पीछे की सोच दो genuinely अलग philosophies को उजागर करती है कि AI को आपके development environment के साथ कैसे interact करना चाहिए।

Tool Granularity एक Security का फैसला है

सबसे striking अंतर यह है कि हर tool file operations को कैसे handle करता है। Claude Code file manipulation को चार अलग tools में बांटता है: Read, Write, Edit, और MultiEdit। Search को भी अपने dedicated tools मिलते हैं, Grep और Glob पूरी तरह Bash से independent हैं। इसका मतलब है कि आप settings.json को इस तरह configure कर सकते हैं कि Read allow हो लेकिन Write block हो। आप agent को अपना codebase search करने दे सकते हैं बिना उसे कोई file modify करने की permission दिए। Permission control tool level पर होता है।

Codex अलग रास्ता लेता है। यह agent को core primitives के रूप में shell, apply_patch, और file_read देता है। बाकी सब कुछ shell से होकर जाता है। Files search करना है? वह एक shell command है। Directories list करनी हैं? फिर shell। Security tool-level permissions से नहीं बल्कि execpolicy rules से आती है जो specific shell commands के खिलाफ pattern-match करते हैं, उन्हें allow, prompt, या block categories में classify करते हैं।

कोई भी approach गलत नहीं है। Claude Code का model आपको fine-grained locks देता है लेकिन एक बड़ी tool surface बनाए रखने की जरूरत होती है। Codex का model reason करने में आसान है लेकिन security enforcement को shell commands पर string-matching में धकेल देता है, जो तब नाजुक हो जाता है जब commands creative हो जाती हैं। मैंने ऐसे cases देखे हैं जहां एक well-crafted pipe chain उस execpolicy rule को bypass कर देती है जो उसी command के straightforward version के लिए लिखी गई थी।

पूरा breakdown:

• Claude Code (29 tools): 4 file tools (Read/Write/Edit/MultiEdit), 3 search tools (Glob/Grep/LS), 2 web tools, 3 cron tools, 4 MCP tools, Bash, और अन्य
• Codex (7 tools): shell, apply_patch, file_read, web_search, update_plan, write_stdin, js_repl

Skill Deployment Ecosystem को अलग करता है

दोनों tools ने Agent Skills open standard को adopt किया, जहां एक single SKILL.md file एक skill का behavior define करती है। Structure identical है। Distribution model नहीं है।

Codex ने एक centralized distribution system बनाया। $skill-installer चलाने से OpenAI की official skills repository से curated skills pull होती हैं। GitHub URL pass करें और third-party skills भी install हो सकती हैं। $skill-creator भी है जो conversation के जरिए नई skills interactively generate करता है। Experience npm जैसा लगता है: एक command, एक registry, instant availability।

Claude Code दूसरी दिशा में गया। आप SKILL.md files को .claude/skills/ में manually बनाते हैं, या /plugin marketplace add के जरिए git repositories से bundles install करते हैं। कोई single official registry नहीं है। Skills community repos, shared links, और word of mouth से discover होती हैं।

शुरू में मुझे Codex का centralized model बेहतर लगा क्योंकि discoverability अच्छी है। लेकिन कई हफ्तों तक दोनों use करने के बाद, decentralized approach का एक genuine फायदा है: मैं session के बीच में ही एक skill file edit कर सकता हूं और बिना restart किए changes तुरंत apply हो जाते हैं। Codex की installed skills के साथ, changes के लिए reinstallation चाहिए। जब आप एक custom workflow पर iterate कर रहे होते हैं, तो यह अंतर उतना ज़्यादा मायने रखता है जितना मैंने expect किया था।

एक नज़र में comparison:

• Invocation: Claude Code /skill-name use करता है, Codex $skill-name
• Storage: .claude/skills/ बनाम .agents/skills/
• Built-in skills: Claude Code /simplify, /batch, /loop, /claude-api ship करता है; Codex $skill-installer, $skill-creator ship करता है
• Distribution: Decentralized marketplace बनाम centralized repository

Session Diagnostics वह जगह है जहां असली फर्क दिखता है

दोनों tools basics share करते हैं: /model, /plan, /review, /clear, /fast। अंतर session introspection में आता है।

Claude Code ने आपको यह समझने देने में भारी निवेश किया है कि आपके session के अंदर क्या हो रहा है। /compact manually context compression trigger करता है। /context दिखाता है कि क्या load है। /cost real time में token spend track करता है। /doctor configuration problems diagnose करता है। /rewind पिछली conversation state पर वापस ले जाता है। /insights एक महीने के usage patterns analyze करता है और improvements suggest करता है। /usage sessions में cumulative consumption दिखाता है। यह सात commands हैं जो पूरी तरह session state को समझने और manage करने के लिए dedicated हैं।

Codex ने अपना focus कहीं और रखा। /personality agent की communication style adjust करता है। /theme visual appearance बदलता है। /apps connected applications manage करता है। ये UX customization features हैं, diagnostic tools नहीं।

यह एक गहरे philosophical split को दर्शाता है। Claude Code session को कुछ ऐसा मानता है जिसे आपको actively monitor और steer करना चाहिए। Codex इसे कुछ ऐसा मानता है जो background में बस काम करना चाहिए जबकि आप experience को customize करने पर focus करें। महीनों के use के बाद, मुझे दोनों चाहिए। Diagnostics मुझे तब बचाते हैं जब कोई session गड़बड़ा जाता है, लेकिन मुझे detailed architecture work और quick bug fixes के बीच switch करते समय personality adjust करने की क्षमता भी अच्छी लगती है।

• Claude Code (~35 commands + 4 bundled skills): session diagnostics पर heavy जैसे /compact, /context, /cost, /doctor, /rewind, /insights, /usage
• Codex (~19 commands): UX customization में stronger जैसे /personality, /theme, /copy, /apps, /skills, /agent, /tools

Team Architectures अलग-अलग assumptions से शुरू होते हैं

Multi-agent collaboration को हर tool कैसे handle करता है, शायद यही सबसे गहरा design difference reveal करता है।

Claude Code के Agent Teams peer-to-peer communication use करते हैं। Teammates एक lead agent के जरिए route किए बिना सीधे एक-दूसरे को messages भेजते हैं। वे एक task list share करते हैं और autonomously coordinate करते हैं। आप 2 से 16 agents run कर सकते हैं, और वे आपस में negotiate करेंगे कि कौन क्या handle करेगा। मैंने एक refactoring task पर तीन agents के साथ यह test किया, और token consumption उसी काम को करने वाले एक single session से 3 से 7 गुना ज़्यादा था। Coordination overhead वास्तविक है। लेकिन जब task genuinely parallel exploration से benefit करता है (जैसे एक race condition debug करना जहां आप agents को एक साथ अलग-अलग hypotheses probe करते देखना चाहते हैं), तो P2P model जवाब ज़्यादा तेज़ी से ढूंढता है।

Codex एक hub-spoke model use करता है। Child agents केवल parent को report करते हैं। कोई lateral communication नहीं है। spawn_agents_on_csv command एक CSV file से bulk में agents create करता है, जो embarrassingly parallel tasks के लिए optimized है जहां काम की हर unit independent है। सोचिए: “इस migration को 200 files पर apply करो” या “इस list के हर endpoint के खिलाफ यह check run करो।”

P2P universally बेहतर नहीं है। मैंने एक straightforward batch task पर significant tokens waste किए क्योंकि Claude Code के agents एक-दूसरे के साथ अपने overlapping काम के बारे में बात करते रहे। Codex का hub-spoke उस particular job के लिए सही choice होता।

• Claude Code: shared task list के साथ P2P messaging, 2 से 16 agents, tmux split-pane support
• Codex: Hub-spoke architecture, spawn_agents_on_csv के जरिए CSV-based bulk agent spawning

Hook Granularity Automation की गहराई तय करती है

Claude Code आपको tool execution को multiple lifecycle points पर intercept करने देता है। PreToolUse किसी tool के run होने से पहले fire होता है, जिससे आप call को validate या modify कर सकते हैं। PostToolUse बाद में fire होता है, इसलिए आप एक formatter attach कर सकते हैं जो हर file save पर auto-run हो। Notification hooks agent communications capture करते हैं। PreCompact context compression से पहले fire होता है, जो आपको critical information preserve करने का मौका देता है। HTTP Hooks external URLs पर JSON POST कर सकते हैं, Claude Code को CI pipelines, Slack, या custom dashboards से connect करते हैं।

Codex इसे simple रखता है। एक execpolicy file जिसमें shell commands पर apply होने वाले allow/prompt/block rules हैं। यही agent behavior control करने की पूरी extensibility surface है।

मैंने एक PostToolUse hook setup किया जो हर Write operation के बाद Prettier run करता है। इसमें पांच मिनट लगे और formatting-related follow-up prompts की पूरी category खत्म हो गई। इस तरह की surgical automation Codex के model में possible नहीं है, जहां आपको हर prompt में “and run prettier after writing” include करना होगा या इसे एक skill में build करना होगा।

लेकिन Codex की simplicity की भी value है। मैंने कभी misconfigured hook से अपना Codex setup accidentally नहीं तोड़ा। Claude Code के साथ मैंने यह दो बार किया है, एक बार PreToolUse hook से जो silently legitimate file reads block कर रहा था और बीस मिनट के confused debugging का कारण बना।

• Claude Code: PreToolUse, PostToolUse, Notification, PreCompact, और HTTP Hooks
• Codex: तीन levels (allow/prompt/block) के साथ execpolicy rule file

Architecture चुनें, Feature List नहीं

29 बनाम 7 की तुलना यह नहीं है कि एक tool दूसरे से ज़्यादा capable है। यह उसी design question के दो अलग जवाब हैं: एक AI coding agent को अपनी capabilities को individually controllable units में कितना decompose करना चाहिए?

Claude Code कहता है “सब कुछ।” हर operation को अपना tool, अपनी permission surface, अपने hook points मिलते हैं। यह आपको maximum control देता है configuration complexity की कीमत पर। Codex कहता है “केवल essentials।” Core operations को dedicated tools मिलते हैं; बाकी सब policy-based guardrails के साथ shell से होकर जाता है। यह आपको simplicity देता है granularity की कीमत पर।

जब मैं किसी दिए गए project के लिए कौन सा tool use करना है यह चुनता हूं, तो feature list से कोई फर्क नहीं पड़ता। जो मायने रखता है वह यह है कि project को fine-grained permission control चाहिए (regulated codebase, अलग-अलग access levels वाले multiple contributors) या lightweight simplicity (solo project, fast iteration, minimal setup)। जिस architecture के ऊपर आप build करते हैं वह बाद के हर workflow decision को shape करती है।