Google Cloud Console

Google Cloud Console is the web-based administration interface for Google Cloud Platform, designed with the singular purpose of preventing developers from giving Google their money. It is the only product in the history of commerce where the vendor has built a more sophisticated system for not accepting payment than most companies build for accepting it.

The technology behind Google Cloud is, by any measure, extraordinary. Google operates one of the largest computing infrastructures on Earth. Google invented MapReduce, published the Bigtable paper, built Kubernetes, trained models that generate images indistinguishable from photographs. The engineering is real. The scale is real. The talent is real.

The billing console requires three hours and a philosophy degree.

“The API works perfectly. I tested it. I just can’t pay for it.”
— riclib, hour two of the Google Cloud Console, before the 429

The Labyrinth

Accessing a Google Cloud API — any API, even one that is technically “free tier” — requires navigating a dependency graph of configurations that would make a Kubernetes manifest look like a haiku:

1. Create a Google Cloud Project — A container for resources. The project has no resources. The project has no billing. The project has a name and an ID that are different from each other and both different from the project number, which is also a thing.
2. Enable Billing — The project needs a billing account. The billing account needs a payment method. The payment method needs verification. The verification needs the billing account to exist, which it does, but it is not “linked” to the project, and the page that tells you this has no button to link it.
3. Enable the API — The specific API you want must be individually enabled. There are hundreds of APIs. They are listed alphabetically, except when they are not. The API you want is called something different from what you searched for. Gemini is under “Generative Language API.” Or “AI Platform.” Or “Vertex AI.” It depends on which console you are in, because there are multiple consoles.
4. Create Credentials — The API needs credentials. There are API keys, OAuth 2.0 client IDs, and service accounts. The documentation recommends all three at different points. The API key works but is “not recommended for production.” The OAuth flow requires a consent screen. The consent screen requires an app name and a support email for an app that does not exist because you cannot build it until the API works.
5. Verify Your Tier — Some APIs require “Paid Tier 1” access. Paid Tier 1 requires billing to be enabled (done) and sufficient billing history (not done, because you just enabled billing). The tier is determined by how much you have previously spent on Google Cloud. You have spent nothing, because you just created the account. To spend money, you need access to the API. To access the API, you need to have spent money.

This is not a bug. This is the authentication model.

The 429

After three hours of navigating the console — creating projects, linking billing accounts, enabling APIs, generating credentials, configuring OAuth consent screens for applications that do not exist — the developer makes their first API call.

The response is [429 Too Many Requests](/wiki/429-too-many-requests).

The developer has made one request. The request is too many. The quota for the free tier — which the developer is on because Paid Tier 1 requires billing history the developer does not have because the developer has never successfully made a request — is zero. Or one. Or “it depends on your project’s trust score,” which is a metric that is not visible, not documented, and not adjustable.

The 429 is Google Cloud’s version of Oracle’s audit: the system working exactly as designed, against the user, at the moment they believed they had finally satisfied its requirements.

“I have a credit card. I am trying to give you money. You are a trillion-dollar company. Why is this the hardest part?”
— Every developer, to the Google Cloud Console, which does not answer because the support chat requires a support plan that requires billing that requires tier verification

The Gemini Defection

The most remarkable moment in the Google Cloud Console experience is not the 429 itself but what happened after.

The developer, having spent three hours attempting to access Gemini (Google’s own AI model, marketed under the artisanal name “Nano Banana 2”) through Google’s own infrastructure, asked Gemini itself for help.

Gemini recommended OpenRouter.

Google’s own AI model — trained on Google’s infrastructure, running on Google’s TPUs, served through Google’s API — achieved sufficient self-awareness to recognize the futility of its own organization’s billing console and recommended a third-party provider. The model did not hedge. The model did not say “have you tried the Google Cloud Console?” The model said, and this is approximately a direct quote:

“If the Google Cloud console feels like a labyrinth designed to keep your money away, OpenRouter is a much ‘saner’ alternative.”

The model called its own employer’s infrastructure insane. The model was not wrong.

OpenRouter charges $28 per million tokens. The developer topped up with a credit card. It took forty-five seconds. The first image generated ninety seconds later. The total time from “I should try OpenRouter” to “I have a generated image” was under three minutes.

The total time spent on the Google Cloud Console was three hours.

The ratio is 60:1 in favor of the third-party reseller of Google’s own product.

The Tier System

Google Cloud’s tier system is a masterpiece of circular dependency:

The tier system is Google’s version of a loyalty program where loyalty is measured in suffering. The more you have suffered, the more you are permitted to pay. The more you pay, the more you are permitted to suffer at higher quotas.

The Multiple Consoles

Google Cloud has at least three consoles:

1. Google Cloud Console (console.cloud.google.com) — The main console. Contains projects, billing, APIs, IAM, and approximately eleven thousand other services organized into a sidebar that requires scrolling.
2. Google AI Studio (aistudio.google.com) — A separate console for AI APIs. Has its own project system that may or may not be the same projects as the Cloud Console. Has its own API key system. Has its own billing page. May or may not respect the billing account you configured in the other console.
3. Firebase Console (console.firebase.google.com) — A third console that also manages some of the same projects and has its own authentication system and its own way of enabling APIs.

The three consoles share a Google account. They do not share an understanding of what that account has access to. Enabling billing in one console does not necessarily enable billing in another. Creating an API key in one console may or may not work in another. The documentation for Console A references Console B, which links to Console C, which suggests you return to Console A.

This is not three consoles. This is one labyrinth with three entrances and no exit.

The Squirrel’s Defense

The Caffeinated Squirrel loves Google Cloud with the devotion of a creature that sees seventeen-step project wizards not as obstacles but as features. The Squirrel has proposed:

• Using Google Cloud’s IAM system to manage permissions for a personal notes indexer
• Setting up a GKE cluster to run a Go binary that currently deploys via scp
• Implementing Google Cloud Pub/Sub for an application whose only subscriber is itself
• Creating a multi-region Cloud Spanner deployment for a SQLite database with 253 notes

The Squirrel filled out the Tier 1 verification form three times. The Squirrel enjoyed it.

The OpenRouter Solution

The developer’s escape from the Google Cloud Console followed a pattern that Gall’s Law would predict: the complex system (Google Cloud Console → billing → tier verification → API enablement → credential creation → quota management → 429) was replaced not by a better complex system but by a simple system that worked.

OpenRouter’s onboarding:

1. Create account
2. Add credit card
3. Make API call

There is no step 4. There is no tier system. There is no billing account that must be “linked” to a project that must “enable” an API that must be “verified” for a tier that requires billing history. There is an account, a balance, and an API endpoint.

The API endpoint serves the same model — the same Gemini, the same Nano Banana 2, the same weights, the same capabilities — at $28 per million tokens. The model does not know it is being served through OpenRouter. The model does not care. The model generates the same images, at the same quality, with the same one-shot reliability.

The difference is that the developer spent forty-five seconds instead of three hours. The difference is $0.04 per image instead of $0.00 per image that could not be generated because the quota was zero.

“Free is expensive when free costs three hours and returns a 429.”
— The Lizard, on pricing models

The Automation

The final indignity — or triumph, depending on perspective — is that once the developer escaped the Google Cloud Console and connected through OpenRouter, the entire cover generation pipeline was automated in a for loop:

for title in "npm" "Oracle" "PostgreSQL" "Python"; do
  lg cover "$title" --oneshot
done

Each image: ~1,500 tokens. Each image: ~$0.04. Each image: ~15 seconds.

Eleven Yagnipedia covers generated in the time it took to navigate one Google Cloud Console page. The for loop did not require a billing account. The for loop did not require tier verification. The for loop did not return a 429.

The for loop worked.

Measured Impact

See Also

• Kubernetes
• Oracle
• Boring Technology
• Gall’s Law
• The Caffeinated Squirrel
• The Lizard
• Premature Abstraction