How to Fix 'invalid API key when scaling' in AutoGen (TypeScript)

When AutoGen says invalid API key when scaling, it usually means your agent process is trying to create a new model client in a different runtime path than the one you tested locally. In TypeScript, this often shows up when you move from a single local agent call to multiple workers, remote executors, or a scaled deployment and the environment variable is missing, stale, or not being passed through.

The key detail: this is usually not an AutoGen bug. It’s almost always a config propagation problem between your app, your runtime, and the OpenAI-compatible client AutoGen is using.

The Most Common Cause

The #1 cause is simple: you set the API key in one place, but the scaled worker process never receives it.

In AutoGen TypeScript, this often happens when you instantiate OpenAIChatCompletionClient at module load time and assume process.env.OPENAI_API_KEY will always be present. That works locally, then fails when the app scales across containers, serverless invocations, or worker threads.

Broken pattern vs fixed pattern

// ❌ Broken
import { OpenAIChatCompletionClient } from "@autogen/openai";

const modelClient = new OpenAIChatCompletionClient({
  model: "gpt-4o-mini",
  apiKey: process.env.OPENAI_API_KEY,
});

// Later in a worker or scaled task
await modelClient.create({
  messages: [{ role: "user", content: "Hello" }],
});

// ✅ Fixed
import { OpenAIChatCompletionClient } from "@autogen/openai";

function buildModelClient() {
  const apiKey = process.env.OPENAI_API_KEY;

  if (!apiKey) {
    throw new Error("Missing OPENAI_API_KEY in this process");
  }

  return new OpenAIChatCompletionClient({
    model: "gpt-4o-mini",
    apiKey,
  });
}

const modelClient = buildModelClient();

If you’re using a scaled runner, each process needs its own environment. Don’t rely on the parent process having already loaded .env.

Other Possible Causes

Here are the other failure modes I see most often.

1) Wrong environment variable name

AutoGen doesn’t magically read every provider key name. If your code expects OPENAI_API_KEY but your deployment uses AZURE_OPENAI_API_KEY, you’ll get auth failures that look like scaling issues.

// ❌ Wrong variable name for this client
const apiKey = process.env.AZURE_OPENAI_API_KEY;

new OpenAIChatCompletionClient({
  model: "gpt-4o-mini",
  apiKey,
});

// ✅ Match the client to the env var actually used
const apiKey = process.env.OPENAI_API_KEY;

If you’re using Azure OpenAI with AutoGen, make sure you’re also using the Azure-specific client/config rather than an OpenAI client pointed at Azure endpoints incorrectly.

2) .env loaded in dev only

A lot of teams use dotenv in local development and forget that production workers don’t load .env files unless explicitly configured.

// ❌ Only works if this file is executed before anything else
import "dotenv/config";

In Docker or serverless, prefer injecting env vars at deploy time:

docker run -e OPENAI_API_KEY=... my-autogen-app

Or in Kubernetes:

env:
  - name: OPENAI_API_KEY
    valueFrom:
      secretKeyRef:
        name: autogen-secrets
        key: openai-api-key

3) Key passed to one agent but not another

When you scale agents, it’s common to create multiple AssistantAgent instances or tool runners. One agent gets a valid client; another gets default config and fails on first request.

// ❌ One agent has config, another silently doesn't
const assistant = new AssistantAgent({
  name: "assistant",
  modelClient,
});

const critic = new AssistantAgent({
  name: "critic",
  // forgot modelClient here
});

Fix by centralizing construction:

// ✅ Shared factory for all agents
const sharedModelClient = buildModelClient();

const assistant = new AssistantAgent({
  name: "assistant",
  modelClient: sharedModelClient,
});

const critic = new AssistantAgent({
  name: "critic",
  modelClient: sharedModelClient,
});

4) Proxy or gateway rewriting auth headers

If you’re running through an internal API gateway, reverse proxy, or egress filter, it may strip Authorization headers or rewrite requests. The error can surface as 401 Unauthorized, invalid_api_key, or AutoGen’s wrapper message around the upstream failure.

Check for configs like:

proxy_set_header Authorization "";

Or custom fetch wrappers that drop headers:

// ❌ Custom transport drops auth header
fetch(url, {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    // Authorization missing here after refactor
  },
});

How to Debug It

Use this sequence to isolate the issue fast.

1. •

   Log the key presence at process start

   • •Don’t print the secret.
   • •Just confirm whether it exists in each worker/container.

   console.log("OPENAI_API_KEY present:", Boolean(process.env.OPENAI_API_KEY));
   

2. •

   Check where the failure happens

   • •If it fails only after scaling out, compare main process vs worker.
   • •If it fails immediately on startup, your env injection is broken.
   • •If it fails only for one agent path, that agent likely missed config.
3. •

   Inspect the exact upstream error

   • •AutoGen often wraps provider errors.
   • •Look for messages like:
     • •401 Unauthorized
     • •Incorrect API key provided
     • •invalid_api_key
     • •OpenAIAuthenticationError
   • •The wrapper message may say “when scaling,” but the real cause is usually underneath.
4. •

   Recreate with a minimal single-process script

   • •Use one AssistantAgent and one explicit client.
   • •If that works locally but fails in deployment, your runtime config is wrong.
   • •If that fails too, your key or endpoint is invalid.

Prevention

• •Build clients through a single factory function that validates required env vars before any agent starts.
• •Inject secrets per runtime environment; don’t depend on .env files outside local dev.
• •Add a startup health check that verifies OPENAI_API_KEY exists and can reach the provider before accepting traffic.

If you want to avoid this class of bug entirely, treat API keys as runtime dependencies of each worker process, not application globals. That’s the difference between something that works on your laptop and something that survives scale.

Keep learning

• •The complete AI Agents Roadmap — my full 8-step breakdown
• •Free: The AI Agent Starter Kit — PDF checklist + starter code
• •Work with me — I build AI for banks and insurance companies

By Cyprian Aarons, AI Consultant at Topiax.