Claude Code API Key: Where to Get One and How to Connect It

The API key is the second most common source of problems after access. The good news is that diagnosis is unambiguous: the fault is either in the key itself or in where the program reads it from.

Where the key is created

Keys are issued in the provider console, in the API keys section. Three things worth doing at creation time:

• Give the key a meaningful name. Six months later you will not remember which of four keys is used where, and you will need to revoke a specific one.
• Copy the value immediately. The full key is shown once; after that you only see its tail.
• Use a separate key per environment. Local work, CI and production scripts should each have their own. Then compromising one does not stop everything.

Where to put it

In order of preference:

1. An environment variable - the default. The program reads the key from the environment and it never sits in the project.
2. The system secret store, if the tool supports it. The key is not even visible in a variable listing.
3. A config file outside the repository - fine if it lives in your home directory rather than in the project.

What not to do:

• Put the key in a file inside the project, even with a .gitignore entry. Sooner or later someone runs git add -f or copies the folder wholesale.
• Pass the key as a command argument - it lands in shell history and in the process list.
• Share one key across a team. You will have to revoke it for everyone at once.

Your own key versus a subscription

This is a choice on two axes: cost and predictability.

A subscription is a fixed monthly amount with usage limits inside it. Spend does not depend on how heavy the week was. What you can hit is the limit, and then work stops until the window resets.

An API key bills actual token usage. You will not stall mid-task, but the invoice reflects how you worked. One bad day with an enormous context costs noticeably more than a careful week.

A practical heuristic: daily, steady use is calmer on a subscription. Bursty load, or invocation from scripts and CI where predictability matters more than the total, favours a key. How spend is formed in the first place has its own article: limits and saving context.

Debugging a 401

Check in order, most common first:

1. Which key the program picked up. An environment variable usually overrides the config file, so you are editing the wrong source. This is cause number one.
2. Is the key complete? Copying often drops the tail or attaches a space, and an invisible trailing newline breaks the authorisation header.
3. Is the key live? Revoked and expired keys give the same error.
4. Is it the right account? A key from another organisation will not work even if it is valid.
5. Is there a balance? With some providers a zero balance returns 401 rather than 402.

If the key is correct and the request still fails, you are probably looking at the wrong error. Timeouts and dropped connections look different; the symptom table is in the access article.

Next

With a working key, continue to CLI commands and modes and picking a model for the task. The overview is in the Claude Code guide.