60% of Users Run Claude Code and Codex Side by Side — The Real Reason Is Downtime Insurance

Title

60% of Users Run Claude Code and Codex Side by Side — The Real Reason Is Downtime Insurance

Meta Description

Theo claims 60% of Codex users also use Claude Code, framed as a dual-model trend. But status page data shows Codex was in a failed state for 42.7 hours over the same period — the real reason for dual use is downtime insurance, not product preference. This article breaks down 80 days of incident data and a router experiment.

Article Content

A developer's statistics got packaged as a "dual-model trend," but when you put both companies' status pages side by side, the conclusion flips entirely.

A Misread 60%

T3 Code founder Theo Browne posted on X that over the past two weeks, more than 60% of T3 Code users who used Codex also used Claude Code, hinting that this proved "the harness is the product." The post racked up nearly 70,000 views, and the comments overwhelmingly interpreted it as: models are interchangeable, and what really matters is the shell that carries them.

But independent developer Matt Busel pulled the public APIs of both companies' status pages and found a key piece of context: within the same time window, Codex was in an unclosed incident state for 42.7 hours, accounting for 12.7% of the two-week period. Claude Code, meanwhile, was down for only 34 minutes over the same period. In other words, for one hour out of every eight, Codex's status page was reporting errors.

"That 60% isn't preference data — it's marketing packaging of downtime data," Busel wrote bluntly in his article.

80 Days of Data: Both Sides Failed for Over 40 Hours Each

Busel used about 60 lines of Python to run interval merging and intersection analysis on the APIs of Anthropic's status.claude.com and OpenAI's status.openai.com. The window was August 1 to October 19, roughly 80 days.

• Claude Code: 28 incidents, totaling 2,533 minutes (42.2 hours), uptime at roughly 97.79%.
• Codex: 12 incidents, totaling 3,358 minutes (56.0 hours), uptime at roughly 97.07%.
• Both failing simultaneously: only 101 minutes, across two events.

If you primarily use one and switch to the other during failures, coverage can rise from about 97% to 99.91%, eliminating 96% to 97% of downtime. This explains why users "dual-open" — it's not aesthetic preference, but the fact that every switch removes nearly all failure time.

Busel also acknowledged the data's limitations: a status page's "degraded performance" doesn't equal a full outage, and status pages are maintained by the companies themselves, so there's a tendency toward underreporting.

The status page's "degraded performance" and "outage" are typically merged statistically into "unclosed incidents," but their actual impact on developers differs significantly: the former may just mean higher latency or partially limited functionality, while the latter means the service is unavailable. Busel's script uses incident state duration as its metric, counting both types of events together — meaning the 42.2 and 56.0 hours are upper-bound estimates of "abnormal state," not precise durations of "completely unusable." Moreover, status pages are maintained by vendors themselves, and incident detection, severity grading, and closure all depend on their internal processes. Historically, multiple cloud providers have been noted for underreporting or delayed disclosure, so third-party analysis based on status page APIs should only serve as a relative comparison reference, not an authoritative measure of absolute availability.

The Economics of Two $20 Plans

Theo once posted that the private message he receives most often is "which $20 plan is better." Busel converted the 80 days of data into monthly figures:

• Claude Code users adding a second plan buy back about 15.5 hours per month, at $1.29 per hour.
• Codex users adding a second plan buy back about 20.8 hours per month, at $0.96 per hour.

"If an hour of your work is worth more than a dollar, the second plan isn't a luxury — it's a backup generator in the garage," the article states. No new tools needed — just two terminals and the habit of "switch when it stalls."

A Misread Anthropic Engineering Blog

Theo pinned a tweet citing news of Anthropic building its own source control system, saying "many of us will eventually end up where they are." But the original text explicitly states: this system is "by no means a general-purpose replacement for git" and applies only to "very large monorepos with tens of thousands of engineers or large numbers of agents."

Busel's rebuttal is direct: most developers merge code 30 times a day, not 30,000 times. What actually held most people back this quarter was failure recovery, not version control. GitHub's status page recorded 4 incidents affecting Git operations during the same period, totaling 554 minutes (9.2 hours) — far less than Claude Code's 42.2 hours.

The Awkward Results of Testing Your Own Router

The most self-deprecating part of the article is the author's real-world test of his own LLM routing library. llm-router claims to use five strategies to dispatch prompts to the "right model," but after running 244 real prompts (164 HumanEval coding problems plus 80 MT-Bench first-round questions), it turned out that every strategy chose the same model for all 244 prompts.

The reason is buried in the scoring formula: the penalty for complexity mismatch can at most halve the score, while the price difference between gpt-4o and gpt-4o-mini is 16.7x. The "Balanced" strategy is essentially just a cheapest-model selector with a bit of ceremony.

"Most routers claiming to be intelligent are doing the same thing — it's just that nobody has publicly run 244 prompts through them," Busel wrote. The truly effective routing is the dumb approach: when one fails, switch to the other.

An "LLM router" refers to routing requests at the application layer to models of different capability tiers and price points based on prompt characteristics (such as length, task type, estimated complexity), in order to balance cost and quality. Its typical scoring function penalizes "capability mismatch," but the penalty magnitude usually has a cap; when the price difference between high-end and low-end models reaches more than tenfold, the weight of the cost term in the total score often overwhelms the quality term, causing routing decisions to degenerate into "always pick the cheapest." For routing to be truly effective, the scoring function needs to make the quality penalty grow nonlinearly with task difficulty, and introduce post-hoc evaluation mechanisms for routing decisions; otherwise, so-called intelligent routing is just a strategic veneer over a fixed choice.

What You Should Actually Do

The article's advice is plain but actionable:

• Keep two coding agents logged in simultaneously. Based on the math above, the second subscription costs about a dollar per hour.
• Subscribe to both companies' status page RSS or JSON feeds, and switch the moment a failure occurs instead of retrying for twenty minutes.
• Implement circuit breaking and degradation at the application layer, not "intelligent routing": open the circuit breaker after five consecutive failures and direct traffic to the other provider.
• If you must route by difficulty, test with a public prompt set first. If one model wins 100% of decisions, it's not a router.
• Before switching, do exponential backoff retries with jitter. Most fluctuations are rate limiting, not outages.

Busel doesn't entirely dismiss Theo's claim that "the harness is the product" — he acknowledges that a tool carrying both models is indeed useful. The disagreement is about the reason: is it product taste, or downtime insurance? The data sides with the latter.

One-line Summary

60% dual-open data is really downtime insurance — switching, not model preference.

Paragraph Summary

The article breaks down T3 Code founder Theo Browne's tweet that "60% of users use both Codex and Claude Code," pointing out that when the data was published, Codex was in a failure window totaling 42.7 hours over two weeks. The so-called dual-open is not model preference but downtime response. Author Matt Busel used about 60 lines of Python to analyze 80 days of status page data from both companies, finding Claude Code failed for 42.2 hours and Codex for 56 hours, but simultaneous failures totaled only 101 minutes. Alternating between them can raise availability from about 97% to 99.91%. Converted to cost, stacking two $20 plans amounts to about $1 per hour of downtime insurance. The article also rebuts Theo's citation of Anthropic's in-house git solution and publicly reveals that his own LLM router chose the same model for all 244 prompts. It ultimately recommends circuit breaking and status page subscriptions over "intelligent routing."