Running Claude Code with several accounts and keys at once

If Claude Code is being used across several projects at once — freelance work for different clients, a personal project alongside a work one, or simply not wanting spend from different tasks to blend together — the question isn't "how do I switch accounts," it's how to split access across separate fetch_... keys, each with its own limits and its own list of allowed models (the balance and spend history stay shared across the account).

A key is a configuration, not a login

This gateway has no notion of "switching users" the way an official subscription service might. Each key is created separately in the dashboard at https://zukko.pro/app/api-keys↗, shown once at creation time, and after that it's just a fetch_... string you paste wherever Claude Code expects one. You can issue as many keys as you need — one per client, one per project, one per team member.

On each key's own page in the dashboard, you can separately configure:

• a daily or monthly spend limit in dollars;
• a list of models allowed for that specific key.

If a key issued for, say, a junior developer's test runs is restricted to cheap models with a $5 daily limit, and the code tries to call claude-opus-5-5 outside that list, you'll get 403 model_not_allowed_for_key. Exceeding the spend limit itself gives a 429 with either key_daily_limit_reached or key_monthly_limit_reached, depending on which limit ran out. These are distinct errors worth telling apart in your agent's logs: the first is a model policy, the second is a spent budget.

How Claude Code knows which key to use

Claude Code is an Anthropic-compatible client, so its base URL is https://api.zukko.pro, with no /v1 — the client appends the path itself. The key is passed the way an Anthropic-compatible client expects — through the ANTHROPIC_AUTH_TOKEN environment variable (not ANTHROPIC_API_KEY, which makes Claude Code think you're working through an official Anthropic account and prompts you to log in). At the HTTP level the header is Authorization: Bearer fetch_..., though x-api-key shows up sometimes too, and the gateway accepts both.

To hold several keys at once without mixing them up across sessions, there are two practical approaches.

Through project settings. For a project tied to one specific client, you can set environment variables directly in that project's .claude/settings.json — then Claude Code, run from that project's folder, automatically picks up the right key and base URL, independent of whatever happens to be exported in the current shell:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.zukko.pro",
    "ANTHROPIC_AUTH_TOKEN": "fetch_project_a_key"
  }
}

Through shell environment variables. For quick switching between projects without a dedicated .claude/settings.json for each one, keep keys in separate profile/environment files and explicitly export the right one before launching:

export ANTHROPIC_BASE_URL="https://api.zukko.pro"
export ANTHROPIC_AUTH_TOKEN="fetch_project_b_key"
claude

Don't mix the two approaches in one session — if a project's .claude/settings.json already sets ANTHROPIC_AUTH_TOKEN, a variable exported in the shell might have no effect, or might override the project setting, depending on which one applies first. It's more reliable to pick one approach for the whole workflow rather than relying on remembering what got exported in this terminal an hour ago.

Checking which key is actually active right now

Before trusting Claude Code with real work against someone else's budget, it's worth checking which account the active key belongs to: /v1/balance returns the account's balance (identical for every key on the same account) — that rules out work silently running against a different account:

curl https://api.zukko.pro/v1/balance \
  -H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN"

If the response shows a balance that doesn't match the account you expected, an old key is still sitting in the environment variable or in .claude/settings.json. Keep one limitation in mind: GET /v1/usage returns cursor-paginated history for the whole account — all keys together, no per-key filter — and Claude Code works in streaming mode, so its requests carry no cost headers. Keys within one account separate limits and models, but not spend history; if client spend has to be strictly separated, set up a separate account per client.

Per-key limits as a safeguard, not just bookkeeping

It's worth setting limits on keys not only for convenient per-project cost tracking, but as protection against typos and runaway loops. A key that Claude Code uses in automated mode — say, in a CI pipeline or a background agent task — is worth restricting both by money and by model list, so an accidental infinite loop of calls hits 429 key_daily_limit_reached instead of burning through the whole account's budget overnight.

If the same key gets used across several parallel Claude Code sessions at once, that's expected — there's no separate limit on the number of concurrent connections in this scheme; the constraint operates on money and on model, not on how many clients are connected simultaneously.