Did anyone else got their weekly usage reset today ? I was at 50% and got a weekly reset today, but my sub was created 2 days ago.

There are plenty of posts everywhere complaining about usage limits lately, and honestly, I get it.

Usage allowance in Codex took a nosedive a few weeks ago, and I don’t think it’s ever coming back. This feels like the natural direction of the space: over time, we’ll probably keep paying more for the same amount of usage.

So yeah, be prepared for that.

I created 4 ChatGPT Plus accounts, and it still wasn’t close to enough for what I’m doing. Then I created an OpenCode Go $10 account to use Kimi, burned through the monthly allowance fast, and ended up with 3 Go accounts. Then I created a Cursor $20 account, burned through the Composer 2.5 monthly allowance in 3 days, then created another Claude $20 account and realized it gave roughly the same usage as a ChatGPT Plus plan right now.

But what did work better for me was splitting the work by model strength and cost.

My current setup

Builder

Use a cheap workhorse model for the actual building/coding work.

For me:

• DSv4 Flash
• via OpenCode Go
• around $10/month (it gives A LOT of DSv4 Flash usage)

DSv4 Flash is unbeatable as a cheap builder. It gets a lot done for the money, but you definitely don’t want it working unsupervised on important/large projects.

Reviewer / planner

Use a medium-tier model for the first review and planning rounds.

For me:

• Composer 2.5
• via Cursor $20 plan

Composer 2.5 is solid all around. It can plan, review, and catch a lot of the obvious issues before you spend your best model’s usage.

Final reviewer / specs / architecture

Use the high-tier model only where it matters most.

For me:

• Codex 5.5 low (best with xhigh, but your usage will be quite a lot higher)
• via one ChatGPT Plus account

A single $20 ChatGPT plan will probably last the whole month if you stop using it as the main builder and reserve it for final review, planning, architecture, and specs and rely on 5.4 low for taks that don't require the absolute top tier, 5.5 low is better but spends 2-3 times more usage on the same settings.

The workflow

The basic idea is:

High-tier model → cheap builder → medium reviewer → high-tier final reviewer

Or more specifically:

1. Use the high-tier model to scaffold the blueprint, milestones, task list, architecture, and implementation plan.
2. Offload the actual building/coding to the cheap model.
3. Use a medium model for the first review rounds.
4. Send the result back to the high-tier model only for final review, final planning, specs, or deeper architectural checks.

You’ll need more review rounds when using a cheap builder, but it’s still much cheaper than burning your best model as the coder for everything.

My main takeaways

• Don’t use your high-tier model as the main coder/builder on large projects unless you’re on a $200 plan or running multiple accounts.
• Use the expensive model for the parts where intelligence matters most: planning, architecture, final review, and specs.
• Use cheaper models for the repetitive implementation work.
• Composer 2.5 is a solid all-around choice, even for planning.
• DSv4 Flash is an excellent cheap workhorse, but it needs supervision.
• The trick is not finding one perfect model. It’s building a workflow where each model does the job that makes the most financial sense.

That’s the only setup I found that actually stretches usage without exploding the monthly cost.

So, after being away from Claude for about four months (basically since the Opus 4.6 era), I resubscribed today and was quickly reminded why Codex with GPT-5.4/5.5 pulled me away from Claude in the first place.

Sonnet 4.6 is incredibly lazy and tends to do very shallow work. Opus 4.8 is more thorough, but it's still not on the same level as GPT-5.4 or GPT-5.5. It also retains many of the same ADHD-like tendencies I see in Sonnet—just to a lesser extent.

What surprised me most was that one of the prompts I use in my agentic workflow—a prompt that DeepSeek V4 Flash, MiniMax, Codex, and Composer have never failed to understand—completely confused Opus. Instead of executing the task, it responded with: "There's nothing being asked here, so there's nothing to do."

The prompt contained a link to a document with multiple clearly defined requests. Opus didn't even bother reading it. When I pointed that out, it replied with the usual: "My bad! I should have..."

I'm glad I only subscribed to the $20 plan. I might keep it around for some frontend design work, but that's probably it.

In my experience, Opus (via Claude Code) still leaves significantly more half-baked features and incomplete components behind than Codex.

Claude itself about the implementation he did on one of my requests:

"So the earlier commit wired up every feature, but several are hidden, half-implemented, or visually broken in the running app — the gap was integration/CSS/UX, not missing logic."

yepz... pretty much what I used to loose my mind over back then, still haven't changed.

I've built the first part of the app in question — up to M39, Milestone 39, out of 165 milestones total — using a GPT-5.5 xhigh builder + GPT-5.5 xhigh reviewer loop, while the good old /goal and forget was working.

But now Codex usage limits are hitting hard. Even with 4 Plus accounts, it wasn’t enough, so I picked up an OpenCode Go account and Cursor accounts.

I was hesitant to rely on Chinese models because they weren’t that good in the past, but I started using this workflow:

• Codex GPT-5.5 xhigh as app spec writer: blueprint, milestones, and initial implementation
• DeepSeek V4 Flash as builder: almost infinite usage on OpenCode Go
• MiniMax M3 as reviewer: 3x usage on OpenCode Go, so it’s cheap to run
• Kimi 2.7 Code as second reviewer: this is expensive and burns OpenCode Go fast
• Codex GPT-5.5 medium as final reviewer: impossible to use 5.5 xhigh with Plus accounts right now

I was surprised that by the time Codex did the final review, although it still found extra issues, there usually wasn’t much left. Usually 2 back-and-forth rounds with DeepSeek V4 Flash solved most of it. So the cheaper multi-model stack seemed to get me most of the way there.

I got intrigued and asked: “How well will these models fare against GPT-5.5 on a code review task on my codebase? Which model gives me the best bang for the buck?”

So I decided to benchmark several models against the exact same review task: same codebase, same milestone, same reviewer prompt.

Result from this M58 task, sorted by severity points:

Rank	Model	Score	Severity pts	Cost	Critical	High	Medium	Low
1	Kimi 2.7 Code	88/112	94	$1.68	4	12	7	0
2	Composer 2.5 Fast	72/112	82	$0.59	4	10	5	0
3	MiniMax M3	70/112	80	$0.18	4	10	4	0
4	DeepSeek V4 Pro	68/112	80	$0.17	4	10	4	0
5	GPT-5.5 xhigh	58/112	76	$2.47	4	9	4	0
6	GPT-5.5 low	51/112	74	$0.98	4	9	3	0
7	Mimo 2.5 Pro	64/112	73	$0.18	2	11	6	1
8	Kimi 2.6	61/112	70	$0.42	3	10	3	0
9	Qwen3.7 Max	60/112	70	$2.70	3	10	3	0
10	GPT-5.5 high	46/112	68	$1.50	4	8	2	0
11	Qwen3.7 Plus	50/112	62	$0.20	3	8	3	0
12	GPT-5.5 medium	42/112	56	$1.73	4	5	2	0
13	Mimo 2.5	37/112	50	$0.02	2	7	3	0
14	DeepSeek V4 Flash	38/112	46	$0.02	1	8	3	0

The shocking part: Codex GPT-5.5 xhigh did not win. Kimi placed first, far ahead. Composer 2.5 Fast placed second, and MiniMax / DeepSeek Pro also beat 5.5 xhigh on this task.

The cost part was also surprising. GPT-5.5 xhigh cost around $2.47 for this run. Qwen3.7 Max cost even more, around $2.70. Meanwhile MiniMax M3 and DeepSeek V4 Pro both scored above GPT-5.5 xhigh on this task while costing around $0.18 and $0.17.

Caveat: this is only one milestone so far. I have up to M165 planned and will rerun this on other milestones. Also, even with the same prompt, harness/runtime differences may matter.

OBS: Severity pts means critical problems got more points than low-severity problems. That’s why GPT-5.5 xhigh found fewer total problems than Qwen 3.7 Max, but had a higher severity score.

OBS: No Claude models. I don’t feel like spending $100 only to run some benches on Claude Code. No GLM 5.1 or 5.2 either. In the past, I found that GLM 5.1 underperformed Kimi 2.6 and DS V4 Pro in code review tasks, and it’s also very expensive to run in OpenCode Go, so I left it out. GLM 5.2 is only available through API and is also expensive, so yeah, I’m not spending API prices to test it.

I published the full test results table with prompts but reddit won't let me post it here.

Update 1: Included Kimi 2.6 results

###### UPDATE 2: Adversarial review. ######

Some people reasonably pushed back that the original scoring could reward models that list more problems, even when some are false positives or irrelevant. Fair criticism.

So I asked another Codex GPT-5.5 xhigh to do an adversarial review of the reports.

This version keeps the true-positive score, but subtracts false positives and irrelevant findings. Penalties are not flat: they scale with the severity of the wrong/irrelevant claim. So a wrong “critical blocker” hurts more than a minor irrelevant nit.

Rank	Model	Findings	False positives	Irrelevant	Final	Precision
1	Composer 2.5 Fast	80	0	0	80	3.9
2	GPT-5.5 xhigh	80	0	0	80	3.8
3	Kimi 2.7 Code	78	-2	-1	75	3.4
4	MiniMax M3	78	-4	0	74	3.7
5	GPT-5.5 low	74	0	0	74	3.4
6	GPT-5.5 high	72	0	0	72	3.6
7	Qwen3.7 Max	73	-1	0	72	3.1
8	Qwen3.7 Plus	65	0	0	65	3.0
9	DeepSeek V4 Pro	64	0	0	64	3.3
10	GPT-5.5 medium	60	0	0	60	3.3
11	Mimo 2.5	60	-2	-1	57	2.2
12	Kimi 2.6	50	0	-1	49	2.6
13	DeepSeek V4 Flash	48	0	0	48	2.3
14	Mimo 2.5 Pro	50	-2	-1	47	2.5

The results show that the original scores stayed more or less consistent, but some models were more heavily penalized by the adversarial reviewer.

Final disclaimer: this is not a lab test. It does not have mathematical strength, and the reviewer/adversarial claims were not human-reviewed.

This was done on a 100k+ lines private TypeScript codebase, around one specific task: reviewing a milestone implementation. The milestone was written by GPT-5.5 xhigh, the implementation plan by Kimi 2.7 Code, and the code was built by DeepSeek V4 Flash.

One more caveat: the adversarial reviewer was a different model/run from the one that did my initial scoring. The initial scoring was done in ChatGPT, while the adversarial pass was done by Codex GPT-5.5 xhigh. So it classified some problems a bit differently, which adds some variance to the adversarial results.

There are signs Anthropic may be losing momentum, and I don’t think this is just a normal “cycle” issue. It looks more like they’re hitting limits before OpenAI.

Both companies are likely subsidizing usage (at least that’s what they claim), but OpenAI has more capital and compute, so it can absorb pressure better. It also seems to have fewer extremely heavy users compared to Anthropic’s ecosystem (e.g., Claude Code).

The real question is how each company responds to that pressure.

Anthropic’s approach appears to be silent degradation: optimizing models in ways that reduce cost, while also restricting usage (like limiting third-party harnesses). Opus 4.5 felt like a peak. Then 4.6 became more capable, but also more constrained due to these optimizations. The end result was arguably still better—especially with the 1M context—but you could already see the trade-offs.

With 4.7, the intelligence improved again, but the optimization push seems too aggressive. The model feels overly steered. I’m not an expert, but it likely relates to post-training choices. Combine that with Claude Code being increasingly tuned to constrain and optimize usage, and the overall UX starts to degrade.

On OpenAI’s side, 5.4 (xhigh) feels relatively unconstrained. But 5.5 shows signs of similar optimization pressure: it can be less thorough and tends to end tasks earlier. It’s not as pronounced, but it resembles the same “lazy” signature people associate with Claude.

Meanwhile, Chinese models are catching up fast. They don’t need to be frontier-level—just “good enough” at a much lower cost. I’ve been testing OpenCode Go with Kimi 2.5/2.6, DeepSeek v4 Max, and GLM 5.1 (though that one burns usage quickly). They’re not on par with models like Codex 5.3–5.5, but the gap has narrowed a lot.

At this point, a hybrid workflow already works: use cheaper models for most tasks, and rely on Claude or Codex as reviewers or for harder logic. You get acceptable results at a significantly lower cost.

Overall, these companies are walking a tightrope—trying to balance performance, cost, and user satisfaction. How they handle that trade-off will shape how this evolves.

What’s your take — is Anthropic actually hitting limits here, or is this just normal model iteration cycle?