Claude Code API key: how it differs from a subscription, where to get it and how to store it

What does this solve?

Claude Code API key - a key from the Anthropic console, which the client uses to authorize instead of logging into an account with a subscription. It is needed where there is no interactive login: CI pipeline, cron on the server, script with claude -p, someone else's machine without a browser. The second reason is accounting: the expense for the key and the workspace is visible separately, so the project, team or client is counted according to the count, and not according to feelings. The third is the ceiling: the subscription is limited by the plan limits, the key is limited only by the spending limit that you set yourself.

How it works

Two authorization methods

Switching lives in the environment, not in the config: specified variable ANTHROPIC_API_KEY interrupts the saved account login. Team /status inside the session shows what the client is authorized with right now - this is where any analysis of “why it was written off to the wrong place” begins.

What is the score made up of?

Payment is calculated by tokens: separate entry, separate exit, rates vary by model. Reading from cache is cheaper than regular input. The key mechanics of agent work: at each step, the entire accumulated context is transferred to the model anew, so the consumption grows faster than the length of the correspondence.

Practical consequences:

• one long session is more expensive than two short ones for the same work;
• large file remaining in the context is paid at each subsequent step;
• a subagent that processes the output in its window and returns a paragraph is cheaper than the same output dumped into the main context;
• A simpler model saves more on mechanical work than any prompt edit.

The exact rates are on the Anthropic pricing page: they vary by model and change, it’s pointless to keep them in mind.

Where does the key live?

The key enters the process in several ways, and one is selected in the project:

• environment variable ANTHROPIC_API_KEY —via ~/.zshrc, direnv, pipeline secret, launch wrapper;
• apiKeyHelper in ~/.claude/settings.json —path to the command that prints the key to stdout. It’s convenient when the key is issued by a secret storage facility and is rotated according to a schedule: the key itself is not on the disk in clear form;
• gateway: ANTHROPIC_BASE_URL together with ANTHROPIC_AUTH_TOKEN, when traffic must go through a corporate proxy with logging;
• cloud company: CLAUDE_CODE_USE_BEDROCK or CLAUDE_CODE_USE_VERTEX —then authorization is taken from AWS or Google credentials, and the Anthropic key is not needed at all.

What is visible in the console

The key is issued in the Anthropic console and is associated with the organization and workspace. The value is shown once upon creation; Then the name, date and expense remain in the console. If you forgot to copy it, they release a new one, and you cannot restore the old one.

How to connect

1. Anthropic console → API keys → create a key. Name - by place of use: ci-rih-api, mac-dmitry, cron-reports. Names like test in a month they won’t make it clear what to recall.
2. Copy immediately and put in the secrets manager: Keychain, 1Password, Vault, CI secrets. Not in notes, not in chat, not in the repository.
3. Create a separate workspace for the project if expenses need to be divided. Then the account is calculated for the projects itself, without manual analysis of the unloading.
4. Set a spending limit per organization or space up to first launch. The night cycle, gone peddling, stops the limit, not the person at the screen.
5. Give the key to the process without writing it to the project files:

export ANTHROPIC_API_KEY="$(security find-generic-password -s anthropic-api -w)"
claude -p "проверка связи, ответь одним словом ok"

Or through the assistant in ~/.claude/settings.json:

{
  "apiKeyHelper": "/usr/local/bin/get-anthropic-key.sh"
}

6. In CI, use the pipeline secret passed into the step environment variables. Not a file in the repository and not a command line argument: the arguments are visible in the job log and in the output ps.
7. Check that local settings with the key do not go to git. Values are placed in the environment or in .claude/settings.local.json, not committed .claude/settings.json.

Useful scripts

• Nightly running a report or checklist on the server via claude -p no interactive session.
• Checking a merge request in CI: the agent reads the diff, writes comments as comments.
• Separate key per client or project to re-invoice the expense.
• Enterprise loop via Bedrock or Vertex, when traffic should not leave the company's cloud perimeter.
• Gateway with request logging, when the security service requires an audit of correspondence with the model.
• One-time work on someone else’s machine, where you don’t need to log into your personal account.

Limitations

• Every token is paid, including re-reading the same files at each step. Careless task setting costs money directly, not nerves.
• Without a set limit, consumption is limited only by the operating time of the process. The cycle that “almost fixed” the test before morning is revealed by the count.
• The key gives access to the organization’s money. The leaked key is recalled in the console and a new one is released; rewriting the git history does not solve the problem; the commit remains in forks, mirrors and CI caches.
• The set of capabilities of the two authorization methods does not completely coincide - what is available specifically to your organization is checked in your organization, and not according to other people’s stories.
• The organization has a common speed limit: parallel subagents and batches run into it and are refused. A script that does not know how to wait and repeat for such a failure crashes entirely.
• The key removes the ceiling and with it removes the brake: with a subscription, the overspending rests against the window limit, with the key - against the bill.

How to check the result

• /status in session - shows what the client is authorized by. The first thing they look at when expectations differ from the score.
• Make sure that the variable has reached the process without printing the value:

[ -n "$ANTHROPIC_API_KEY" ] && echo "ключ задан" || echo "ключа нет"

• Test headless call claude -p "ответь одним словом: ok" is a cheap way to make sure that the key is alive and the organization is not blocked.
• Usage page in the console: the consumption should appear on the correct key and in the correct workspace. Empty where they were waiting, which means the process was authorized by something else.
• Training feedback: revoke the test key and make sure that the pipeline crashes with a clear authorization error, and does not silently move to someone else’s.
• Before the first push, run a search for secrets in the repository and view git diff --staged eyes: the key most often leaks not in the code, but in the config, which was “just committed at the same time.”

One line rule: the key is stored in the secrets manager, gets into the process as an environment variable, and the consumption limit is set before the first launch.