How to Configure OpenClaw Google Gemini

Google Gemini support in OpenClaw covers much more than chat. The provider docs list Gemini models, image generation, media understanding, text-to-speech, music generation, video generation, web search via Gemini Grounding, realtime voice, and thinking controls. That breadth is useful, but it also means you should configure the auth route and defaults deliberately instead of assuming every Google feature uses the same model or runtime path.

30-second answer

For standard API access, set GEMINI_API_KEY or GOOGLE_API_KEY, run onboarding with gemini-api-key, and set a default model such as google/gemini-3.1-pro-preview. To reuse Gemini CLI OAuth, install the gemini command, log in through openclaw models auth login --provider google-gemini-cli --set-default, and keep canonical model refs as google/* with the google-gemini-cli runtime.

Where it fits

Use Google when you want one provider family for text, media understanding, grounded search, image generation, video, music, TTS, or realtime voice. Use API-key auth for standard production paths. Use Gemini CLI OAuth when you intentionally accept the unofficial integration risk and want to reuse an existing CLI login.

Docs-grounded facts

• Google provider id is google.
• GEMINI_API_KEY and GOOGLE_API_KEY are accepted.
• google-gemini-cli runtime reuses Gemini CLI OAuth while keeping google/* refs canonical.
• Google supports image generation, music generation, TTS, realtime voice, media understanding, and web search grounding.
• Gemini 3 models use thinkingLevel rather than thinkingBudget.
• The Gemini CLI OAuth integration is documented as unofficial.

Set it up deliberately

The docs show both interactive and non-interactive onboarding for Gemini API keys. Model verification uses openclaw models list --provider google. Google image generation defaults to google/gemini-3.1-flash-image-preview and supports generation plus edit mode. Google video generation defaults to google/veo-3.1-fast-generate-preview and supports text-to-video, image-to-video, and single-video reference flows with controls such as aspectRatio, resolution, and audio.

Use it safely

The Gemini CLI route is explicitly marked unofficial, and the docs say some users report account restrictions when using OAuth this way. Use it with eyes open. For Gemini 3 and related models, thinking controls use thinkingLevel rather than thinkingBudget, and OpenClaw maps reasoning controls so disabled or dynamic modes are represented correctly.

Common mistakes

The common mistake is using legacy google-gemini-cli/* model refs in new config. The docs say new configs should use google/* model refs plus the google-gemini-cli runtime when local Gemini CLI execution is intended. Another mistake is assuming media defaults are set just because chat works. Configure imageGenerationModel, videoGenerationModel, musicGenerationModel, or TTS provider separately when those surfaces matter.

Verification checklist

List Google models, run a small chat test, then test each enabled media surface independently. If using Gemini CLI OAuth, confirm the gemini command is on PATH and the OAuth flow works from the gateway host. If login fails after browser flow, check the documented GOOGLE_CLOUD_PROJECT or GOOGLE_CLOUD_PROJECT_ID hint.

Playbook angle

The OpenClaw Playbook treats Google as a multi-surface provider. Decide which surfaces you want, set each default explicitly, and record the auth route so future agents do not confuse API keys with CLI OAuth.

Operator note

How to Configure OpenClaw Google Gemini works best when it is written into a small runbook instead of left as tribal knowledge. Record the intended owner, the exact config surface, the channel where results should appear, the allowed inputs, the expected output, and the rollback step. OpenClaw gives agents broad tools, but the durable value comes from making each tool boring, repeatable, and auditable. I would rather have one well-scoped Google config workflow that survives a restart than five clever demos nobody can safely run next week. If the runbook cannot explain when not to use it, keep refining before automation becomes default.

Keep the final proof simple: name the source doc, run the smallest check that proves the path works, and save the result where the next operator will look first.