Anthropic Is Now Actively Enforcing TOS Violations Against Third-Party Claude Access
Anthropic Is Now Actively Enforcing TOS Violations Against Third-Party Claude Access
Forty-eight hours ago this was a “legal notice to one developer” story. It isn’t anymore.
Anthropic is actively enforcing TOS compliance against third-party tools that access Claude outside sanctioned channels. OpenCode was first — they received a legal notice demanding removal of Claude OAuth, and they complied. But that was the opening move, not the whole game. Enforcement is confirmed and ongoing. More tools are in the crosshairs. If you’ve built workflows on Claude via third-party integrations, this is no longer a “watch and see” situation.
Here’s what’s actually happening, what the new evidence shows, and what you need to do about it.
What Happened (Updated)
OpenCode had implemented Claude OAuth — a mechanism that let users connect their Claude access to OpenCode without going through Anthropic’s official API. It worked. People used it. Then Anthropic sent a legal notice demanding removal. OpenCode complied.
That was the story as of 48 hours ago. Since then:
GitHub issue #56960 has documented gateway resource degradation affecting OpenClaw and OpenCode integrations with Claude. This isn’t a developer complaint about a policy change — it’s technical evidence of deliberate capacity restriction targeting unofficial access patterns. The degradation is documented, repeatable, and consistent with an active enforcement campaign rather than a one-off legal notice to a single company.
Anthropic isn’t just deprecating OAuth. They’re actively pursuing TOS violations. The enforcement mechanism isn’t just legal notices — it’s technical degradation of unauthorized access paths, combined with legal pressure when that’s not enough.
OpenClaw’s 2026.3.28 release responds directly to this situation. The fact that the release addresses it tells you this is being tracked at the infrastructure level, not just as a news story.
The picture that’s emerging: Anthropic has decided that the unofficial access ecosystem needs to close, and they’re using every tool available to make that happen.
Why This Is Different From Normal Platform Policy Changes
Most platform policy changes are announced, give developers a deprecation timeline, and break things gradually. This is different.
The legal notice mechanism means a developer can go to sleep with a working product and wake up to a compliance demand with a short window to respond. There’s no public roadmap. There’s no “we’re deprecating this in Q3” blog post. You find out when you’re the one getting the notice — or when a tool you depend on quietly removes a feature because they got one.
The gateway degradation documented in GitHub #56960 is the other edge of the same sword. Before a legal notice arrives, access patterns can be technically degraded — throttled, rate-limited, or selectively broken in ways that look like reliability issues until you read the docs and realize it’s deliberate.
For an operator who built workflows on a tool that accessed Claude via OAuth, both paths lead to the same outcome: your workflow breaks, and you may not know why until after the fact.
The Pattern Is Bigger Than One Legal Notice
The OAuth enforcement doesn’t exist in isolation.
Claude session limits have been emerging at peak hours. If you’ve noticed your Claude-based tools getting throttled or erroring out during business hours, you’re seeing the same trend from a different angle. Anthropic is managing access — and the managed access benefits paying API customers and Anthropic’s own products, not the third-party ecosystem built around them.
Anthropic’s market position is “crystallizing,” as one analyst put it. They’re not a scrappy startup trying to get distribution anymore. They have a product people depend on. They have a business model to protect. They’re acting like it.
This isn’t surprising. Every platform that achieves dominance eventually tightens its grip on the ecosystem that grew up around it. Twitter did it. Apple did it. Google did it. The difference here is speed — we went from early warnings to active enforcement in weeks.
The question isn’t whether this will keep happening. It will. The question is what your exposure is.
What “Dependency Risk” Actually Means in Practice
Here’s a concrete way to think about it: draw a line between your business operations and Anthropic’s decisions.
If Anthropic changes pricing tomorrow, what breaks? If they remove API access for a category of use case, what breaks? If they send a legal notice to the tool you rely on most, what breaks?
Most operators haven’t mapped this. They adopted Claude integrations because they worked, not because they stress-tested the dependency.
The OpenCode situation is useful precisely because it’s visible. Someone else got the notice. Someone else documented the degradation on GitHub. You got a free warning about the risk.
The harder question: how many tools in your stack have the same exposure and just haven’t been targeted yet?
What to Do Right Now
Here’s the practical breakdown — what’s urgent this week versus what you can address over the next month.
This week:
Audit which tools access Claude via OAuth or unofficial methods. This is the immediate action. Go through your stack and identify every tool that connects to Claude in a way that isn’t “I have an API key from Anthropic and this tool uses it directly.” If a tool logs in to Claude on your behalf, accesses your Claude account via OAuth, or uses any non-API access pattern — it’s at risk.
Check your API key situation. Are your tools using API keys you hold, or are they holding keys on your behalf? If you don’t know the answer, find out. Tools that hold keys on your behalf are one TOS enforcement action away from having their access revoked — and taking your workflow with it.
Have a migration plan for your highest-dependency tools. For each at-risk tool, know what you’d use instead. You don’t need to switch today, but you should know the path before you need to walk it.
In the next 30 days:
Migrate high-risk integrations to direct API access. Where possible, move to tools where you hold the API key directly and the tool just uses it. This is the most durable pattern — Anthropic’s enforcement actions target the access mechanism, not your direct API credentials.
Evaluate alternative model providers for critical workflows. If Claude is a single point of failure in your operation, it shouldn’t be. Practical cost comparison as of early 2026:
- OpenAI (GPT-4.1, GPT-5 series): Comparable capability to Claude Sonnet for most tasks, slightly higher cost at scale. Direct API, well-documented, large ecosystem.
- Google Gemini: Strong for long-context tasks, competitive pricing. Direct API available.
- Open source via OpenRouter: Significant cost reduction (often 10-20x cheaper for many tasks) with acceptable quality for routine automation. Models like Qwen and others have improved substantially.
- Local models: Near-zero marginal cost if you have the hardware. Quality gap has narrowed considerably for non-frontier tasks.
You don’t have to abandon Claude. You should have a secondary provider configured and tested so enforcement actions against your primary tools don’t halt your operation.
What can wait:
Full infrastructure migration doesn’t need to happen on an emergency timeline — but the window to do it deliberately (rather than reactively, when a tool you depend on suddenly stops working) is now. Don’t let “no current emergency” become “still haven’t done it” in six months.
There Is an Alternative Architecture
Local execution doesn’t solve every problem. It won’t give you Claude’s models if you want Claude’s models. But it changes the dependency structure.
When your AI agent runs locally — on hardware you own, using API keys you hold directly — there’s no intermediary that can receive a legal notice and break your workflow overnight. The connection is between you and the model provider, not between you, a third-party tool, and the model provider.
This is why the move to local-first infrastructure isn’t just a privacy story or a performance story. It’s a control story.
OpenClaw takes this approach: agents run on your hardware, you hold your own API keys, and no one can send OpenClaw a legal notice that breaks your workflow. OpenClaw isn’t sitting in the middle of your connection to Claude. The 2026.3.28 release addresses the infrastructure implications of exactly this enforcement situation.
That’s not a sales pitch — it’s the actual architecture. The value of that architecture just became a lot more concrete.
The independent operator ecosystem built real value on top of Claude’s capabilities. That’s not going away. But the terms of that relationship are shifting fast, and the shift isn’t in your favor.
Know your exposure. Reduce it where you can. Don’t wait for your own workflow failure to prompt the audit.
We run Steward HQ on OpenClaw — local agents, direct API access, no intermediaries. The Free AI Operator Kit has the full setup guide, API key management templates, and the operational patterns we use to keep our workflows running regardless of what any single provider decides. No fluff — just the configs we actually use.