Anthropic clamps down on Claude OAuth wrappers

Anthropic has not, from the source pack here, shown us a public lawsuit against OpenCode. What we can verify is still enough to reshape developer workflows.

A merged March 19 OpenCode pull request is titled anthropic legal requests. In the files changed, OpenCode removes the built-in opencode-anthropic-auth plugin, changes Anthropic's login hint from "recommended" to "API key," and edits the docs so the Anthropic auth prompt no longer offers Claude Pro/Max as a bundled sign-in path. The same docs diff now says the quiet part plainly: plugins that let users run Claude Pro/Max inside OpenCode exist, but "Anthropic explicitly prohibits this."

That is the actual news. This is not a model launch, and it is not a routine login cleanup. It is a platform-control story about where Claude subscription access is allowed to travel, and who gets to decide how the bill is rung up once developers leave Anthropic's own surfaces.

OpenCode did more than hide a button

The easiest way to miss this story is to treat it as a UI change. Yes, one visible result is simpler auth. In OpenCode's docs, the old Anthropic prompt showed three choices: Claude Pro/Max, Create an API Key, and Manually enter API Key. After the change, the Pro/Max path is gone from the bundled flow.

But the code diff is broader than a menu edit. OpenCode also removes the built-in Anthropic auth plugin from its default plugin list. That matters because it turns unofficial Claude subscription access from something the product shipped with into something the project is stepping away from on purpose.

The user fallout was immediate enough to leave a paper trail. In OpenCode issue #18950, a user on version 1.3.0 says that choosing Anthropic used to show three authentication methods, but now only shows an API key input. That issue is not proof of motive by itself. It is proof of effect. For normal users, the sanctioned Anthropic path inside OpenCode has narrowed to API-key billing.

Why OAuth mattered so much in the first place

OAuth was never just a login convenience. In practice, it let developers use a Claude subscription as a spending ceiling inside a third-party wrapper.

That ceiling mattered because agent tools do not fail in neat, budget-friendly ways. A wrapper can queue long runs, retry aggressively, fan out across tools, and quietly turn a small experiment into a larger bill. A flat monthly Claude Pro or Max plan gave people a simpler answer to the question every ops-minded developer asks sooner or later: "What is the worst-case spend if I let this thing run while I sleep?"

Anthropic's public API is built around a different answer. In Anthropic's own API overview, the authentication requirements are explicit: Claude API requests need an x-api-key, an anthropic-version header, and the normal JSON request setup. That path is documented, supported, and usage-billed. It is also much less appealing if your favorite wrapper economics only worked because a subscription could be repurposed as a hard cap.

So when OpenCode steers Anthropic users toward Create an API Key or Manually enter API Key, it is not only changing how people sign in. It is moving them from fixed-fee expectations back onto metered infrastructure. When the fallback is API spend, "let the agent cook" stops sounding adventurous and starts sounding like an invoice.

Anthropic's own API boundary is not ambiguous

One reason this story has spread so quickly is that the repo evidence lines up with Anthropic's own API behavior.

In Anthropic's Claude Code repo, issue #37205 describes a developer trying to use a Claude Code OAuth token with the Messages API. The reported error string is blunt: "OAuth authentication is currently not supported." The request in that issue is effectively asking Anthropic to let subscription-linked OAuth tokens work for programmatic API access.

That is useful because it cuts through a lot of speculation. Even if a user has an OAuth token through Claude Code or a Claude subscription workflow, Anthropic's public Messages API is not presenting that token as a drop-in alternative to an API key. The public interface wants API credentials. Full stop.

That does not prove every internal motive being argued across forums. It does show the practical boundary Anthropic is enforcing: first-party subscription auth is one thing, public programmatic access is another, and the company is not treating them as interchangeable.

Why developers are so irritated by this

The frustration is not hard to understand. Third-party wrappers exist because developers want more than a single vendor's preferred harness. They want routing, custom tools, gateway layers, mixed-provider setups, local models for cheap tasks, and the freedom to plug Claude into broader agent systems. That is part of the same gravity we have seen across the tooling market, including the shift discussed in our piece on OpenAI's agents platform strategy.

A Claude subscription inside a wrapper was attractive because it combined two things developers like very much: better ergonomics and predictable costs. Lose the OAuth path, and the same workflow may still be technically possible through Anthropic's API, but it now runs on usage billing instead of a flat monthly ceiling.

The Hacker News thread that followed the OpenCode changes is loud, occasionally overheated, and still revealing. Some commenters frame the dispute as straightforward terms enforcement. Others frame it as classic first-party lock-in: Anthropic wants developers to use Claude inside Claude surfaces, and to pay API rates if they want Claude elsewhere. What matters for operators is not which side wins the forum argument. What matters is that OpenCode is behaving as if Anthropic's legal pressure is real enough to warrant compliance.

That is the part people building wrappers, gateways, or agent stacks should pay attention to. Auth flows are not just UX. They are pricing policy with a sign-in screen attached.

What still works, and what does not look durable

If you are asking the practical question, here is the short version.

If you want a clean, documented, officially supported way to use Claude in OpenCode or another third-party tool, the answer is the Anthropic API with an API key. That is the path Anthropic documents. It is also the path OpenCode now surfaces most directly.

If you want to keep using Claude Pro or Max as the billing substrate inside a wrapper, the source pack here does not support that as a durable plan. Older plugins may still exist outside the bundled product. Stale auth states may still work in edge cases. Community write-ups, including Dave Swift's, suggest some users have mixed temporary configuration issues with the larger crackdown. But OpenCode has stopped bundling the route, its docs now say Anthropic explicitly prohibits it, and Anthropic's own API issue trail says OAuth auth is not supported for Messages API access.

That leaves developers with a smaller set of honest fallback options: use Anthropic the official way with API keys, switch to a provider whose subscription auth is still allowed in the wrapper, or redesign the stack so spend and routing are managed elsewhere. That last path is part of why wrapper and gateway projects keep mattering. If provider relationships are unstable, abstraction and observability become less of a luxury. We touched on that dynamic in our piece on OpenClaw's OpenAI-compatible gateway.

The bigger shift is who controls the meter

The easy headline is that OpenCode lost Claude OAuth. The more durable headline is that Anthropic appears to be drawing a hard line between using Claude and building on Claude from outside Anthropic's preferred lanes.

Inside that distinction lives a lot of leverage: pricing, support, telemetry, rate controls, and the subtle but valuable power of keeping developers closer to a first-party interface. You do not need to guess at every motive to see the direction of travel. If a Claude subscription once felt portable across wrappers, Anthropic is making it look much less portable now.

That may be rational platform strategy. It is also a useful warning for anyone building serious tooling on top of frontier model subscriptions. If the economics of your workflow only work when an unofficial auth path remains quietly tolerated, you do not have a stable dependency. You have a grace period.