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 f...
For further actions, you may consider blocking this person and/or reporting abuse
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.