Claude Max 20x Hit 100% on Day Four. Why I Moved to Codex

On day four of my Claude Max 20x week, the usage meter hit 100%.

I had about four Claude Code sessions running side by side. Heavy use, yes, but not unusual for me. I had worked the same way with earlier Claude models, including Opus 4.5, without losing the rest of the week to the reset clock.

Max 20x costs $200 a month. I never expected unlimited usage. I did expect Claude's most expensive individual plan to last through my normal work week.

At the same time, features that older models used to implement correctly were taking more rounds of explanation and repair. I was burning extra turns to reach the result I used to get on the first attempt. Four days of quota would have been easier to accept if those four days had produced more finished work. They did not.

That combination ended the subscription. I cancelled Claude Max and moved my coding work to Codex.

What I know, and what I only suspect

I still cannot tell whether Anthropic actually made any older model worse. What I can say is that whenever a new model came out, the previous version felt noticeably less capable in my sessions. Prompt drift, Claude Code updates, longer projects, selective memory, or my own rising expectations could all create that impression. I have no evidence of deliberate degradation.

I did not need to settle that question before cancelling. I only needed to decide whether the product was still worth $200 for my work.

Opus 4.7 was the release where my patience ran out. Anthropic reported broad benchmark gains over Opus 4.6, and early testers quoted on the launch page reported improvements too. My correction load went up. I was not seeing those improvements in my own repositories, which was what I had to base the subscription on.

The quota itself is hard to plan around. Anthropic says usage changes with conversation length, complexity, enabled features, model choice, and effort. Max 20x is described relative to Pro usage per session, while the plan also has a weekly limit and may receive other caps. There is no fixed weekly Token allowance that tells me how much engineering work $200 will buy.

Opus 4.7 may also consume the allowance differently. Anthropic says the same input can become roughly 1.0 to 1.35 times as many tokens under its updated tokenizer. Higher effort produces more output, and Claude Code made xhigh the default for Opus 4.7. That does not account for every point on my meter, but it gives me a plausible reason for at least some of the faster burn.

Whatever the cause, the bill and the correction work were mine. The meter told me when I had run out; it did not tell me what one accepted implementation would cost.

Codex felt bare at first

My first reaction to the Codex TUI was that something was missing. Claude Code had trained me to expect a status line and a larger set of polished commands. Codex gave me a very clean screen and a /status command I had to remember to open.

For development, the pieces I cared about were already there: Plan mode, repository tools, and --yolo. I run --yolo inside containers, where I have already limited the blast radius. The interface was plain, but I could plan a change, edit the code, run the checks, and see what happened.

I had used my Golden CLAUDE.md for a long time, so I copied those rules into AGENTS.md. They tell the agent to read before editing, state risk, keep the patch small, verify the result, and stop treating confidence as evidence. Codex had the same working contract I had already been refining with Claude.

GPT-5.4 was the part that made me a fan. It got to the point. It did not spend a paragraph comforting me before doing the work, and it followed the plan more closely than I had come to expect. When I corrected a step, it usually stayed corrected.

I started running five to eight sessions in parallel, sometimes around the clock. Close to the weekly reset, the meter would still show 30%, 40%, or even 50% remaining. GPT-5.5 behaved similarly even though I used xhigh most of the time. I kept feeling that I had failed to push the subscription hard enough.

Those percentages describe my account and my mix of repositories. They are not a controlled provider comparison. In my actual week, though, Codex let me finish more work before quota management took over the schedule.

Sol was the first Codex model I had to ration

GPT-5.6 Sol at max is a token-draining monster. It is also very smart and very slow.

The detail in a Sol plan can be excellent. Letting it implement every line felt wasteful, especially once I saw the weekly meter move. I wrote more about that tension in my review of what AI benchmarks actually measure. This was the first Codex model that made me ration where I used it.

I settled on Sol Max for planning and GPT-5.5 for implementation. The split worked, but Codex made me operate it manually. Claude Code has /model opusplan, which can use Opus for planning and Sonnet for execution. The current Codex config reference includes plan_mode_reasoning_effort, but no equivalent Plan-mode model setting. After leaving Plan mode, I have to switch the model myself.

GPT-5.6 Terra Max was my next implementation model. It was capable enough, but I would occasionally hit a model-capacity message. Those messages had an annoying habit of appearing after I went to bed, so a goal could sit idle for hours before I saw it.

I knew Luna existed and had mostly ignored it. Cheap implementation models had burned me before. Then OpenAI cut its API price. At the GPT-5.6 launch, Luna cost $1 per million input tokens and $6 per million output tokens. The current price is $0.20 and $1.20, an 80% drop. API pricing is separate from my subscription quota, but the cut was enough to make me try it.

I was wrong about Luna

My skepticism came from a real failure pattern. I had tried using Opus to plan and Sonnet to implement. Opus could produce a solid plan, then Sonnet would misunderstand one boundary, improvise around an acceptance check, and send the change south. Anthropic now recommends Opus for planning and Sonnet for execution as a common setup. It may work for other people. I had stopped trusting the cheap model in that role.

I expected Luna Max to repeat the same failure. It did not. Sorry, I was wrong about the cheap model.

The Artificial Analysis comparison currently gives GPT-5.6 Luna Max a 52 on its Intelligence Index and GPT-5.4 xhigh a 53. Luna is also faster and much cheaper in that comparison. One point on a composite benchmark does not make them interchangeable, but it explains why Luna often feels closer to GPT-5.4 than its price suggests.

The other reason is the job I hand it. Sol has already investigated the repository and written the plan. Dense-Mem has supplied decisions and project knowledge that the session would otherwise need to rediscover. Luna receives the file list, existing patterns, constraints, execution order, and acceptance checks. It has less room to invent the wrong solution.

This is how my 1+1 hypothesis now works day to day: the stronger model narrows the problem, then the cheaper model implements inside those boundaries. Luna can still get a vague step wrong, so its output goes through review and tests before I accept it. Even with that cost, it has brought back some of the hope I had lost in cheaper models.

The stack I use now

Stage	What I use	What can go wrong	What I check
Context	Dense-Mem plus the repository	An old decision can distort the task	Compare recalled context with current code and requirements
Planning	GPT-5.6 Sol Max	A detailed plan can target the wrong goal	Review scope, risk, files, and acceptance criteria before implementation
Implementation	GPT-5.6 Luna Max	An ambiguous step can invite the wrong pattern	Keep the task bounded and run checks after meaningful changes
Review	Ten to fifteen agents using Qwen, MiMo, GLM, and other model families	Reviewers produce noise and confident false positives	Trace each finding back to code and intent instead of counting votes
Verification	Tests, linters, builds, and targeted runtime checks	A green suite can miss behavior it never exercises	Test real logic and acceptance criteria rather than mocked success

ultra is not my style. I see too many agents doing things on my behalf without enough control over who is doing what. I would rather choose the planner, bound the implementer, and decide which review agents receive the result.

I usually run ten to fifteen review agents from what I casually call "random models": Qwen, MiMo, GLM, and others. By "random," I mean that I mix model families instead of relying only on GPT. I still trace every finding back to the code. A different family may catch a GPT blind spot, which is the argument I made in The Multi-AI Thesis, but ten agents can also give me ten bad reviews. Tests remain the evidence when the behavior can be tested.

Why I do not call this vibe coding

I dislike the phrase "vibe coding" for this kind of work. It sounds like someone is prompting a system they do not understand and accepting the result because the demo looks right. That is not what I am doing.

The agents write a lot of the code. I decide what the system should do, which tradeoffs I will accept, and what proof is enough to ship it. I read the plan, inspect review findings, and make the tests exercise the behavior I care about. When the result is wrong, I own it.

I am not loyal to Codex. If Claude becomes the better tool for this workflow again, I will use it again. I cancelled because $200 was buying fewer accepted results, more correction work, and a weekly limit I could not plan around.

The agents do most of the typing now. I still choose the context, divide the work, and decide when the result is done. "Agentic coding" is the least misleading name I have found for that.