Your new Gemini API key starts with AQ., not AIza

If you generated a Gemini API key recently and it came back starting with AQ.Ab instead of the familiar AIza, nothing is wrong with your account. When I first saw it, I assumed mine had been flagged or rate limited. It had not. Google is rotating the whole key format, and new keys from AI Studio now ship in the new shape.

The part that costs you time is not the prefix. It is that the new key works on some routes and gets rejected on others, sometimes with an error that blames the key while the key is perfectly valid. I'll get to that, because it is the thing most likely to send you debugging in the wrong direction.

Checked: June 2026 Issued from: Google AI Studio (free tier) Routes tested: native generativelanguage.googleapis.com and OpenAI-compatible /v1beta/openai Reference: Google docs, "Using Gemini API keys" https://ai.google.dev/gemini-api/docs/api-key

What Google actually changed

Gemini is moving from the old Standard key (AIza...) to a new Auth key (AQ.Ab...). Keys created in AI Studio default to Auth keys now, which is why a format you saw yesterday looks different today.

The dates are the reason this matters rather than being a cosmetic change. Unrestricted Standard keys started getting rejected on June 19, 2026, a deadline that has already passed as I write this. In September 2026, Standard keys get rejected across the board, restricted or not. So the AIza format is on its way out, and AQ. is where everything lands.

There is a softer edge to the June cutoff worth knowing. A Standard key with an explicit restriction keeps working past the 19th, so the shutdown runs in stages: unprotected keys first, restricted ones later in September. One more behavioral note for anyone who tracks usage in the Cloud Console. Requests made with an Auth key do not appear in Google Cloud's service account usage metrics, since the key and project sit on the AI Studio side. If your dashboards go quiet, that is why, and the traffic is still flowing.

What breaks, and how to tell

Here is the map, from my own testing and from what people are reporting on the official forum.

The one to watch is the second row. An AQ. key that returns a clean 200 on the native route can come back as 401 invalid_api_key the moment a tool quietly hands it to an OpenAI-compatible transport. The key is alive. The message says it is not. If you take the error at face value and start regenerating keys, you will burn an afternoon on a key that was never the problem. Some OpenAI-compatible setups reject it earlier still, with Multiple authentication credentials received, as though you passed your credentials twice. A few desktop tools that hard-assume the AIza shape throw the same 401.

Native traffic is the calm path. Hit generativelanguage.googleapis.com directly with the key as a query param or header and AQ. behaves exactly like the old key. The official SDKs (google-genai and the rest) pass it that way under the hood, so through an SDK you likely will not notice anything changed. I maintain a WordPress plugin whose Gemini path goes native, and the AQ. key went straight through; if I had been on an OpenAI-compatible route, every user pasting a fresh key would have met a 401 and I would have met a queue of bug reports.

So the diagnostic is short. Before you suspect the key, look at the route. A key that works on native and fails on Bearer is not broken; it is being passed somewhere that does not accept the new format yet.

Still on an AIza key?

If you are running on an AIza key today and it still answers, that is not the same as being safe. The dates above decide that.

Open your AI Studio key list and look for the Unrestricted label. That is the kind that already stopped on June 19. To keep one alive, hover the label on the API Keys page, click Add restrictions, pick Restrict to Gemini API only, and confirm with Restrict key. It is now scoped to the Gemini API and runs past the June cutoff.

Read that as a stay of execution, not a fix. September takes Standard keys as a class, so a restricted AIza key stops then too. The restriction just gives you room to migrate without scrambling. The endpoint of all of this is an AQ. Auth key.

Two practical notes. Restricting a key needs apikeys.keys.update on the project, which API Keys Admin and Editor already carry. And if a key is shared across other Google APIs, which is a setup better avoided, you restrict it from the Cloud Console rather than AI Studio. Separately, you may run into forum threads about accounts that can no longer create AIza keys at all. That is a different problem. The AQ. rollout is the everyone change, and a new key arriving as AQ. says nothing bad about your account.

The short version

Not much to do, really. On a new AQ. key, confirm your traffic is going to the native Gemini endpoint. On an OpenAI-compatible path, test whether Authorization: Bearer actually accepts the AQ. key before you ship it to anyone. On an old AIza key, restrict it for breathing room and move to AQ. before September.

And when a Gemini key starts failing with a confident invalid_api_key, check the route before you touch the key. Most of the time the key was telling the truth and the transport was lying.

Reference: Google AI for Developers, "Using Gemini API keys" https://ai.google.dev/gemini-api/docs/api-key