I created a free Gemini API key in Google AI Studio. When I went to copy it, I stopped. It started with AQ.Ab. Not the AIza I had been looking at for as long as I can remember.
My first thought was that something had gone wrong with my account. A leaked key, or a restriction, or some flag on the project. I looked into it, and it was none of that. Google is partway through changing how API keys are issued, and a freshly created key now comes out in the new format. Nothing broke. This is the plan.
That said, you can't drop the new key into every path and expect it to work. Some routes reject it. I run a WordPress plugin called Rapls AI Chatbot, and one of its no-card onboarding paths uses the Gemini free tier, so the first thing I did was check what was affected. Here is the short version before the details. The new AQ. key works fine on the native Gemini endpoint. It gets rejected on OpenAI-compatible endpoints and by some third-party tools that assume the AIza format.
Checked: June 2026
Issued from: Google AI Studio (free tier)
Routes tested: nativegenerativelanguage.googleapis.comand OpenAI-compatible/v1beta/openai
Reference: Google docs, "Using Gemini API keys" https://ai.google.dev/gemini-api/docs/api-key
From AIza to AQ., what is actually happening
Google is moving Gemini API keys from the old Standard key (AIza...) to a new Auth key (AQ.Ab...). Keys you create in AI Studio now come out as Auth keys automatically. So someone who saw AIza yesterday gets AQ. today. That is what happened on my end.
There are dates attached, and this was the part that mattered most. Starting June 19, 2026, the Gemini API began rejecting requests from unrestricted Standard keys. By the time I am writing this, that deadline has already passed. Then in September 2026, Standard keys get rejected outright. Restricted or not, an AIza Standard key stops working after September.
One thing worth adding. A Standard key with an explicit restriction keeps working past June 19. So it is not that every AIza key died on the 19th. The unprotected ones go first, and the rest follow. It is a staged shutdown.
Auth keys behave a little differently in one place. Requests authenticated with an Auth key do not show up in Google Cloud's service account usage metrics. The project and key live on the AI Studio side. If you have been watching requests in the Cloud Console, your numbers may stop adding up, and that is why.
The trap I hit was compatibility, not the key itself
The format change matters less than the compatibility fallout. The AQ. key has a few known snags. Here is what I saw in my own testing alongside what people are reporting on the official forum.
| Route | How the key is passed | What the AQ. key does |
|---|---|---|
| Native Gemini |
?key= query or x-goog-api-key header |
Works. curl returns 200 |
| OpenAI-compatible |
Authorization: Bearer to /v1beta/openai/...
|
400 with Multiple authentication credentials received. 401 in some implementations |
| AIza-assuming third party | Tool expects the AIza format internally |
401 invalid_api_key |
Native is fine. If you hit generativelanguage.googleapis.com directly and pass the key as a query param or header, AQ. goes through the same as before. The official SDKs (google-genai and friends) handle that internally, so going through an SDK you probably will not even notice.
The OpenAI-compatible path is where it jams. Send an AQ. key with Authorization: Bearer to an OpenAI-compatible endpoint and it can come back with Multiple authentication credentials received, as if you passed credentials twice. In the same family of reports, a key that returns 200 through the native route still comes back as 401 invalid_api_key once a tool quietly routes it through an OpenAI-compatible transport. The nasty part of that second case is that the key is alive, but the error says the key is invalid. Trust the message, blame the key, and you never get out of the loop.
Some desktop tools that assume the AIza format throw the same 401.
In my case, the plugin talks to Gemini natively, so the AQ. key sailed through. To be safe I ran a new AQ. key through a full round trip, and it sent and received without trouble. I am folding that confirmation into the plugin's guidance in an update going out the next day. If I had been routing through an OpenAI-compatible path, users would have hit a 401 the moment they pasted a new key. With something you ship, your code being correct does not help. What piles up is a stack of "I entered the key and it will not work" reports. I was glad I checked first.
If you are still on an AIza key
This part I will spell out. If you are running on a key that starts with AIza and it still works, that is not a reason to relax. The dates above are why.
Check whether the key is restricted. In the AI Studio key list, if a key carries the Unrestricted label, that is the kind that stops after June 19. To keep it alive, restrict it. Hover the Unrestricted label on the API Keys page, click Add restrictions in the dialog, choose Restrict to Gemini API only, and confirm with Restrict key. Now it is locked to the Gemini API and keeps running past June 19.
This restriction only buys time. September pulls in Standard keys as a whole, so even a restricted AIza key eventually stops. Treat it as breathing room for an unhurried migration, nothing more. The destination is the AQ. Auth key.
Restricting a key needs the apikeys.keys.update permission on the relevant Google Cloud project, which the API Keys Admin and Editor roles already include. If your key is shared across other Google APIs (not a setup you want), you restrict it from the Cloud Console rather than AI Studio.
For what it is worth, the forum also has a separate thread about accounts getting restricted and no longer being able to create AIza keys at all. The AQ. issuance here is unrelated. It is the format change that applies to everyone. A new key coming out as AQ. does not mean something is wrong with your account.
One line of action
Put together, there is not much to verify on your end. If you are using a new AQ. key, confirm your traffic goes to the native Gemini endpoint. If you run an OpenAI-compatible path, test on real hardware whether Authorization: Bearer accepts the AQ. key. If you are still on an AIza key, restrict it to buy time and move to AQ. before September. That is the whole list.
Back to where I started. Staring at AQ.Ab in AI Studio with my hand frozen over the copy button, I suspected the key. What I actually had to fix was not the key. It was how I was handing the key to each route. If you froze at the same screen, point your suspicion at the route first.
Reference: Google AI for Developers, "Using Gemini API keys" https://ai.google.dev/gemini-api/docs/api-key
Disclaimer: The experiences and decisions in this post are my own. English isn't my first language, so I use an AI assistant to help draft and edit the writing.
Top comments (13)
I suspect weโre going to see a lot of โGemini API key is brokenโ posts over the next few months ๐. In most cases, the key will be fine and the actual culprit will be an OpenAI-compatible wrapper, SDK, or gateway making assumptions about the old AIza format.
Agreed, and the tell will be that the same key works in a raw call and fails through the wrapper. That points the finger at the layer, not the credential. When I switched, the native Gemini endpoint took the AQ. key with no change, because it never cared about the prefix shape. The breakage shows up exactly where someone validated the key against an
AIzapattern, or where an OpenAI-compatible shim assumed a format it was never promised.That's the part worth saying out loud: a key format was never a contract. Anything regex-matching
AIzato "verify" a key was encoding an assumption the provider didn't owe them, and the AQ. switch just collected the bill. The fix in most of those posts won't be a new key, it'll be deleting a validation that should never have been that specific. Good call flagging the wrapper layer, that's where the noise is going to come from.The interesting part isnโt the new AQ. key format, itโs how many tools accidentally treated AIza as a contract. I suspect weโll see a wave of โGemini API is brokenโ reports where the real issue turns out to be a wrapper, SDK, or regex validation that was making assumptions it shouldnโt have made.
Yeah, that's the real story here. AQ. didn't break anything; it just sent the bill for an assumption a lot of tools had been quietly running on. Treating AIza as a contract was the bug, and a key-format regex is where it usually hides. The wave you're predicting feels right, and I'd bet most of those "Gemini is broken" reports trace back to a validator someone wrote to be helpful. The lesson I'm taking isn't "update the regex from AIza to AQ." It's that validating a credential's shape at all is the mistake. The key is an opaque string the provider can rebrand whenever it likes. The moment your code knows what a valid key looks like, you've welded a provider's current format into your own logic, and you're just waiting for the next prefix to send the next bill. Stop checking the shape, pass it through, and let the API be the thing that says yes or no.
The AQ. migration is a perfect example of why credentials should be treated as opaque values. The API provider owns the format, not the client. Any code that assumed AIza was a permanent contract was essentially introducing a hidden dependency on an implementation detail. The migration didnโt break Gemini; it exposed brittle validation logic that had been sitting unnoticed for years.
The trap you hit is the nasty kind because the error lies to you. A live key coming back as "401 invalid_api_key" sends you chasing a key problem that was never there. I'd have burned an hour on that too. Did the OpenAI-compatible path eventually take the AQ key some other way, or is the only real fix to route those calls back through the native endpoint?
Good question. It splits by which error you actually get. If it's a 400 with
Multiple authentication credentials received, the key is being sent twice (Bearer plus another auth header or a?key=query param); collapse it to a single credential and it usually goes through. If it's the 401invalid_api_keyon a key that returns 200 natively, I haven't found a reliable way to get the OpenAI-compatible path to accept the AQ. key yet, so routing those calls back through the native endpoint is the stable fix for now. Worth checking 400 vs 401 first, since they need different things.ๅใๅ้กใซ้ญ้ใใพใใ๏ผ๐
็งใฏ
AIza...ใงๅงใพใใญใผใ็บ่กใใใใจๆใฃใฆใใพใใใใGoogle AI Studio ใงใฏไปฃใใใซAQ...ใฎใญใผใ็ๆใใใพใใใ่ชฟในใฆใฟใใจใใใGoogle ใฏๅพๆฅใฎๆจๆบ API ใญใผใฎไปฃใใใซใๆฐใใ Auth Key ใใใใฉใซใใง็บ่กใใใใใซใชใฃใใใใงใใใใใใใใฎใฏใๅคใใฎใใญใฅใกใณใใใใฅใผใใชใขใซใSDK ใฎใตใณใใซใไปใงใ
AIzaใๅๆใจใใฆใใใใใไฝใๅ้กใ่ตทใใฆใใใฎใงใฏใชใใใจๅ้ใใใใใใใจใงใใใใฎ่จไบใๆธใใฆใใใฆใใใใจใใใใใพใ๏ผใใใใง็ก้งใชใใใใฐไฝๆฅญใใใใใ็ใใใจใใงใใพใใใ
ใพใใซใใใๅไปใงใใใใญใผ่ชไฝใฏๅ้กใชใใฆใAIza ใๅๆใซใใฆใใๅจใใฎใใญใฅใกใณใใ SDK ใตใณใใซใฎใปใใๅคใใชใฃใฆใใใใจใใใใจใฉใผใฏใญใผใๆใใฎใซใๆฌๅฝใฎๅๅ ใฏใใฎๅๆใฎใปใใซใใใ็ก้งใชใใใใฐใ็ใใใชใใๆธใใ็ฒๆใใใใพใใใใใใใจใใใใใพใใ
Ran into something similar recently โ a rejection that read like a credentials issue but was actually a provider quietly deprecating something I'd hardcoded an assumption around. Same trap: the error message points one way, the real cause is somewhere else entirely.
Appreciate you logging the exact routes you tested. That table alone will save someone an afternoon.
"The error message points one way, the real cause is somewhere else entirely" is the whole pattern, and your version is a cleaner example than mine. A provider quietly deprecating a thing you'd hardcoded an assumption around is exactly it: nothing on your side changed, but the assumption you baked in finally got called. The error talks about credentials because that's the surface the failure happened to surface on, not where it actually lives.
The shared root is that we both encoded a provider's current behavior as if it were a contract. A key prefix, a format, a field that's always been there, and then it isn't, and the breakage shows up wearing the wrong label. The fix in both cases isn't a new value, it's deleting the assumption that was too specific to begin with. Appreciate the kind words on the table, that's the part I almost cut, glad it earns its place.
Interesting real-world reminder that โit works in the docsโ and โit works in productionโ are often two different things.
Key format changes like this seem small, but they quietly break a lot of assumptions baked into third-party tooling and wrappers. This is exactly why abstraction layers still need fallback handling and version awareness instead of hard validations.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.