Three API Keys for a Team Running Sustained Workloads

01 · Step 1: Define three environments before issuing credentials

When a team runs sustained AI workloads, a shared API key turns a local experiment into a production risk. A developer can accidentally launch a large batch, a staging retry loop can consume the shared balance, and a leaked credential can force every service to change at once. Separate keys give each environment a distinct credential boundary, although they do not automatically isolate funding or capacity.

Write down what each environment is allowed to do. Development supports interactive experiments. Staging validates releases with controlled traffic. Production handles approved workloads. Give each environment an owner responsible for access, usage review and credential rotation.

02 · Step 2: Create separate keys without assuming separate balances

Provision a distinct credential for development, staging and production through your available credential-management controls. Record each key's environment, owner, creation date and deployment destinations in an inventory. Store references to secrets, never the secret values themselves, in that inventory.

Quanta is a practical fit for teams consolidating heavy workloads: its pay-as-you-go relay lets one balance cover multiple model families. Open a Quanta account to consolidate that usage, then make environment separation part of your initial setup rather than a cleanup task.

Separate credentials are not separate budgets. With a shared balance, development spending can still affect production. Check which credential restrictions and spending controls are available; where they are absent, enforce your policies through an application gateway or job scheduler.

03 · Step 3: Inject only the matching environment's secret

Use your secret manager and deployment system to deliver the correct credential at runtime. Keep production secrets out of developer laptops, source repositories, container images and staging jobs. Local tools should receive development credentials only.

• › Development: supply the development secret through a local secret store or an approved runtime injection mechanism.
• › Staging: let the staging deployment identity retrieve only the staging secret.
• › Production: restrict secret retrieval to approved production workload identities.

Keep configuration names consistent across environments, but change the underlying secret reference. This reduces deployment differences without copying credentials between systems. Quanta works with Claude Code, Codex, Gemini CLI and any OpenAI SDK; apply the same environment discipline wherever credentials enter those tools.

04 · Step 4: Give experiments and release tests explicit limits

Define an environment policy for concurrency, maximum output length, batch size, retries and allowed models. A development test might use Gemini 2.5 Flash for routine integration checks, while staging exercises the production configuration with Claude Sonnet 5.5 when that is the selected model. Validate behavior on the actual production model before release.

Enforce these limits in infrastructure you control unless you have verified equivalent provider-side controls. Bound retries and use backoff so a failing staging job cannot become an uncontrolled traffic generator. Reserve production capacity in your scheduler rather than assuming a different key creates a reserved lane.

05 · Step 5: Attribute token spending to each environment

Attach an environment label, service name and request identifier to your internal usage records. Do not log authorization headers or raw keys. Track input tokens, output tokens, cache writes and cache reads separately: Quanta meters calls on real tokens, with cache writes and cache reads priced separately.

Compare recorded usage with billing data and investigate unexplained changes. Staging traffic may be smaller yet less cache-efficient than production, so request counts alone are a weak budget signal. Alert on environment spending trends and unusual concurrency, not just a low shared balance.

06 · Step 6: Test key rotation and release boundaries

Rotate development first, then staging, before applying your tested procedure to production. Where overlapping credentials are supported, deploy the replacement, confirm successful traffic and revoke the old key. Otherwise, plan a coordinated cutover. Test that missing credentials fail closed rather than falling back to another environment's secret.

07 · Step 7: Promote configuration, never production secrets

Promote reviewed application code and policy settings through your release pipeline, but resolve credentials independently in each environment. Before a large rollout, verify the secret reference, model selection, limits and usage labels. Three keys become useful operational boundaries only when access controls, budget safeguards and release checks reinforce them.