AI Gateway BYOK 403 in Production, same key works locally

AI SDK
1 
Hi everyone,

I’m running into a strange Vercel AI Gateway BYOK issue and would appreciate help from the Vercel team.

Summary:
My app uses Vercel AI Gateway with BYOK for an Azure-backed GPT model. The same AI Gateway API key and same model work locally, but fail when called from a Vercel Production deployment.

Error:
The Production request fails with HTTP 403:

byok_requires_paid_credits

Message:

Bring Your Own Key (BYOK) is available only with paid credits.

What is confusing:
I have AI Gateway credits available on the relevant Vercel account/team. Also, from the same Production runtime, calling `gateway.getCredits()` succeeds and returns a positive balance.

What I verified:
- `AI_GATEWAY_API_KEY` is present in the Vercel Production runtime.
- The key length matches the expected key.
- `VERCEL_OIDC_TOKEN` is not present in the runtime diagnostic.
- `gateway.getCredits()` succeeds in Production.
- `generateText()` fails in Production with `byok_requires_paid_credits`.
- The exact same API key and exact same model work locally.
- The local request successfully routes through BYOK to Azure.
- The Production failed request shows `providerAttemptCount: 0`, so it appears to fail before any actual provider attempt is made.

The model used is:

azure/gpt-5.4-mini

A representative failed Gateway routing object from Production:

{
  "originalModelId": "azure/gpt-5.4-mini",
  "resolvedProvider": "azure",
  "fallbacksAvailable": ["openai"],
  "canonicalSlug": "openai/gpt-5.4-mini",
  "modelAttemptCount": 1,
  "modelAttempts": [
    {
      "canonicalSlug": "openai/gpt-5.4-mini",
      "success": false,
      "providerAttemptCount": 0,
      "providerAttempts": []
    }
  ],
  "totalProviderAttemptCount": 0
}

The local successful request, using the same key and model, shows:

{
  "finalProvider": "azure",
  "credentialType": "byok",
  "statusCode": 200
}

Question:
Is AI Gateway applying a different BYOK / paid credits eligibility check when the request originates from a Vercel Production runtime, compared with a local request using the same AI Gateway API key?

It looks like the API key itself is valid, because:
1. It works locally.
2. `getCredits()` works from Production.
3. The failure happens before provider execution.

I can provide private details such as project ID, deployment ID, log links, and generation IDs to Vercel staff if needed, but I prefer not to post them publicly.

Thanks.
2

Same story here, have purchased credits, but when using my own Google Studio key I’m getting the

HTTP 403 Test Request Failed
Bring Your Own Key (BYOK) is available only with paid credits.

3

Hi RainX,

Since the same model works locally but Production returns byok_requires_paid_credits, I’d first rule out a team/env mismatch rather than focusing on Azure itself.

BYOK has two separate pieces:

  • the AI Gateway API key used by your app

  • the provider credential added in the AI Gateway BYOK dashboard

The provider BYOK credential is scoped to a Vercel team, and the team still needs AI Gateway credits available even when BYOK is used. So if Production is using an AI Gateway key from a different team, or an older key created before the BYOK/credits setup was fixed, it could explain why getCredits() and generateText() behave differently than expected.

A clean test would be:

  1. In the same Vercel team where the Azure BYOK key is configured, create a new AI Gateway API key.

  2. Replace the Production AI_GATEWAY_API_KEY with that new key.

  3. Redeploy the project, not just save the env var.

  4. Trigger one request and check the new generationId.

Also make sure the deployed app is not accidentally using the Azure/OpenAI provider key directly as the Gateway auth token. Requests to AI Gateway should authenticate with the AI Gateway key, while the Azure credential should stay in the BYOK settings.

The Vercel BYOK docs mention the team-scoping and paid-credit requirement here:

If the new same-team Gateway key still produces providerAttemptCount: 0, then I’d include the generation ID and timestamp in a support follow-up, because that would point to the request being rejected before it reaches the provider.