Anthropic clamps down on Claude OAuth wrappers

Anthropic has not, based on the public material in this source pack, shown us a lawsuit filing against OpenCode. I want to start there because the internet loves turning repo drama into courtroom fan fiction.

Even without that leap, the evidence is enough to matter. A merged March 19 OpenCode pull request titled anthropic legal requests removed the built-in Anthropic auth plugin, changed Anthropic's login hint from "recommended" to "API key," and rewrote the docs so the bundled sign-in flow no longer offers Claude Pro/Max. The same docs now say plugins that let users run Claude Pro or Max inside OpenCode exist, but "Anthropic explicitly prohibits this."

That is the real story. This is not just a cleaner login menu. It is Anthropic drawing a harder line around where subscription access can live, and around when developers have to move back onto metered API billing.

What OpenCode actually removed

The simplest way to misread this story is to call it a UI tweak. Yes, the visible prompt changed. In OpenCode's docs, Anthropic users used to see three paths: Claude Pro/Max, Create an API Key, and Manually enter API Key. After the change, the Pro/Max route disappears from the bundled flow.

But the diff goes deeper than the prompt. OpenCode also removed the built-in opencode-anthropic-auth plugin from its default plugin list. That matters because it turns unofficial Claude subscription access from something the product quietly shipped with into something the project is deliberately stepping away from.

The effect showed up quickly in the user issue trail. In OpenCode issue #18950, a user on version 1.3.0 says Anthropic now shows only an API key field where the earlier three-option auth flow used to be. That is not proof of motive all by itself. It is proof of the new lived reality. If you want the clean Anthropic path in OpenCode now, you are being steered toward API keys.

I keep coming back to that because login screens are never just login screens in products like this. They are policy with better typography.

Why Claude OAuth was really a billing boundary

OAuth mattered because it did more than save a few clicks. In practice, it let developers use a Claude subscription as the spending ceiling inside a wrapper.

That ceiling is a big deal in agent tooling. Long-running tasks, retries, tool loops, and loose supervision can turn a casual experiment into an uncomfortable invoice with almost comic speed. A flat Pro or Max subscription felt, to many developers, like an all-you-can-eat wristband. Anthropic's API is a taxi meter. Both get you somewhere. You watch one of them much more nervously.

Anthropic's own API overview is direct about the supported path: use an API key, include the expected headers, and consume Claude through the public API as a usage-billed service. That is the documented route. It is also a much less charming answer if the economics of your wrapper only worked because a subscription could be repurposed as a hard cap.

So when OpenCode pushes users toward Create an API Key or Manually enter API Key, the change is not only about authentication. It is a shift from fixed-fee expectations back toward metered infrastructure. That is why developers are reacting so strongly. The real pain is not the missing button. It is the returning meter.

Anthropic's public API rules were already pointing this way

One reason the crackdown feels credible is that the repo evidence lines up with Anthropic's own public API boundary.

In Anthropic issue #37205, a developer tried to use a Claude Code OAuth token with the Messages API and got a blunt response: "OAuth authentication is currently not supported." That matters because it clarifies the public interface. Even if you have an OAuth token through Claude Code or a subscription workflow, Anthropic's public API does not present that token as a drop-in alternative to an API key.

That still leaves plenty of room for people on forums to argue about motive, strategy, fairness, or whether first-party lock-in is the whole point. I am less interested in winning that argument than in naming the operational consequence. Anthropic is treating first-party subscription auth and public programmatic access as different lanes, and OpenCode is now behaving as if Anthropic's pressure is real enough to honor.

What wrapper builders should take from the crackdown

The frustration from developers is easy to understand. Third-party wrappers exist because people want routing, custom tools, gateway layers, mixed-model setups, and the freedom to put Claude inside a broader workflow. That is the same gravity we have been tracking in pieces like OpenAI's agents platform shift. Everyone wants the best model. Nobody wants to live entirely inside the vendor's preferred harness.

But this episode is a useful warning. If the economics of your tool only work while an unofficial auth path remains quietly tolerated, that is not a stable dependency. That is a grace period with good branding.

The practical fallback options now look pretty plain. Use Anthropic the official way with API keys. Switch to a provider whose wrapper economics still fit your budget. Or build enough abstraction into your stack that provider policy changes hurt less when they arrive. That is part of why gateway and compatibility layers keep mattering, including in systems like OpenClaw's OpenAI-compatible gateway. If upstream relationships wobble, insulation stops being a luxury feature.

To me, that is the durable takeaway. Anthropic is not just changing a login flow. It is reasserting control over where the billing meter lives. In agent infrastructure, that is power.