I've been paying for Claude Max since December. Last week I hit a wall I didn't expect.
Not a usage cap. Not a model deprecation. A policy.
I want to write this down because the version of it I keep rehearsing in my head is either too angry to be useful or too measured to be honest, and the truth is somewhere I can only get to by actually writing it out.
Where I'm writing from
I have been paying for Claude Max out of my own pocket since December. Not because I had to — because by the time my Pro plan started feeling tight, the math worked out for the way I use the model: long sessions, large repositories, real engineering work. I am the customer Anthropic's marketing copy is written for. I hit the limits regularly. I plan around them.
I also spent the first months of 2026 evangelizing internally. Talking to my team. Talking to the people who hold the budget. Building a case that this wasn't a fad and it wasn't a coding-copilot toy — that we should commit, and pay for, a serious platform bet on Claude. I made that case. I won it. We paid. I have a second account on the company plan and I hit those limits too.
To save you having to take "real engineering work" on faith: my Claude Code history has more than two thousand prompts in it. Sixty-something active sessions across roughly thirty project directories, split across a WSL2 box and a Windows host depending on what the task needs. I have written my own hooks layer — session init, status line, PR-size check, privacy/scout blockers — and my own plan-driven workflow on top of Claude Code, with conventions like /plan, /fix, and /cook for moving work from design to execution. I have custom skills, a plan-and-task directory structure that survives across sessions, and memory files I have edited by hand to capture hard-won lessons that take real time to re-learn. This is not a chatbot for me. This is infrastructure I have invested months of work into.
That is the position I'm writing from.
What happened
Last week I started testing two open-source tools as the next step in our AI workflow.
Hermes Agent — an MIT-licensed agent framework from Nous Research. Persistent memory, scheduled automations, isolated subagents that can spawn their own terminals and RPC scripts, real sandboxing across local / Docker / SSH / Singularity / Modal backends. Lives on a server. Talks to you over Telegram, Slack, Discord, email, CLI. Designed exactly for the kind of always-on developer agent pattern that mature AI workflows are converging toward.
OpenCode — open-source AI coding agent that runs in your terminal and ships with a paired web editor. The terminal experience is fast and feels native. The web editor is good enough that I don't miss opening VS Code in another window. The whole thing feels like what an AI coding tool should be when it isn't tethered to one vendor's specific UX choices.
Both of these tools support a wide range of providers. Anthropic API key, OpenAI, OpenRouter, local models, whatever. They are not Claude-specific. I could have pointed them at any of those and they would have worked fine.
I chose to point them at my Claude subscriptions — personal Max and the company plan — because that is what I am already paying for. That is the model I want to use. That is the supported pattern in the tools, and that is the pattern that was working two weeks ago.
It does not work anymore.
HTTP 400: Third-party apps now draw from extra usage, not plan limits.
Ask your workspace admin to add more and keep going.
That is the literal message. The endpoint is api.anthropic.com. The credentials are valid. The model is available. The request is well-formed. The block is a policy decision: requests from clients Anthropic does not ship are no longer considered "subscription usage." They get pushed into a separate prepaid pool that has to be topped up out of a different budget line.
The defense, and why it doesn't hold up
I know what the defense sounds like. I have been thinking about it for a week. It goes something like:
Agents and third-party tools hit our infrastructure harder than chat users. To protect plan limits for everyone, heavier use cases need to draw from a separate, metered pool.
If that were true, the answer would be per-account caps, metered overage, or a tiered power-user plan. None of that is what shipped.
What shipped is a categorical block based on which client originated the request. Here is the cleanest way I can put it:
The Claude Code instance I run, with my custom hooks layer and my plan-driven workflow and my multi-step orchestrated tasks — the thing that already hits the API harder than any chat user — works fine against my subscription. Hermes Agent, doing the same kind of agentic work, gets a 400. OpenCode, doing the same kind of agentic work, gets a 400. Same model on the other end. Same kind of load. Same kind of requests. The discriminator is not how heavy the workload is. The discriminator is whether Anthropic ships the client.
That isn't a compute policy. That is a UI lockdown policy dressed up in compute language.
Either the limit is about compute, in which case why am I allowed to burn through it in Claude Code and the browser all day? Or it isn't about compute, in which case let's call it what it is.
What I was actually building toward
This is the part I keep coming back to, because it is the part that stings.
The plan-driven workflow I have built on top of Claude Code already approximates a primitive version of what I want. Plans live in directories. Tasks live in files. The /plan and /cook cycle moves work from design to execution. I drive it by hand because that is what the tool currently supports.
The next iteration is the obvious one: give it real parallelism. A Kanban-style surface where I triage incoming work — bugs, features, infrastructure tasks, architecture reviews — and auto-decompose each item into subtasks. Spawn parallel Claude sessions for the subtasks. Watch them work. Have results flow back to the board. Have the board talk to me on Slack when something needs human attention.
That is not an exotic idea. That is what every team doing serious AI-augmented engineering work in 2026 is converging toward. Hermes Agent's subagents with their own conversations and Python RPC scripts is literally a building block for it. OpenCode's terminal + web editor is the per-task workspace. The pieces exist. They are open-source. They are MIT-licensed. The thing I wanted to build is a weekend project, not a research moonshot.
Under the current policy I cannot build it on the subscriptions I already pay for. Not "I can but it's awkward." I cannot. The 400 is categorical. To build it I have to fund it out of a separate per-token API budget that scales linearly with how useful I make the system. The more work I successfully automate, the more it costs me — on top of two subscriptions I am already paying for, both of which are sold as "use Claude."
The structure is: the cheaper the use case, the more access you get. The more valuable the use case, the more it costs you, and it costs you in a different budget pool that probably requires a different procurement conversation. That is a pricing model that disincentivizes exactly the customers most willing to push the product forward.
What this actually signals
Set my situation aside for a minute. Look at what the policy says to anyone building on top of Claude.
The rules under which you bought in can be unilaterally rewritten. There is no migration window. There is no grandfather clause. There is no developer or agent tier that lets a legitimate open-source project run against a subscription on terms anyone could plan around. The decision about what counts as "real" subscription usage and what counts as "third-party app" usage is Anthropic's, and only Anthropic's, and it can change.
If you are an open-source maintainer building agent infrastructure on top of Claude, what you have just learned is that your project's economic viability for your users is contingent on Anthropic continuing to consider your category acceptable. That is not a stable foundation for an ecosystem.
What would have been fine
I want to be specific here, because "be less stingy" is not an argument.
A grandfather clause for accounts that were using these patterns before the cutover would have been fine. A migration window with a clear date would have been fine. A developer or team tier that lets a subscription cover modest custom and open-source agent usage with sane caps would have been fine. An honest framing that said "agents are heavy and we are pricing them separately, here is the new structure, here is when it takes effect, here is what we are doing to ease users who were already building on the old terms" would have been fine.
None of that is what shipped. What shipped is a quiet reclassification — quiet enough that the first I heard about it was a 400 error in a terminal — that turned existing usage patterns into a new billing pool overnight.
That is the part I am writing about. Not the policy itself. The way it was rolled out.
My actual ask is small, and I think it's the ask a lot of paying customers would echo if they were given a chance: let me use the subscription I am already paying for from Claude Code, from Claude Desktop, and from whatever third-party harness I prefer — the way I used to be able to. Stop deciding for me which client gets to count as "real" usage. I would happily keep paying Max. I would probably upgrade to a higher tier if one existed. I know plenty of people who would do the same.
The policy Anthropic shipped instead reads, from where I'm sitting, like this: get as much money as possible out of the customers we already have, and don't worry too much about whether new ones show up at all — as long as the ones who do show up come through our front door and not anyone else's. I do not think that is the company Anthropic wants to be. I am writing this in part because I do not want to believe it is.
Where I've landed
I'm not switching providers. The model is still the best one for the work I actually do, and the alternatives don't quite match it yet for the workloads that matter most to me. Anthropic knows this. It is, presumably, part of the calculation.
But the trust is different now. Last month I would have told you that betting on Claude was a safe long-term technical decision. This month I'll tell you the model is excellent and the platform terms can change under you without warning. Those are not the same recommendation, and the difference will show up in every internal conversation I have about AI tooling for the rest of the year.
I was the champion. I am still, for now, using the product. I am writing this because I think the people who shipped this policy may not fully see what they spent to ship it the way they shipped it.
If you work at Anthropic and you read this: the version of you I made the case for, when I was telling my team this was the company to bet on, is not the version of you that shipped the third-party app reclassification. I hope the first version is the one that decides what comes next.




Comments
No comments yet. Be the first to share your thoughts!
Leave a Comment