Managing Claude Code API Keys Across Multiple Projects

You’re working on three projects. Two are personal, one is a client’s. All three use Claude Code with your Anthropic API key.

You launch Claude in the client’s repo and realize — it’s the same key you use everywhere. The same key that has access to your billing. The same key your personal projects burn through tokens on. If the client ever asks “are we being billed separately?” you don’t have a clean answer.

This isn’t hypothetical. Anyone running Claude Code across multiple projects hits this problem eventually.

Why shared API keys cause real problems

The most obvious issue is billing. If you’re using one key for everything, you can’t attribute costs to specific projects. When a client asks what their AI usage cost this month, you’re guessing.

But there’s a subtler problem: key scope. A single key used across every project means every project has the same access. If one project’s environment leaks the key — through a misconfigured .env, an accidental commit, or a CI log — every project is exposed.

And then there’s the operational side. If you need to rotate a key because of a suspected leak, you’re rotating it everywhere. Every project, every environment, every script that references it. One compromised context takes down all your contexts.

The standard approach: environment variables per project

The most common pattern is setting ANTHROPIC_API_KEY per project directory. You can do this with direnv, project-specific .env files, or shell scripts that export the right key when you cd into a directory.

This works, but it has friction:

  • direnv requires a .envrc file in every project root, and you need to remember to direnv allow each one.
  • .env files need to be gitignored carefully. One missed entry and your key is in version control.
  • Shell scripts require you to remember to source them before launching Claude.

All of these approaches rely on you doing the right thing every time. They don’t fail safely — they fail silently, falling back to whatever key is in your global environment.

What good key management looks like for Claude Code

The ideal setup has a few properties:

  1. Each project gets its own key. Create separate API keys in the Anthropic console and assign one per project. This gives you per-project billing attribution and limits the blast radius of a leak.

  2. Keys are bound to projects, not to your shell. The key should be associated with the project itself, not with whether you remembered to run a setup script.

  3. Rotation affects one project. If you rotate a key, only the project using that key needs updating.

  4. Keys never touch version control. This should be enforced by the tool, not by your discipline.

How Crystl handles API keys per project

In Crystl, each gem (project) can have its own API key configured through the API key management settings. You set the key once for the gem, and every shard (session) within that gem uses it automatically.

This means:

  • Your client project uses the client’s API key. Your personal projects use yours. No cross-contamination.
  • Keys are stored in Crystl’s secure configuration, not in files that could be committed to git.
  • Rotating a key means updating one field in the gem’s settings. Every shard in that gem picks it up.
  • You never need to think about which key is active. The gem knows.

You can also set a default key that applies to any gem that doesn’t have a specific key configured. So your personal projects can share your default key while client projects each get their own.

A practical multi-project setup

The setup I use:

  1. Create separate API keys in the Anthropic console. Name them clearly — “Personal,” “Client A,” “Client B.”
  2. Set per-gem keys in Crystl for each client project. Leave personal projects on the default.
  3. Set usage alerts in the Anthropic console for each key so you know if a project is burning through tokens unexpectedly.
  4. Rotate quarterly or whenever someone leaves a project. Since each key is scoped to one gem, rotation takes about ten seconds.

This also makes invoicing straightforward. At the end of the month, pull usage per key from the Anthropic dashboard and attribute it directly to the client.

The cost of getting this wrong

API key hygiene isn’t exciting, but the failure modes are:

  • A key leaked in a git commit means scrambling to rotate it across every project that shares it.
  • Mixed billing means you’re eating API costs you should be passing through.
  • A compromised key with broad access means every project is a potential vector.

If you’re running Claude Code on more than one project — and especially if any of those projects involve client work — per-project key management isn’t optional. It’s infrastructure.

Crystl is free — sign up at crystl.dev/login.