⌘K
Ryu Hi Edward, First, I’d edit the post and remove the Team ID. It is not an API key, but it is still better not to leave account identifiers public. For the 403 itself, I’d separate “the key is recognized” from “the workspace can run inference.” The fastest check is to test both model listing and a tiny completion with the same key from a local terminal: curl -i "ai-gateway.vercel.sh/v1/models" \ -H "Authorization: Bearer $AI_GATEWAY_API_KEY" \ -H "Content-Type: application/json" Then: curl -i "ai-gateway.vercel.sh/v1/chat/completions" \ -H "Authorization: Bearer $AI_GATEWAY_API_KEY" \ -H "Conten
Edward Hi Ryu, Thank you for your reply. Testing /v1/models returns 200 but /v1/chat/completions returns 403 access_denied HTTP/2 403 cache-control: public, max-age=0, must-revalidate content-type: application/json date: Mon, 22 Jun 2026 11:38:32 GMT server: Vercel strict-transport-security: max-age=63072000; includeSubDomains; preload vary: rsc, next-router-state-tree, next-router-prefetch, next-router-segment-prefetch x-matched-path: /v1/chat/completions x-vercel-cache: MISS x-vercel-id: sin1::fra1::spqsq-1782128311682-72dfa5316781
Ryu Hi Edward, Thanks, that result is the important one. Since /v1/models returns 200, the Gateway endpoint, bearer token format, and key recognition are likely correct. Since /v1/chat/completions returns 403 access_denied, this does not look like a local network issue or a model-listing issue anymore. I’d try one last user-side check: create a brand-new AI Gateway API key from the same workspace after the credit top-up, then run the same two curl tests again. If the new key still gives: GET /v1/models => 200 POST /v1/chat/completions => 403 access_denied then I don’t think more SDK/app debugging
Amy Egan If you can tell me more about the problem, I’d be happy to connect with the engineering team to get you the help you need or share your feedback!
Erik Sandquist Well I had a problem where AI gateway selects another provider than the BYOK option, but it doesn't disclose a reason for it. The status is ok for the provider, tried testing the key again and it worked and have balance at the provider but still chooses another provider which massively drained my Vercel balance since without BYOK i get charged about 5-6x more.
Pauline P. Narvas Are you talking about the AI SDK? Currently, the @ai-sdk/azure provider is specifically designed for Azure OpenAI deployments. While Azure does host models from Anthropic and others, these aren’t accessible through our Azure provider yet. I recommend checking out AI Gateway: vercel.com/ai-gateway/models
Kejvi Dema @pawlean - I believe there is confusion. Yes, I am referring to AI Gateway, and yes, I am well aware that Azure is not a provider for the cited models, and that’s the reason I am writing this and requesting/recommending Vercel to add this in their offering.
Pauline P. Narvas I was confused by your initial post, I’ve changed your post to Feedback and will share with our product team. Thank you!
Pauline P. Narvas Thanks for reporting this feature gap! You're correct - while the AI SDK supports imageConfig for Google Gemini models (via PR #12059), this isn't currently available through the AI Gateway REST API. You could try the following workarounds though: Use the AI SDK with TypeScript (already supports this) If using BYOK, make direct calls to Google's API with imageConfig parameters Thanks again! Keep an eye out for updates :)
René Schubert Thanks for pointing to the PR, it helped me understand a bit more. However I’m not sure about the difference between generateText({ model: google("gemini-3-pro-image-preview"), // from the test in the PR /* … / }); and generateText({ model: "google/gemini-3-pro-image", // what we're using / … */ }); Is it basically the same and for both the structure of the providerOptions should be providerOptions: { google: { responseModalities: ['TEXT', 'IMAGE'], imageConfig: { aspectRatio: '16:9', imageSize: '4K', }, }, }, or does it differ, depending on whether I use @ai-sdk/google or not?
