I'm torn between Claude and Codex

I’m torn between Claude and Codex because each platform wins a different part of my work. Codex gives me more usable time, smoother controls, clearer responses, and better frontend results. Claude turns my multi-agent plans into finished changes much faster, which matters more when a feature spans several systems.

Part of the job	Claude	Codex
Architecture overview	My first choice	Strong, but loses focus sooner
Large-feature orchestration	Usually reaches the end first	Often expands into a much longer run
Frontend implementation	Reliable but often familiar	Better fit, spacing, and visual judgment
Written communication	Fable sees the system clearly	Sol usually explains it more plainly
Included usage	Fable stops at half the weekly pool	Resets have made the allowance feel much larger
Safety interruptions	More false positives in my work	Not perfect, but better calibrated for my tasks
Phone and desktop flow	Capable, spread across several modes	More coherent in daily use

The table is why I stay torn. Codex wins more individual parts of the experience, but Claude wins the large-feature work that takes the biggest blocks of my time. Neither model is clearly more intelligent in my use. The systems around them decide which one I open.

Why do I pay for both? Each wins work I need

I pay for both because Claude fits my large-feature workflow, while Codex is the product I prefer using for many smaller jobs. Dropping either one would remove something I use every week. That is an annoying answer when they are two of my largest recurring software expenses.

I have used coding assistants since the early GitHub Copilot days, including the period when using ChatGPT for code meant copying snippets out of a browser chat. For years, my stable setup was Claude Max 20x for coding and a cheaper ChatGPT plan for research. I tend to research both technical and personal decisions before I make them, and OpenAI’s research experience consistently suited me better.

GPT-5.6 changed the balance. Sol is roughly as capable as Fable 5 in my work, so I upgraded to OpenAI’s Pro 20x plan and kept Claude Max 20x. [4] [9] My usage is high enough that I have sometimes needed a second Claude Max subscription. When one plan burns faster or stops sooner, it changes how much work I can finish that day.

OpenAI’s allowance often feels more generous in practice. I watched three more global resets land from 26 August through 1 September 2026, on top of the reset campaign I covered in August. My read is that the celebrations also work as marketing for a model that can burn through usage quickly. The effect on me is simpler: the resets gave my account more capacity, and that makes Codex hard to leave.

What does Codex do better? Frontend work and daily use

Codex does better at the parts of daily work I notice immediately: first-pass frontend design, written explanations, remote control, and the way usage limits interrupt a task. It is easier to live with from one bounded job to the next, even though Sol does not always write better backend code.

Frontend work is the clearest quality difference. GPT-5.6 tends to produce layouts with better spacing, alignment, and visual hierarchy on the first attempt. OpenAI says the model improves frontend aesthetics and design judgment. [1] That supports the capability but does not compare Sol with Fable 5. My own use supplies the comparison: Codex is more likely to create a design that fits the existing product, while Claude more often returns a familiar template unless I describe the visual direction in detail.

I also find Sol easier to read. It usually explains a decision in ordinary language, even when the underlying work is technical. Fable gives me a better architectural overview, but its prose can still become harder to follow. This difference matters because the lead agent spends most of its time discussing trade-offs and reporting progress, not only writing code.

That ease carries over when I leave my desk. OpenAI documents remote access that lets a phone continue a Codex conversation running on a connected Mac or Windows machine. From the phone, I can steer active work and review approvals, diffs, and terminal output. [7] Codex also offers isolated cloud tasks, although the connected-host route is the one I use most. [21]

Claude covers the same ground through several modes. It can continue local sessions from a phone, launch desktop work through Dispatch, and run cloud sessions after the computer is turned off. [17] [18] [22] Both platforms cover the main use cases, but Codex presents them in a way I find easier to follow. Claude divides similar work among Remote Control, Dispatch, local sessions, and cloud sessions.

Usage limits sharpen the difference. OpenAI’s current documentation says local messages and cloud tasks on Pro 20x share a five-hour window, and weekly limits may also apply, so the plan is not weekly-only. It also says an active turn can continue after the account reaches a limit, subject to fair-use controls. [4] Claude can now wait and resume an interrupted task after a session reset. [20] In my use, the limit still feels more like a hard break at exactly the wrong moment. The exact reset rules matter less to me than whether today’s change reaches a safe checkpoint.

Why does Claude finish first? Its manager stays focused

Claude finishes my large features first because its orchestration matches how I divide software work. One capable model keeps the plan, makes decisions, and talks to me while separate agents research, implement, test, and audit. In my projects, Claude keeps that lead focused on coordination more reliably.

Anthropic calls the general pattern orchestrator-workers: a central model breaks down a task, delegates it, and combines the results. OpenAI documents the same basic pattern as manager-style orchestration. [14] [15] The name matters less than the separation: the manager holds the goal and decisions, while workers receive bounded jobs and return evidence.

Claude Code’s dynamic workflows make that division unusually explicit. Claude writes an orchestration script, starts parallel agents, and lets the runtime manage branching and intermediate results. Anthropic says one run can start tens or hundreds of agents over time, with up to 16 working concurrently when the machine has enough CPU capacity. [11] [12] I do not need hundreds, but I value that the lead conversation does not have to absorb every file read, command result, and debugging detour.

My version uses Fable 5 as the lead. It settles the architecture with me and writes the plan, then Opus agents implement bounded slices while other agents test and review them. Fable decides which findings deserve work and asks me when a change would alter the plan. I explain the implementation details in my plan-first Opus 5 workflow; the relevant point here is that Fable remains responsible for the whole result.

manager

• Fable 5 holds the goal, plan, decisions, and user conversation

delegates bounded work

workers

• research agents map the repository and open questions
• Opus agents implement bounded slices
• test and audit agents return evidence and findings

returns evidence

decision

• manager review accept, reject, redirect, or ask the user
• finished feature plan satisfied and checks passed

In Claude Code, Fable and Opus support a one-million-token context window, but the larger advantage is that worker details stay outside the manager’s conversation. [13] A large window still fills if every file read, agent log, and test result enters it. Dynamic workflows keep that detail separate and leave the manager’s remaining context useful.

OpenAI describes the same separation for Codex: the main thread should retain requirements and decisions while workers handle exploration, tests, and logs. [5] That is why I expected my workflow to transfer. In my runs, however, the main Codex agent does not stay in the manager-only role as consistently as Claude does.

Why does faster Sol finish later? Codex creates more work

Sol can generate text faster and still finish a large feature later because output speed measures only one part of an agent run. Most of the time goes into choosing work, calling tools, reopening questions, and coordinating workers. Faster text does not help when the agent creates extra work or revisits settled decisions.

Artificial Analysis measured GPT-5.6 Sol at 77.1 output tokens per second and Fable 5 at 66.9 in the compared maximum-effort configurations on 1 September 2026. [3] That roughly 15% throughput lead matches the feeling of watching Sol respond. It does not match my end-to-end results because Codex often creates more work for itself after the original implementation is already close to done.

Extra scope consumes Sol’s speed advantage

Much of the extra time comes from overengineering. I have to state very clearly that Codex should preserve the existing architecture, report unrelated findings without fixing them, and stop when the acceptance criteria pass. Otherwise Sol may add defensive layers, new helpers, or a subsystem for a problem that needed one focused change. I have measured the same tendency during audits, where Sol found far more possible issues than Fable but most did not survive triage.

Coordination adds another delay. In the Codex Ultra runs I used, the main agent had trouble staying in its manager-only role. It delegated work but then continued to inspect files, make edits, or reopen decisions while its agents were doing their own jobs. OpenAI documents Ultra as maximum reasoning with automatic delegation and says the main thread collects worker results. [5] [19] It does not promise that the main thread remains implementation-free. My attempts to enforce that boundary have reduced the problem without removing it.

More context and lower effort do not fix the loop

Long runs put more pressure on context, but enlarging the window has not solved the slowdown. My Codex status initially showed 272K tokens, so I changed model_context_window to one million in the configuration. OpenAI documents that setting, and Sol itself supports up to 1.05 million tokens. [6] [2] The 272K figure describes what my configuration displayed, not a universal default established by OpenAI. The larger window helps, but Codex still fills it quickly during a long multi-agent run. Once compaction begins, I am less confident that an early constraint will carry the same weight six hours later.

Long context is not free either. OpenAI’s API pricing charges prompts above 272K at twice the input rate and 1.5 times the output rate for the entire request. [2] OpenAI does not say that a ChatGPT Pro allowance uses those exact multipliers, so I do not apply that formula to my subscription meter. It does show why increasing a window is not the same as making long work efficient.

Lowering Sol’s effort setting has not solved the problem for me. Codex becomes somewhat faster, but planning and review quality fall much more than the run time improves. A goal does not fix it either. OpenAI describes goals as a way to keep working across turns toward a verifiable stopping condition, which is exactly what I want. [8] In my long runs, the goal keeps Codex active without helping it finish sooner.

What makes Claude harder to use? Limits and safety interruptions

Claude’s orchestration advantage comes with tighter limits and more false-positive safety interruptions. Its large-feature workflow suits me better, but I spend more time managing which model can still run and recovering when a safety check interrupts ordinary work.

The Fable cap is the most direct frustration. I pay for Max 20x, yet Fable can use only half of the weekly included allowance. [10] I understand why a provider might ration its most expensive model more tightly. That does not make the interruption fit my work. A large feature does not become less important when that smaller pool runs out.

Safety interruptions are worse because they break concentration without advancing the work. Anthropic acknowledged that Fable 5 was flagging benign requests during routine coding and debugging after its June 2026 release and temporary withdrawal. [16] I see fewer interruptions than I did at first. They still trigger more often than I expect on harmless work.

OpenAI also warns that GPT-5.6 safeguards can intervene on legitimate requests. [1] Codex is not free of false positives. In my projects, its classifiers have been better calibrated: I can usually understand why a dual-use request caused a pause, and ordinary development work is less likely to trigger one. That comparison comes from my projects, not published filter error rates.

These complaints do not outweigh the orchestration advantage. They explain why I keep looking across at Codex even after Claude wins another large implementation.

Which should I use, Claude or Codex? It depends on scope

I choose Claude when the feature needs repository research, an architecture decision, several implementation workers, and an independent audit. I choose Codex for bounded changes, frontend work, and sessions where I value the cleaner interface and larger practical allowance. For broad research, I still begin with ChatGPT rather than either coding harness.

That division is based on workflow, not a claim that Fable 5 is smarter than Sol. If I gave both models one small, clear task, I would trust either to produce strong code. The difference appears when a feature must be split into several dependent tasks and one conversation has to preserve the reason behind all of them.

Codex would become my default if its manager could stay out of implementation, control scope more reliably, use long context more efficiently, and bring a large run to a verified stop. Claude would become the easier single subscription if Fable’s included allowance were less restrictive and routine coding triggered fewer safety fallbacks.

For now, I keep paying for both. Claude is the place where I start a large feature because its orchestration reaches the finished state I asked for. Codex is the product I keep wanting to use because the rest of the experience is easier. Neither platform currently gives me Claude’s orchestration and Codex’s product experience in one workflow.