How I Got Opus Back Under My Max Plan

TL;DR

Claude Opus 5 runs in my own coding setup again, paid for by the Claude Max subscription I already had.

Two programs are involved. OpenCode is the control layer I type into: it chooses and orchestrates the right assistant, then hands the job to Claude Code. Claude Code executes the work, makes the model call, and runs its own tools.

Here is what this is not. I did not dig the login token out of Claude Code and point my own code at Anthropic’s pay-per-use API with it. That is a different thing, and the docs do not describe it as a supported way in.

It took months, mostly because Anthropic’s rules moved twice and my first working build turned out to be the wrong shape. This is a personal setup on my own machine, and it is NON-PHI: no patient data, ever.

Which model, and why

I did not land on Opus 5 in one step. I ran Opus 4.8, then Fable, then Opus 5.

Opus 5 is where I stopped. It gives me the level of thinking I want without pushing me into paying more for it.

The bigger win is how I pay. For my work, getting Opus 5 through a subscription I already hold is far better than paying per token on the API for the same jobs. That is a structural difference rather than a number I have measured, and I am not claiming a figure.

The rules moved twice

On April 3, Anthropic’s Boris Cherny announced the restriction, which would take effect April 4 at noon PT: subscriptions would stop covering outside tools. Extra usage bundles and API keys were the alternatives. I took that at face value and moved my Opus work onto Google’s Vertex, where you pay per token.

Then it moved.

On May 13, the official Claude Developers announcement named what a paid plan would cover: the Agent SDK, which is Anthropic’s toolkit for building on Claude Code, the claude -p command, GitHub Actions, and outside apps built on that toolkit.

On June 15, Anthropic paused the credit program attached to it. The part that stayed true through the pause: Agent SDK, claude -p, and third-party app usage still draw on your subscription’s limits. The credits may come back. I am not treating a paused credit as something I own.

One line I will not blur. This is personal, local use on my own machine. Anthropic’s legal and compliance guidance says third-party developers may not offer Claude.ai login or route other users’ plan credentials without approval, and points businesses at API keys or a cloud provider instead. The Agent SDK overview covers what the toolkit supports.

Direct API access is a separate path. The Anthropic API overview says you authenticate there with a Console API key or Workload Identity Federation. Anthropic also documents claude setup-token as an official setup flow for Claude Code and Agent SDK use. Following that documented flow is not the same as scraping a login credential from storage and replaying it against the direct API. The docs do not describe credential scraping and replay as direct API authentication. I am stating what they cover, not claiming a source uses the word “prohibited”.

What the metered route cost

While the subscription route was unclear, Vertex was the honest answer: a supported cloud provider, paying for what I used.

The official Vertex AI pricing page lists standard global-endpoint pay-as-you-go Opus 5 pricing at $5 per million input tokens and $25 per million output tokens. Regional or multi-region pricing is $5.50 input and $27.50 output per million tokens.

I am not turning that into a monthly savings claim. I never established a typical month, and the total depends heavily on what you ask for. The difference is structural: Max is already paid for, while Vertex bills separately per token. Once the Max route worked, OpenCode reported $0 for its provider cost on verified runs. That means OpenCode saw no metered charge to report. It does not mean the Max plan or the compute is free.

The build that passed everything and still failed

In July I built the version that looked best on paper. It passed 45 tests, finished 250 of 250 calls and 20 of 20 cancellations, and cleared CI and review.

Then I gave it three real jobs that required reading files.

It produced sensible text, and OpenCode’s own record showed none of its tools had run. A test could prove the thing returned words. It could not prove OpenCode still owned the tools, which is exactly what that design depended on. I had agreed in advance that this would kill the experiment, so I killed it instead of faking the missing signals.

What actually runs the work

The version I run now changes the deal rather than pretending to meet the old one. OpenCode is the app and the control layer. It chooses the role for a job, decides what work to hand over, and sends that work down to Claude Code.

Claude Code is the executor. It executes the work, makes the model call, and runs its own tools. That distinction explains the signal that killed my earlier build: when a read happens inside Claude Code, OpenCode may not log a tool event of its own. The missing OpenCode event does not mean nothing ran. It means I was looking at the wrong layer for execution evidence.

I accept that, because OpenCode still chooses the roles and the work, while the tools reaching Claude Code are deliberately limited. The boundary has to be real at the executor. Calling a role read-only is not enough; the restriction comes from which tools actually reach Claude Code. That is less tidy than my first design, but it describes the system I actually tested instead of the one I wanted to have.

Versions will bite you

What works for me is ai-sdk-provider-claude-code@3.5.3 with OpenCode 1.18.16. The provider package is the bridge that lets OpenCode drive the Claude Code CLI rather than calling Anthropic directly. Those two speak the same version of the spec that connects them.

When I tested this in August 2026, installing the latest gave me 4.1.0, which speaks a newer spec and would not load. That is what I saw at the time, not advice that will age well. All the pieces move independently. Check the versions you actually have before copying mine.

The OpenCode provider documentation is the right place to start. Neither doc removes the need to check that the two ends agree.

Three roles with different power

I run three roles, because they should not all be allowed to do the same things.

Planning and research gets the full set of tools. I use it when the model needs to look around before deciding anything.

The advisor role gets read tools only. It can inspect and recommend; it cannot change anything. Because Claude Code is the executor here, that limit comes from which tools I hand to Claude Code, not from calling the role read-only. I tested it by asking it to make a change: nothing changed, and no write was logged. That result covers the exact versions and settings I tested, not a promise that holds everywhere.

The design role gets the full toolset plus a browser, because building something visual needs a different set of tools than reviewing does.

All of it is NON-PHI. Not approved for patient data or anything clinical.

Logins fail in confusing ways

Some of my worst debugging here was authentication wearing a costume.

Specific inherited environment variables can quietly decide which account gets charged before your intended route gets a say. The conflicts are credential values, custom endpoints, cloud profiles or federation settings, and provider-selection controls associated with Anthropic, Claude, AWS, Google, Vertex, or Bedrock. A setup that looks correct in one terminal can behave differently in another, purely because of what it inherited.

My wrapper removes or overrides those conflicting variables instead of blanket-stripping every variable with one of those prefixes. It preserves deliberate isolated settings such as CLAUDE_CONFIG_DIR, keeps the Claude settings separate, and refuses to run when the official login is missing. No login, no run, and no quiet fallback to Vertex, Bedrock, or an API key.

Once, a CLI update wiped the login here. That happened to me; I am not claiming every update does it. The lesson was narrower and more useful: prove which route you are actually on before starting real work.

I am not publishing my paths, endpoints, or private settings. The diagram shows the order without handing anyone a map.

What this does not promise

Max usage limits still apply, and terms and limits can change. The paused credit plan could return, change shape, or stay paused.

There is no metered API fallback here, on purpose. If I hit the limit or the login disappears, work stops rather than quietly turning into a bill.

A role is only as limited as the tools you actually hand it, so re-test after any version or settings change.

This is personal and local, not a template for a business that collects or routes other people’s Claude accounts. Anthropic points businesses at API keys or a cloud provider.

Set this up yourself

The prompt below is harness-agnostic. Paste it into OpenCode, Claude Code itself, or whatever agent tool you use:

Help me run Claude Opus through my existing Claude Max subscription inside my own agent setup, staying within Anthropic's documented rules.

Start by asking me: which agent app and version I use, whether it supports a custom model provider or plugin, and whether my use is personal and local rather than a product serving other people's Claude accounts. If it is the latter, stop and tell me so; that path needs an API key or a cloud provider instead.

Before changing any config, check which SDK spec version my app speaks and which my candidate provider package speaks, then pin a compatible pair. Do not assume the newest version works.

Rules while you set this up:
- Route every model request through the Claude Code CLI as the execution engine; do not use a direct API client.
- Use only official Claude Code or Agent SDK authentication, including Anthropic's documented `claude setup-token` flow when that is the supported setup path. Never scrape a credential from storage or replay one against the direct Anthropic API.
- Remove or override conflicting credential, custom-endpoint, cloud profile or federation, and provider-selection variables so they cannot silently redirect which account is billed. Do not blanket-remove variables by prefix. Preserve deliberate isolated settings such as `CLAUDE_CONFIG_DIR`.
- Keep the Claude settings and tool surface isolated from my unrelated profiles.
- Give each role only the tools it genuinely needs. Limit power by the tools actually passed through, never by naming a role something reassuring.
- Fail closed. If the official login is unavailable, stop; never fall back to anything billed per token.
- Keep this non-PHI. Never print paths, endpoints, credentials, tokens, or private config.

Once it runs, verify and report back: which account was billed, what cost my app reports, that a read completes through the intended route, that a write attempt is refused and leaves no file change and no write event, that cancelling works, and that the login survives a CLI update.

Tell me plainly which checks passed and which did not.

You have it working when the expected read succeeds through the intended route, the write attempt changes no file and logs no write event, and login and billing both resolve where you expected. If any check fails, fail closed and fix it before trusting the setup.