How to Manage Multiple LLM API Keys

If you're building more than one app or feature on top of an LLM, you'll quickly end up with a pile of API keys scattered across .env files, CI secrets, teammates' laptops, and dashboard clipboards. Managing multiple LLM API keys well comes down to three things: issuing a separate key per app or environment instead of reusing one key everywhere, tracking usage and spend per key so you know what's costing you money, and having a clean way to revoke or rotate a single key without breaking everything else.

The short answer: don't share one master key across your stack. Create scoped keys for each app, service, or team, store them in a secrets manager (not source control), set up usage/budget alerts per key, and rotate on a schedule or immediately after any suspected leak. The rest of this article walks through how to actually do that in practice, including when it makes sense to put a gateway layer in front of your provider keys entirely.

Why "one key for everything" breaks down

It's tempting to generate a single API key from your LLM provider and paste it into every project. It works fine until it doesn't:

• No blast radius control. If that one key leaks — in a client-side bundle, a public repo, a log file — every app using it is compromised at once.
• No per-app visibility. You can't tell if your chatbot or your internal script is burning through your budget this month.
• Revocation is all-or-nothing. Rotating the key means updating every service simultaneously, which usually means downtime.
• Team access is binary. Either someone has the key or they don't — there's no way to give a contractor temporary, limited access.

This is the same reason you wouldn't give every microservice the same database root password. API keys deserve the same hygiene.

Step 1: Issue one key per app, not per provider

The first real fix is structural: generate a distinct key for every distinct consumer of the API. "Consumer" means an app, a service, an environment (staging vs production), or a team — not your whole company.

A reasonable baseline:

sub_live_app_marketing_site
sub_live_app_support_bot
sub_live_app_internal_tools
sub_live_app_staging

Naming conventions matter more than people think. Encode the app and environment in the key's label (most providers let you name/tag keys) so that when you're staring at a usage dashboard at 2am, you immediately know which key spiked.

If your provider doesn't let you create multiple keys easily, or charges friction for it, that's a signal you need a layer that does — more on that below.

Step 2: Store keys properly, not in code

Once you have multiple keys, storage discipline matters more, not less. Rules that hold regardless of how many keys you manage:

• Never commit keys to git, even in "private" repos.
• Use environment variables locally, loaded from .env files excluded via .gitignore.
• In production, use your platform's secrets manager (Vault, AWS Secrets Manager, Doppler, or your host's built-in encrypted env vars) instead of plain environment variables where possible.
• Avoid putting keys in client-side JavaScript. Any LLM key used in a browser is public the moment it ships.

# .env (never committed)
APP_SUPPORT_BOT_KEY=sub_live_xxxxxxxxxxxxxxxx
APP_MARKETING_KEY=sub_live_yyyyyyyyyyyyyyyy

const key = process.env.APP_SUPPORT_BOT_KEY;

const res = await fetch("https://api.subtoapi.app/v1/messages", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${key}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "claude-sonnet-4",
    max_tokens: 1024,
    messages: [{ role: "user", content: "Summarize this ticket." }]
  })
});

Step 3: Track usage per key, not just in aggregate

Once keys are separated, the real payoff is visibility. You want to answer, at any time: which app is spending the most, which key has a usage spike, and which key is nearing a limit.

A per-key dashboard should show at minimum:

• Request volume over time
• Token usage (input/output)
• Error rate
• Last-used timestamp (useful for spotting dead keys you can revoke)

This is exactly the gap a gateway like SubToAPI fills: it turns your Claude access into application API keys with usage metadata built in, so each sub_live_... key reports its own request counts and token usage in one dashboard instead of you trying to reconstruct that from raw provider logs. See the docs for details on how usage data is surfaced per key.

Step 4: Rotate keys on a schedule and after any incident

Rotation shouldn't be a fire drill. Build it into your calendar:

1. Generate a new key for the app.
2. Deploy the new key to the app's environment.
3. Confirm the app is using the new key (check the "last used" timestamp on the old one).
4. Revoke the old key.

Do this quarterly for production keys, and immediately — not "when you get a chance" — if a key appears in a log, a committed file, or a shared screenshot. Because each app has its own key, rotating one doesn't touch the others.

Step 5: Consider a gateway if you're managing keys across a team

If you're a solo developer with two apps, the steps above are usually enough. Once you've got a team, multiple products, or clients who each need their own access, manually issuing and tracking provider-level keys gets tedious fast, especially if your underlying LLM subscription doesn't naturally support multiple scoped keys with individual limits.

That's the specific problem SubToAPI solves: it sits on top of your existing Claude access and gives you proper application API keys, with streaming, tool use, and per-key usage metadata, plus team seats so colleagues can create and manage their own keys without sharing credentials. Plans start at Solo for a single developer, Team for shared seats, and Scale for larger usage — all with a free trial at signup. Check pricing or start with the quickstart to see how key issuance works in practice.

Putting it together

Managing multiple LLM API keys isn't about finding a clever trick — it's about applying the same access-control discipline you'd apply to any other credential: one key per consumer, proper secrets storage, usage visibility per key, and a rotation habit that doesn't require a crisis to trigger it. Do those four things and "multiple keys" stops being a liability and becomes exactly what it should be: a clean way to see where your LLM usage is actually going.

questions

Do I need a separate API key for every single environment (dev, staging, production)? Yes, ideally. Separating environments means a leaked staging key can't touch production traffic or billing, and you can safely give developers broader access to non-production keys.

What's the fastest way to tell which key is costing the most? Use a dashboard that reports usage per key rather than aggregated totals. If your provider doesn't offer that natively, a gateway layer like SubToAPI's dashboard can surface per-key request and token metrics.

Is it safe to use the same key across multiple client projects to save money? No — it removes your ability to isolate billing, revoke access for one client without affecting others, or see per-project usage. Issue a distinct key per client even if it adds a small amount of setup overhead.