If you are wiring a personal agent harness — scripts on your machine, tools that call Claude, maybe the Claude Agent SDK — you will hit a fork almost immediately.
Not the model fork. The money and identity fork.
Anthropic exposes Claude through more than one front door. The two that matter for builders are API keys from the Console and OAuth-backed sessions tied to Claude Code / Claude.ai subscription plans. They are not interchangeable ideas, even when the underlying model family is the same.
API keys: the pay-as-you-go rail
You create a key in Claude Console, export it as ANTHROPIC_API_KEY, and anything that speaks the Anthropic API can bill your workspace in the usage sense — rate limits, spend caps, and line items on the API side.
This is the path documented for direct API use and for the Agent SDK quickstart: install the SDK, set ANTHROPIC_API_KEY, run query() (or the TypeScript equivalent). The same docs also describe cloud provider auth — Bedrock, Vertex AI, Azure AI Foundry — as first-class alternatives, still in the “programmatic product integration” family, not consumer login.
For a harness, API keys are boring in a good way. One env var, predictable billing, easy rotation, straightforward secret hygiene (.env local, a vault in production).
OAuth and Claude Code: the subscription rail
When you use Claude Code (the CLI / IDE flow) with a Pro, Max, or Team-style plan, authentication is typically OAuth — you log in, tokens refresh, and the tool talks to Anthropic as *that* product channel.
Same session, different contract from a Console API key: the CLI banner (Sonnet 4.6 · Claude Max) is the subscription rail in the open — not ANTHROPIC_API_KEY metering. Claude Code runs as the Claude Code product; docs for the programmatic Agent SDK still point at Console keys for third-party distribution, as in the Agent SDK overview.
That channel is optimized for Claude Code and claude.ai, not for “any HTTP client that found a bearer token.” Anthropic’s own Agent SDK documentation draws a bright line for third-party products: unless you have explicit approval, you should not build software that asks end users to “log in with Claude” for rate limits; you should use Console API keys (or the supported cloud paths) instead.
Translation for a solo harness: using your own Claude Code login on your own machine is one thing. Shipping a product that funnels strangers through consumer OAuth to hit the Agent SDK is another — and the docs tell you which side is supported for shipping.
What the Agent SDK “wants” on paper
The public story is API-key-first (or Bedrock / Vertex / Foundry). That matches how most programmable integrations are expected to authenticate.
OAuth-heavy workflows you see in the wild are often Claude Code–shaped — subprocesses, local config, tokens bound to a CLI session. If you mix that with raw @anthropic-ai/sdk calls in the same repo, you can end up with two different auth stories in one process. Some setups even document a precedence rule: if ANTHROPIC_API_KEY is set, it can override subscription auth for Claude Code–adjacent tools. That is not hypothetical confusion — it is the kind of thing you only notice when your bill or your error message suddenly “switches rails.”
Rule of thumb: one primary rail per process, and read the env docs for the specific tool you spawned.
Choosing for a personal harness
| Question | API key | OAuth / Claude Code |
|---|---|---|
| Who pays? | Your API workspace, usage-based | Your Claude subscription / team terms |
| Best when | You want explicit metering, automation, or you are close to the documented SDK path | You live inside Claude Code and want the bundled agent loop there |
| Secret shape | sk-ant-api03-... in env / vault | Session managed by Claude Code / login flow — not something to paste into Discord |
| Shipping a product to others | Supported pattern per docs | Consumer OAuth is not the documented distribution path for third parties |
Security notes that survive contact with reality
Treat API keys like passwords. Never commit them, never log them, never proxy them to the browser. For a long-running harness, prefer a secrets manager or OS-level secret injection over a world-readable .env on a shared machine.
OAuth tokens are still secrets. If you can read a bearer token from disk, so can malware. The win is not “OAuth is safe” — it is “the Claude Code client handles refresh and scope for its product surface.”
Split keys by environment if you ever graduate the harness from laptop to server — dev/staging/prod keys, rotation when someone leaves a machine.
Closing frame
You are not choosing between “real Claude” and “fake Claude.” You are choosing which contract your harness runs under — API usage with a Console key, or Claude Code / subscription OAuth on the product path Anthropic attached that login to.
For personal work, either rail can be legitimate. For software other people install, the Agent SDK’s documented default is the Console (or cloud provider) key path — and Anthropic explicitly discourages wiring arbitrary products to claude.ai login unless you are in an approved arrangement.
If you only remember one thing: know which rail you are on before you debug rate limits, because the failure modes and the dashboards are different.
Primary references: [Claude Agent SDK overview](https://docs.anthropic.com/en/api/agent-sdk/overview), [Claude API — getting started](https://docs.anthropic.com/en/docs/get-started). Policy language around OAuth vs API keys for third-party products appears in the Agent SDK docs and Claude Code legal/compliance materials — read the current version before you ship anything that authenticates users.