Shift Note: Separate API Keys for Each Project

One shared key makes every project harder to trace

An API key is a secret credential that an application sends when it calls a service. Think of it as a pass that lets the service recognize an authorized caller. Depending on the provider, that pass may also connect requests to billing, permissions, and usage records.

Using one key for a personal experiment, a customer-facing application, and a background job might seem convenient. The trouble starts when spending rises or a key leaks. You may struggle to identify which project caused the problem, and replacing the shared key can interrupt all three.

A practical starting point is one key per project, with separate keys for testing and production when available. This makes credentials easier to replace and activity easier to investigate. It does not automatically create separate billing accounts or enforce spending limits; those depend on the service.

Give each key a job before issuing it

Start with a short inventory rather than a complicated system. For each application, record its purpose, owner, environment, and where its secret is stored. Keep the actual key out of this inventory.

• Name a test key something recognizable, such as invoice-helper-development.
• Give the live application its own credential, such as invoice-helper-production.
• Record who can replace the key and which deployments need updating afterward.
• Note any permissions, model restrictions, or spending controls that the provider actually supports.

A project that experiments with Gemini 2.5 Flash should not need the production credential for a separate application using Claude Haiku 4.5. The model choice and the key serve different purposes: the model determines what handles the request, while the key identifies and authorizes the caller.

Keep secrets outside source files and browser code

For local development, load keys through environment variables or a local secrets file that is excluded from version control. Commit a sample configuration containing variable names and empty placeholders, not working credentials.

In a deployed application, use your hosting platform's secret storage or a dedicated secrets manager. Make each environment receive only the credential it needs. Avoid copying production secrets onto every developer's laptop.

Do not embed a private API key in browser JavaScript or a mobile application distributed to users. Those credentials can be extracted. Instead, let your application call a backend that holds the secret, checks user access, and applies appropriate request controls. Also check that logs and error reports do not capture authorization headers.

Check usage without assuming a key is a budget

Separate keys can help attribute activity when the service reports usage by credential. Check what the dashboard or usage API actually exposes before building a process around it. A key name alone does not guarantee detailed reporting.

Review usage regularly and investigate unexpected changes. If supported, configure project budgets, alerts, and request limits. Treat an alert as a notification, not necessarily a hard stop. Your application may also need its own limits on request frequency and output size.

Replace a key with a small, repeatable handover

Routine replacement is easier when every key has a known owner. Where the provider allows overlapping credentials, create a replacement, update the affected secret stores, deploy, and confirm that requests succeed before revoking the old key.

If a key is exposed, prioritize revoking it promptly. Restore service with a fresh credential, inspect available usage records, and remove the exposure source. Deleting a secret from the latest source file does not remove it from repository history or invalidate copies already taken.

Use a relay when several model projects share tooling

Relay365 is worth considering when separate projects need access to several model families through a pay-as-you-go relay desk. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDK clients. Its API base is https://api.api365relay.com; OpenAI clients add /v1.

Before adopting it, verify the available credential controls, usage reporting, and model access against your project's needs. Create a Relay365 account to try a small, non-production workload before connecting live applications.

The shift handover should stay simple: each project has an identifiable credential, a responsible owner, a safe storage location, and a replacement procedure. That is enough structure to prevent a small credential problem from becoming an all-project scramble.