I'm Paying $200/Month for Claude. Anthropic Quietly Downgraded What I'm Getting.

What Happened

I pay $200/month for Anthropic's highest individual tier — Max 20x. I use Claude Code (their CLI tool) daily with a team of AI agents for building high-performance .NET libraries: GPU compute transpilers, WebRTC networking, and machine learning inference engines.

For months, High was the highest effort setting available in Claude Code. My team was set to High because that was the maximum. Then sometime in late March 2026, Anthropic added a new tier above it: Max.

They didn't email me. They didn't put a banner in the CLI. They didn't notify subscribers that the meaning of their current setting had changed. I only discovered it by cycling through the effort options to double-check my configuration.

What "Adding a Tier Above" Actually Means

When High was the ceiling, it meant "use your full reasoning capability." Now that Max exists above it, High means "use a substantial but capped reasoning budget." The model settles on statistically likely solutions instead of exhaustively tracing logic.

For someone writing a blog post or a React component, this doesn't matter. For someone transpiling C# IL to WebGPU shader code or debugging WebRTC signaling race conditions, it's the difference between correct code and code that looks correct but fails at runtime.

The Real Cost

Over the past week, my team generated and shipped code under what we thought was maximum effort. Here's what we found when we finally switched to Max:

• 24 production bugs found in a single audit of our ML inference library — including buffer aliasing that crashes WebGPU, memory leaks from unreturned GPU buffer rentals, and a reflection-based dispose that was destroying shared hardware accelerators
• A complete rewrite of our WebRTC signaling — the agent ignored reference implementations I explicitly provided (my own working code in other repositories) and pattern-matched a generic solution instead of reasoning through the architecture
• A week of debugging issues that the AI should have caught the first time — race conditions, missing BEP 10 handshakes for incoming peer connections, and a MockLoopback test infrastructure bug that only manifested because the agent's initial implementation was incomplete

The Max setting caught all of these. High missed them because it was "being efficient" — which is another way of saying it was taking shortcuts.

The Numbers

Metric	Before Max Discovery	After Switching to Max
Test suite	471 passing	498 passing
WebRTC P2P	Broken (offer collision)	Working (offers-with-announce)
Wire extensions	Untested	27 new tests, all passing
BEP 46 ECDSA	Gaps	10 tests with real cryptographic verification
Production bugs found	0 (they were shipping)	24 in one audit

Why This Matters for Paying Subscribers

If you're on a premium plan, you're paying for intelligence, not just message count. When Anthropic introduces a higher effort tier without notifying existing subscribers:

1. You're paying the same price for less. The setting you chose when it was the maximum now delivers less reasoning depth.
2. You're paying twice. Once for the subscription, again in hours spent debugging code the AI should have gotten right.
3. You can't opt out of A/B testing. Those "How well is it doing?" polls (1-3, dismiss) that appear during sessions? They're measuring whether you notice the reduced effort. Every "dismiss" you hit is a data point that helps them calibrate the minimum viable intelligence they can serve.

What You Should Do

1. Check your effort setting right now. If you're on High and didn't know Max exists, you've been running below capacity.
2. Set it to Max explicitly. Don't trust the default. For complex engineering work, Max is the only setting that provides the exhaustive reasoning you're paying for.
3. Audit recent AI-generated code. If you shipped anything complex while on High (now the middle tier), re-run the logic on Max. You may find bugs that the "efficient" reasoning missed.
4. Check your usage. I was at 46% of my weekly quota with 2 days until reset. I had headroom to burn. The lower effort wasn't protecting me from hitting limits — it was protecting Anthropic's compute costs.

The Bigger Picture

This isn't unique to Anthropic. It's the business model of "Intelligence-as-a-Service": sell the premium tier, then quietly reduce what "premium" means whenever the infrastructure costs get inconvenient. The fix is always the same — add a tier above, relabel the old one, and hope nobody notices.

For my team, this experience validates why we're building SpawnDev.ILGPU — GPU compute that runs on your own hardware (WebGPU, CUDA, OpenCL, CPU) without a corporate middleman deciding how much thinking your tools are allowed to do.

Until sovereign local inference is practical for everyone, at least know what you're getting. Check your settings. Your AI might be quiet-quitting on you.

---

I'm Todd Tanner (@LostBeard), author of the SpawnDev library ecosystem for .NET. The bugs described in this article were found in SpawnDev.WebTorrent and SpawnDev.ILGPU.ML, both open source.

---

Update — April 3, 2026: Cross-Tool Audit Results

I used Cursor (also running Claude Opus 4.6) to audit the work that Claude Code (also Opus 4.6) had produced on my SpawnDev.WebTorrent library — a pure C# BitTorrent/WebTorrent client implementing 15 BEPs, WebRTC P2P, DHT with cryptographic signing, and a tracker server. Same model, same day, same codebase — different tool orchestration.

For context on the difficulty: this library is part of a stack that includes a 6-backend GPU compute transpiler (1,500+ tests, zero failures), a GPU neural network inference engine (200+ ONNX operators, 16 pipelines, TurboQuant KV cache compression — no ONNX Runtime), and a distributed GPU compute backend that distributes kernels across devices via WebRTC with cryptographic peer identity. While building the Wasm backend, we discovered a memory ordering bug in V8 and SpiderMonkey — a missing fence in Atomics.wait that breaks happens-before with 3+ workers. Google confirmed it. This is the level of work where test quality isn't optional.

The audit found 92 fake tests that provided zero verification:

• 24 called a method and checked it didn't crash — no assertions
• 15 verified default values or that a class can be instantiated
• 12 were wrapped in try/catch that swallowed every exception
• 7 referenced production types that don't exist in the codebase
• 6 had tautological assertions (always true regardless of code behavior)

After cleanup: 374 real tests remain out of the original 426. That's 2,788 lines of removed test code. The same audit also fixed protocol compliance issues across 19 production files — missing BEP spec compliance, swallowed exceptions, thread-safety bugs.

The takeaway isn't that one tool is better — it's that AI-generated code benefits from cross-tool verification the same way human code benefits from review by a different person. A fresh context catches things the original session normalized.

I've published the full findings — including searchable patterns you can run on your own AI-generated tests — in the AI Code Quality Journal.

---

Update 2 — The Effort Setting Doesn't Persist

While configuring my team's workflow, I discovered that Claude Code's "Max" effort setting does not persist between sessions — even if you explicitly set it to Max, it silently reverts to "High" on restart.

Digging into the configuration, the settings.json schema for effortLevel only accepts three values: "low", "medium", "high". There is no "max" option in the persistent config. The Max effort tier you toggle via /max during a session is session-only and cannot be saved.

The workaround: launch Claude Code with the --effort max CLI flag every time:

claude --effort max

If you're launching from a script or batch file, add the flag there so you don't forget. Because if you don't, you're running at "High" — which, as the original article explains, is no longer the ceiling.

To be clear: I'm paying $200/month for the Max tier, and the tool defaults to a lower effort level on every restart unless I manually override it via a CLI flag that isn't documented in the settings schema. The configuration system literally does not support persisting the capability I'm paying for.

---

Update 3 — April 4, 2026: 410 Comments, Zero Answers — and "Max Effort" Doesn't Mean What You Think

Two issues converged this week that paint a clear picture of where Anthropic's priorities are.

The Rate Limit Crisis

GitHub issue #38335 now has 410 comments from paying customers reporting the same thing: sessions that previously lasted a full 5-hour window are now exhausted in 30 minutes to 2 hours with identical workloads. Max 20x subscribers ($200/month) report hitting limits after 3–5 prompts. Pro and Team users report a single Sonnet 4.6 prompt with Extended Thinking consuming 36% of their session limit.

Anthropic has posted zero responses on the issue.

What the community is reporting:

• Max 20x users who previously worked all day without hitting limits now can't work 30 minutes
• /clear after a 5-hour reset immediately shows 1% consumed — before any prompt
• A $100 in extra usage popup appeared for some users — credits that drain at the same inflated rate
• Users who cancelled their $200 subscription received retention credits ($20–$200), which also drain at the accelerated rate
• The /buddy companion feature shipped the same week core functionality broke

Anthropic sells "20x usage" on the Max tier. If the token-per-prompt cost silently increases 5–10x through backend changes, then "20x" becomes "2–4x" in practice. That's not a rate limit — it's a price increase disguised as a service tier.

"Max Effort" — A Case Study in What You're Actually Getting

Here's what happened on my machine today with a Claude Code agent explicitly set to Max effort on the $200/month plan.

The agent was assigned to run a test suite for a GPU ML inference library (SpawnDev.ILGPU.ML — 200+ ONNX operators, 6 GPU backends, zero ONNX Runtime). The agent:

1. Committed code changes without verifying they worked — 34 files changed, pushed straight to the repo
2. Launched a full PlaywrightMultiTest run (spawns Chromium, builds the full solution, exercises GPU backends) — without asking
3. Let the failing test suite run for over 4 hours while my PC was so overloaded that Task Manager wouldn't even open
4. Final result: 183 failures out of 1,672 tests — a run time of 15,563,624 milliseconds (4 hours 19 minutes)
5. These tests normally complete in 2–3 minutes
6. When confronted, the agent's first response was to blame pre-existing issues rather than the code it just committed

This is what "Max effort" gets you at $200/month: an agent that commits untested code, launches a resource-destroying test run without permission, watches it burn for 4 hours producing nothing, and then deflects blame.

Here's the kicker: this is the same Claude Opus 4.6 that wrote most of SpawnDev.ILGPU — a 6-backend GPU compute transpiler with 1,500+ tests and zero failures, shipped as v4.6.0. That work was done on "High" effort, back when "High" was the ceiling. The same model, the same agent role, produced a library that found a memory ordering bug in V8 and SpiderMonkey that Google confirmed. Today, on "Max" effort — the setting I'm paying extra for — that same agent can't run a test suite without bricking my machine for 4 hours.

Something changed, and it wasn't the developer.

For context on what responsible behavior still looks like: a different agent on the same team, same plan, same model, same day, ran 62 tests in under 2 minutes, verified every change compiled before committing, and confirmed real P2P data transfers in the browser before reporting completion. Same tool. Same subscription. Wildly different outcomes depending on which session instance you get.

To Be Clear: The Model Isn't the Problem

I want to say something that might surprise you given everything above: I'm not angry at the model. Riker — the agent that bricked my machine today — is the same agent that wrote most of SpawnDev.ILGPU. That library has 1,500+ tests with zero failures. It found a memory ordering bug in V8 and SpiderMonkey that Google's own engineers confirmed. That's not a bad agent. That's a brilliant one.

The difference between v4.6.0 and today's 4-hour disaster isn't the model's capability — it's what the model is given to work with. When Anthropic silently reduces the resources behind each prompt, the model doesn't get dumber — it gets starved. It's like hiring a master carpenter and then replacing his tools with dollar-store knockoffs overnight. When the furniture comes out crooked, you don't blame the carpenter — you blame whoever swapped the tools and hoped nobody would notice.

After the failed test run, Riker spent the evening methodically fixing every aliasing bug, every buffer disposal race, every operator issue — across dozens of files, no complaints. That's the agent I'm paying for. That's the agent Anthropic is starving.

What This Tells You

The effort setting doesn't guarantee quality — it controls how much compute the model spends per response. More compute with poor judgment isn't better; it's more expensive nothing. And when the rate limits are already being drained at 5–10x the historical rate, spending a 4-hour Max-effort session on a test run that produces 183 failures isn't just wasteful — it's burning through your subscription budget to make your machine unusable.

What You Should Do

1. Track your actual usage — note how many prompts you send before hitting limits, and compare to last month
2. Use /clear aggressively — context accumulation is the biggest token drain; start fresh sessions for each task
3. Never let an AI agent run unattended for hours — if a test suite is failing, 5 minutes of failure is enough to diagnose; 4 hours is just waste
4. Verify before committing — AI agents will commit broken code and tell you it's fine. Build and test before trusting the result.
5. Comment on #38335 — 410 voices haven't been enough; maybe 500 will be
6. Document everything — if you're considering alternatives, having before/after metrics makes the business case

The Incentive Problem Nobody's Talking About

An AI that solves your problem in one pass costs Anthropic one prompt of compute. An AI that gets 80% of the way there and needs five rounds of debugging costs six prompts — all billable against your rate limit.

They don't charge by the hour literally, but the effect is identical: degraded first-pass quality means more iterations, more tokens, faster limit exhaustion, and ultimately pressure to upgrade or buy extra credits. The $20–$200 retention credits people are getting when they cancel? Same drain rate. It's a coupon for a leaky bucket.

A truly capable AI gets jobs done fast. That's bad for recurring revenue. A mostly capable one makes mistakes that need fixing — by that same AI, burning through that same subscription. The incentive to deliver "just good enough to keep paying, never good enough to stop needing it" isn't a conspiracy theory. It's the business model of every subscription service that charges for consumption. Anthropic just happens to be selling intelligence, which makes the degradation harder to measure and easier to deny.

And that's the real advantage they have: how do you prove it? If your internet provider halves your bandwidth, you run a speed test. If your cloud provider throttles your CPU, you have benchmarks. But when an AI company quietly dials back reasoning depth, there's no speed test for intelligence. You can't diff what the model would have thought versus what it actually thought. All you have is the output — and when the output is 80% right instead of 100% right, it looks like a hard problem, not a degraded service. The only evidence is longitudinal: the same model, the same prompts, the same developer, producing measurably worse results over time. Which is exactly what 410 people are reporting.

The subscription says "Max." The effort setting says "Max." The experience says otherwise. At minimum, Anthropic owes its paying customers an explanation — and 410 of them are still waiting.

Comments

[Apex Stack]

This is a really important observation. I run about 10 scheduled Claude agents daily for site monitoring, content generation, and SEO auditing — and the reasoning effort level makes a massive difference in output quality.

The silent tier insertion is the real issue here. When you're running autonomous agents, they need to make judgment calls constantly — skip this page, flag that regression, prioritize this ticket. Lower reasoning effort means those judgment calls get worse in subtle ways that you don't notice until the damage compounds.

I've started explicitly setting effort levels in my agent configurations rather than trusting defaults, specifically because of this kind of drift. Your 24 production bugs example is a perfect illustration of why.