Do not buy a pre-generated or shared Claude API key from a marketplace. An API key is a credential, not a transferable balance. The safe official route is to create the key inside a Claude Console organization you control, then buy prepaid usage credits for that organization. A cloud platform or API gateway can be a valid alternative, but it issues its own credential, uses its own billing account and endpoint, and must not be presented as an Anthropic key.
A listing labeled “Claude API Key with $100” does not, by itself, prove that you own the Console organization, that the balance has legitimate provenance, that the secret is exclusive, or that you can revoke it. If the seller gives you only a string and you cannot create, rotate, audit, and delete credentials in the account behind it, stop.
Before paying anyone, get three plain answers:
- Who creates and can revoke the credential?
- Who owns the balance and bills each request?
- Which exact endpoint accepts the key?
If those answers point to different or unnamed parties, you do not yet have a safe API contract.
First decide whether you need raw API access
You need a Claude API contract when your own backend, SDK, CI job, agent, evaluation harness, or BYOK application will send programmatic requests. You do not need to buy an API key merely to use Claude on the web or in the consumer apps.
Claude Pro and Max are also not prepaid API accounts. Anthropic's current subscription-versus-Console explanation says paid chat plans and Claude Console/API billing are separate products. A third-party app such as an IDE may include its own Claude allowance, offer BYOK, or charge for a separate plan; check that app's active billing route before buying another contract.
Claude Code sits close enough to both surfaces that it deserves a separate check. If your question is whether a terminal session is using a subscription login, ANTHROPIC_API_KEY, or paid usage credits, use the Claude Code API billing versus subscription guide before funding anything.
The official Console route is the reference path
For direct Anthropic API use, the account and credential should remain under your control from the start. Anthropic's API access help identifies Claude Console as the place to create API keys, manage users, configure billing, and use Workbench.
The current self-serve sequence is:
- Check Anthropic's supported countries and regions for the person or organization that will own the account. The United States is listed as of July 18, 2026; readers elsewhere should check the live list rather than assume the result is global.
- Create a Console organization that your business or project actually controls. Do not let a contractor or marketplace seller remain the only administrator.
- Buy prepaid usage credits in Settings > Billing before using the API. Set a spend limit and decide deliberately whether auto-reload should be enabled.
- Create a workspace for the environment or project, then create a dedicated API key inside that workspace.
- Run one bounded, non-sensitive test request and reconcile it with the Console usage and cost records before moving real traffic.
This sequence separates the asset you fund from the credential you rotate. The Console balance pays for usage; the key authorizes a workload to spend from that controlled account.
What the prepaid credit contract includes—and does not
Anthropic's current API billing help says Claude API and Workbench usage are funded with prepaid usage credits. Credits must be purchased before use. If the balance reaches zero, API and Workbench access stops until more credits are bought or auto-reload adds them.
Four details should affect how much you fund:
- Purchased credits expire one year after purchase, the expiration cannot be extended, and the purchase is nonrefundable.
- Failed requests generally are not charged; successful calls and completed tasks are charged. Check the actual ledger for edge cases such as a client disconnecting during an otherwise successful request.
- Auto-reload makes another purchase when the balance crosses the threshold you set. It prevents downtime but can also turn a runaway workload into repeated charges, so pair it with spend limits and alerts.
- The current public billing and access pages do not promise universal starter credits or state a universal minimum top-up. If your individual Console shows a promotion or test balance, treat it as account-specific and read its amount, expiry, and conditions there.
Funding is not model pricing. Model cost depends on input tokens, output tokens, caching, tools, routing options, and the current rate. Check the live Claude API pricing page immediately before estimating a workload; do not rely on an old “Tier 1–4” chart or a reseller's claim about how much usage a balance buys.
Keep the key scoped, expiring, and replaceable
Each Anthropic key belongs to one workspace. The workspaces documentation explains how workspaces separate projects or environments and can carry lower spend and rate limits than the parent organization. Separate development, staging, and production keys improve isolation, but they do not create separate free balances.
At creation time, Anthropic's current authentication documentation lets you choose preset expirations of 3 hours, 1 day, 7 days, or 30 days, a custom duration, or Never. Use a short-lived key for a short test. If a production key must live longer, store it in a secrets manager, restrict its workspace, and plan rotation rather than putting it in source code, a browser bundle, screenshots, or support messages.
If exposure is suspected, revoke first and investigate second. Anthropic's compromised-key guidance directs the owner to delete the affected key in Console and create a replacement. A marketplace secret fails this basic security model when the buyer cannot perform those actions independently.
Apply the three-owner test before you pay
A provider can be official, cloud-operated, or independent. The label matters less than whether the control plane is explicit. Use this test for every route:
| Check | A controlled route can answer | Stop when |
|---|---|---|
| Credential owner | You create, scope, expire, rotate, and revoke the key in your account | A seller sends only a secret or remains the sole account owner |
| Billing owner | One named provider shows balance, usage, expiry/refund rules, failed-request billing, and invoices | “Official balance” has no auditable account or funding record |
| Endpoint owner | The key has a documented Base URL, authentication scheme, and provider support path | The key is advertised as working everywhere or the endpoint is withheld |
| Secret control | You can exclude former contractors/sellers and replace the credential without permission | Another party may retain or redistribute the same string |
| Evidence control | You can inspect request ID, exact model ID, token/cost records, data terms, and logs | A single successful response is the only proof offered |
The first three rows establish the contract. The last two establish whether you can operate it safely.
Why a cheap “$100 key” fails this test
A marketplace page can prove that a seller offered a product at a particular moment. It cannot prove that the buyer receives the organization, exclusive secret control, a durable balance, or the right to manage support and refunds. The key may work once and still leave every important control with someone else.
That does not justify accusing a specific seller of theft, card fraud, model substitution, or secret sharing without evidence. You do not need such an accusation to make a sound decision. The objective stop rule is enough: no owned account, no independent revocation, and no auditable ledger means no purchase.
Run one bounded call before production
The first test should prove that credential, endpoint, and billing form one observable loop. It should not try to benchmark quality or prove long-term reliability.
Use this procedure:
- Set an organization/provider spend cap. Disable auto-reload for the test, or set a threshold and reload amount small enough to be harmless.
- Create a test-only workspace or project and a short-lived key. Do not reuse a production secret.
- Copy the current Base URL, authentication header, and exact model ID from the provider's own documentation or model list.
- Send one non-sensitive prompt, such as “Reply with OK only,” with a deliberately small output limit.
- Match the response or request ID to the provider's usage log. Confirm model ID, input/output tokens, status, and the actual charge.
- Revoke the test key and repeat the request. It should fail authentication. If it still succeeds, stop and contact the provider before sending any data.
One passing call proves only that this route handled one request and produced a visible charge at that time. It does not prove exclusive provenance, permanent model identity, future availability, or an SLA. Production approval still needs workload-sized cost samples, rate-limit behavior, retry handling, data/retention terms, and a real support path.
Cloud and gateway credentials are separate contracts
An organization that already uses a supported cloud may prefer the cloud provider's IAM, procurement, regional controls, and consolidated billing. In that route, the cloud account issues or governs the credential and the cloud provider bills usage. Anthropic's Claude Platform on AWS documentation describes a provider control plane, not a shortcut that adds money to Claude Console. Cloud credentials and Console keys are not interchangeable.
An independent gateway is another distinct route. It can be useful when a developer deliberately wants one OpenAI-compatible endpoint, multi-model switching, or a separate backup provider. It also adds another contract: the gateway owns its balance, token, Base URL, logs, data terms, availability, and support boundary.
For example, the LaoZhang API quickstart, checked on July 18, 2026, describes a separate multi-model integration platform with its own account balance, token, and OpenAI-compatible https://api.laozhang.ai/v1 Base URL. It states that a new account's $0.5 test credit is for connectivity and development verification, not production. That credit belongs to LaoZhang's provider contract; it is not Anthropic credit, and a LaoZhang token is not an Anthropic key.
The same quickstart tells users to distinguish development testing, internal tools, and production integration, check credit and billing status in the console, and contact support before production use or enterprise procurement. Before funding production, confirm the account route, payment, limits, invoice or contract, and support owner; stop if any of them cannot be confirmed.
This route fits a developer who intentionally accepts a separate provider while valuing OpenAI-compatible integration and model switching. Prefer Anthropic direct or a supported cloud when you require an Anthropic-issued credential, native account controls or features, first-party support, a specific procurement/compliance contract, or explicit data-residency ownership. Stop evaluating any gateway if its current model list, live pricing, failed-request billing, data terms, logs, or support cannot be confirmed. For the broader architecture choice, use the Claude direct, cloud, or gateway guide.
Is there a free Claude API key tier?
Key creation and funded usage are different questions. As of July 18, 2026, Anthropic's current public access and billing pages do not promise every new API user starter credits, and an API key does not carry its own allowance. The dependable public self-serve contract is prepaid credits followed by usage-based charges.
If your Console shows an account-specific credit or promotion, use only the amount and conditions displayed for that account. If a separate provider offers test balance, attribute it to that provider and its stated purpose. Creating more keys does not multiply either balance.
For ongoing cost, measure a representative request's input and output tokens, then price the workload using the current provider ledger and rates. If the next question is how Anthropic compares with another API rather than where to obtain a credential, use the Claude versus OpenAI API cost guide.
The purchase rule that prevents most mistakes
Use Claude Console when you qualify for direct access and need an Anthropic-issued key and first-party contract. Use a supported cloud when cloud IAM, procurement, or regional governance is the real requirement. Consider an independent gateway only when you deliberately want its interface and accept its separate billing, data, and support boundaries.
Never pay for a secret that you cannot create, audit, rotate, and revoke yourself. The key opens the door; the account, ledger, endpoint, and off switch are what make the API access worth paying for.
