Google Cloud ADC and Vertex AI

What this path is for

Choose Google Application Default Credentials (ADC) when the 9Miho server should call Gemini or Veo through Vertex AI in your Google Cloud project. The Python provider asks Google for the cloud-platform scope, uses the project saved in the selected profile when present, and otherwise falls back to the project reported by ADC.

This is not the GCP ComfyUI/IAP installer. Vertex ADC authenticates hosted Google model APIs. GCP ComfyUI provisions or connects a GPU VM and carries separate compute, disk, storage, tunnel, and model-license boundaries. See ComfyUI and GPU setup for that path.

Prerequisites in Google Cloud

You need:

• a Google Cloud project with billing enabled;
• the Vertex AI API enabled;
• permission to use Vertex AI, commonly Vertex AI User (roles/aiplatform.user);
• permission to enable services if you will run the enable command, commonly Service Usage Admin (roles/serviceusage.serviceUsageAdmin);
• Google Cloud CLI installed on the same machine and OS account that runs the 9Miho server.

Google’s official references are Vertex AI setup, local ADC setup, and enabling services.

Create local ADC

Replace PROJECT_ID with the exact project ID, not its display name.

gcloud --version
gcloud init
gcloud auth list
gcloud config set project PROJECT_ID

gcloud services enable aiplatform.googleapis.com --project=PROJECT_ID

gcloud auth application-default login
gcloud auth application-default set-quota-project PROJECT_ID

gcloud services list --enabled --filter="name:aiplatform.googleapis.com" --project=PROJECT_ID

gcloud auth application-default login creates local ADC for client libraries. It is separate from the account used by ordinary gcloud commands. Likewise, gcloud config set project changes the CLI default but does not replace the project saved in a 9Miho profile. The quota-project command requires ADC to exist and the account to have serviceusage.services.use on that project.

The local ADC file contains a refresh credential. Do not copy it, commit it, print an access token for 9Miho, or paste any token into Canvas. 9Miho reads ADC through Google’s authentication library on the server machine.

Configure the 9Miho profile

1. Start or restart 9Miho under the same OS account that created ADC.
2. Open Settings → Providers.
3. Select Google · Gemini / Veo.
4. Add a new named profile or select the intended one.
5. Choose Application Default Credentials.
6. Enter GCP project ID. Supplying it explicitly makes the billing and resource boundary visible in the profile.
7. Enter Vertex region. Use the region required by the selected catalog Variant; global is the profile default, while some model paths use or fall back to us-central1.
8. Choose Save settings, then Make default if appropriate.
9. Choose Re-check and read the reported credential state.
10. Select a compatible Google Variant, validate, and review the spend card before running it.

Re-check refreshes the provider’s reported credential surface. After switching the ADC account or replacing local ADC, restart the 9Miho server before the final check so the running adapter cannot retain an older credential object.

ADC detected means the server found a local credential. It does not prove Vertex AI API enablement, billing, IAM, model entitlement, region, quota, or a successful generation. A compatible Variant’s validated Run is the final check.

Service-account impersonation

For a local workstation that should avoid downloading a service-account key, Google supports user ADC with service-account impersonation. The signed-in user needs Service Account Token Creator (roles/iam.serviceAccountTokenCreator) on the target service account. The impersonated service account itself also needs the required Vertex role—normally Vertex AI User (roles/aiplatform.user)—in the project selected by the 9Miho profile.

gcloud auth application-default login --impersonate-service-account SERVICE_ACCOUNT_EMAIL
gcloud auth application-default set-quota-project PROJECT_ID

9Miho’s provider is Python-based, which is supported by this ADC flow. Avoid service-account key files when user ADC or impersonation is sufficient. If an operator deliberately uses GOOGLE_APPLICATION_CREDENTIALS, remember that this environment variable can take precedence over the ADC file and may point the server at stale credentials.

Troubleshooting

Symptom	Check
ADC stays pending or unavailable	Confirm ADC was created on the server machine, under the server’s OS account; restart the server and choose Re-check.
403	Check billing and the Vertex AI API on the profile’s project, then confirm the calling identity—an impersonated service account when used—has roles/aiplatform.user. Check the ADC quota project and serviceusage.services.use separately for quota attribution.
Model unavailable or 404	Check that the selected Variant is available to this project and region; authentication alone does not grant model entitlement.
Wrong project is billed	Check the GCP project ID saved in the selected 9Miho profile. It defines the Vertex resource path and resource/billing project. The ADC quota project controls quota attribution and does not override that profile project; the active gcloud project does not override it either.
A different account appears	Inspect GOOGLE_APPLICATION_CREDENTIALS and the OS account running the server; then recreate ADC intentionally.
API-key profile works but ADC does not	Treat them as separate paths. API-key mode calls the Google API-key surface; ADC mode calls Vertex AI.

Google’s ADC lookup and troubleshooting behavior is documented in how ADC finds credentials and ADC troubleshooting.