How to Set Up Gemini 3.7 Flash in Home Assistant

As of Q3 2026, the Home Assistant setup I would actually run is the Google Gemini API route through Home Assistant’s Google Gemini integration, with the model ID gemini-3.7-flash. This is not Google’s consumer “Gemini for Home” path, and it is not a vague “pick the latest Gemini model” setup. Gemini 3.7 Flash reached general availability on August 13, 2026, and Google’s model docs list the exact API model ID as gemini-3.7-flash.[1][2]

My status label for this recipe is: usable, worth testing first, and cheap only if you plan for the January 1, 2027 price change. Introductory API pricing is $0.75 per 1 million input tokens and $3.75 per 1 million output tokens through December 31, 2026; standard pricing is scheduled to double to $1.50 input and $7.50 output per 1 million tokens on January 1, 2027.[1]

The reason I am willing to use this model for a Home Assistant conversation agent is not because a benchmark number magically transfers to lights, locks, thermostats, and speakers. Google reports Gemini 3.7 Flash at 30.4% on AutomationBench versus 17.0% for an earlier baseline, which is useful directional evidence that the model is better at multi-step automation-like work.[1] It is still only safe in a home after you verify the model in your installed Home Assistant release, audit every exposed entity, and budget for tokens after the introductory window ends.

What this recipe installs

Home Assistant’s Google Gemini integration is the official integration point here. It was introduced in Home Assistant 2023.6, and Home Assistant’s documentation says it can provide a conversation agent, speech-to-text, and text-to-speech. The same documentation reports it is used by 6.2% of active installations.[3]

Gemini 3.7 Flash itself has a very large context window: 1,048,576 input tokens and 65,536 output tokens according to the Gemini API model documentation, which was last updated on 2026-08-13.[2] Treat that as capacity, not permission to shovel your whole house state, every automation trace, and a novella-length instruction prompt into every request.

One more date matters if you expect the model to answer general knowledge questions inside the same assistant: Google DeepMind’s model card lists a March 2026 knowledge cutoff.[4] For smart-home control, that is less important than your exposed entities and your Home Assistant state. For current device documentation, release notes, or troubleshooting a breaking change, do not assume the base model knows what changed after that cutoff.

Setup sequence

The safe order is boring on purpose: API key, integration, model verification, conversation agent, restrained instructions, exposed-entity audit, control testing, then TTS. If you wire a pleasant voice first, you can make a poorly scoped assistant feel finished before it is safe.

1. Create a Google AI Studio API key for the Gemini API.
2. In Home Assistant, add the Google Gemini integration and paste the API key.
3. Open the integration’s conversation-agent configuration and look for gemini-3.7-flash.
4. If the model is selectable or accepted, set it as the model for the agent.
5. Set the Gemini conversation agent as the Assist pipeline agent you intend to use.
6. Add a short instruction prompt that constrains behavior instead of trying to narrate your whole house.
7. Audit exposed entities before testing commands that affect locks, climate, alarms, doors, scenes, or scripts.
8. Only after command behavior is predictable, add TTS to the pipeline.
9. Set cost and rate-limit guardrails before other household members start using it casually.

Create the API key and add the integration

Start in Google AI Studio and create an API key for the Gemini API. Then go to Home Assistant, add the Google Gemini integration, and paste the key when prompted. Home Assistant’s integration page is the right source for the current UI path because the integration handles the conversation agent, STT, and TTS pieces inside Home Assistant rather than inside a separate smart-speaker ecosystem.[3]

If you are using the Gemini API free tier, do not treat it like a private lab. Home Assistant’s documentation warns that the free tier is rate-limited and that prompts may be used for product improvement.[3] For testing a few harmless commands, that may be fine. For a household assistant that sees device names, room names, routines, and your phrasing patterns, I would plan on a paid API key before making it a daily driver.

Verify the model in your installed Home Assistant release

This is the checkpoint that keeps the recipe honest. The model ID you want is gemini-3.7-flash, but Home Assistant’s public integration documentation describes “Recommended model settings” without enumerating every selectable model in the UI.[3] So the verification source is not a blog post, and it is not this article after your next Home Assistant update. It is your installed Home Assistant release.

Open the Google Gemini conversation-agent options and inspect the model selector. If gemini-3.7-flash appears, select it. If the field accepts a manual model name, enter gemini-3.7-flash exactly and save. Then issue a harmless test command such as asking for the current state of a light that is already exposed to Assist.

If the UI rejects the model or silently falls back to another model, stop and use the newest model your installed integration actually supports. Do not select an unlabeled “latest” option and call the recipe verified. The whole point of using gemini-3.7-flash is that the model ID, pricing window, and context limits can be checked against dated Google documentation.[1][2]

Use a restrained instruction prompt

The instruction prompt should make Gemini a predictable Home Assistant agent, not a chatty house narrator. Keep it short enough that every request does not pay to resend a manual you could have enforced with entity exposure.

You are the Home Assistant conversation agent for this home.

Control only entities that Home Assistant exposes to Assist.
Do not invent entity IDs, room names, device names, automations, or scripts.
If a request is ambiguous, ask one short clarification before acting.
For locks, doors, garage doors, alarm modes, and major climate changes, ask for confirmation before changing state.
Prefer simple, direct responses after an action.
If Home Assistant does not expose an entity or service, say that you cannot control it from this assistant.

That prompt does not replace the entity audit below. It is a seat belt, not a firewall. If a dangerous script is exposed with a friendly alias, the better fix is to unexpose the script, not to hope the language model remains cautious forever.

Audit exposed entities before you test real control

Gemini does not get supernatural access to your house. In this setup, it works through Home Assistant Assist, and Home Assistant’s voice-assistant settings control which entities are exposed.[3] This is the most important safety boundary in the whole recipe.

Go to the Home Assistant voice-assistant exposure screen and review it like you are handing a remote control to someone who hears imperfectly, occasionally guesses, and is very confident when the room name sounds familiar. The goal is not to expose everything and make the prompt smarter. The goal is to expose only the things a household member can safely ask for in normal language.

Scripts deserve extra suspicion because the entity name often hides the blast radius. A hypothetical script.goodnight might turn off lights, lower blinds, lock doors, arm an alarm, and change the thermostat. That can be useful. It is also too much power to expose casually until you have tested the exact spoken phrases people in the house are likely to use.

Aliases are part of the audit. If the kitchen pendant lights, kitchen work lights, and kitchen scene controller all answer to “kitchen lights,” the assistant may do the wrong reasonable thing. Rename or alias exposed entities so a short command maps cleanly to one intended device group.

I also keep a small “never expose” scratchpad for entities that look harmless in the UI but should not be available to a conversation agent: reset helpers, guest-mode toggles, sleep-mode scripts, vacation automations, alarm bypasses, and anything that changes access to the home. The exact list will be different in every installation, which is why copying someone else’s entity exposure screenshot is a bad shortcut.

Test with low-consequence commands first

• Ask for the state of one exposed light.
• Turn on one lamp in the same room as your test microphone.
• Try a room-level command where the entity names are unambiguous.
• Ask for a media-player volume change with a small adjustment.
• Try one climate query before allowing climate changes.

Only after those commands behave predictably would I test scenes, scripts, or anything involving a lock, door, alarm, or climate mode. If one command surprises you, fix exposure and naming before adding more capabilities.

Keep Google Search out of the control agent

Home Assistant documents a real conflict here: using the Google Search tool with the Gemini conversation agent conflicts with Assist control and can produce a 400 INVALID_ARGUMENT error. The documented workaround is to use a second Gemini conversation agent when you want Search, instead of enabling Search on the same agent that controls devices.[3]

That split is clean operationally: one agent controls the house with Search off, and another agent answers web-backed questions. The control agent should have fewer tools, fewer exposed entities, and less room to improvise.

Add TTS after control behavior is boring

The Google Gemini integration can provide TTS as well as the conversation agent and STT.[3] Wire it into your Assist pipeline only after text-based or low-risk voice control is behaving correctly. A better voice does not make entity exposure safer; it just makes mistakes sound more polished.

1. Confirm the Gemini agent can answer and control exposed low-risk entities.
2. Add TTS to the same Assist pipeline or to the speaker path you intend to use.
3. Test short confirmations first: “done,” “the kitchen light is on,” and “I need a confirmation.”
4. Avoid long spoken explanations for routine actions; they add latency, noise, and output tokens.

Cost and rate guardrails before January 1, 2027

The attractive part of Gemini 3.7 Flash in 2026 is the price/performance story. Google’s launch post, Apidog, and Layer3 all report the same introductory API pricing: $0.75 per 1 million input tokens and $3.75 per 1 million output tokens, with standard pricing of $1.50 input and $7.50 output per 1 million tokens from January 1, 2027.[1][5][6]

Separate input from output when you budget. Input tokens are your system prompt, conversation history, exposed-state context, and user request. Output tokens are the model’s response. A setup that replies with long explanations after every light command can become output-heavy for no practical gain.

The huge context window is where people get sloppy. Yes, Gemini 3.7 Flash supports 1,048,576 input tokens and 65,536 output tokens.[2] No, a smart home should not send everything it knows on every turn just because the model can accept it. Keep the instruction prompt short, expose fewer entities, and prefer Home Assistant’s actual state and service calls over a giant prose inventory.

Rate limits are not just developer trivia. Google’s Gemini API rate-limit documentation describes spend-based limits of $10, $50, and $200 per rolling 10 minutes for Tiers 1 through 3, and requests that exceed limits return 429 RESOURCE_EXHAUSTED. The same documentation lists a separate Tier 1 batch limit of 3,000,000 enqueued tokens per batch job.[7]

In a house, a 429 RESOURCE_EXHAUSTED failure does not feel like an API-policy event. It feels like someone asked for the lights and the assistant stalled. If the household will depend on voice control, keep a non-LLM fallback path for basic actions: wall switches, dashboards, physical remotes, and simple Home Assistant automations that do not call the model.

Troubleshooting the first bad command

• Model is missing: confirm your installed Home Assistant release accepts gemini-3.7-flash. If not, do not pretend another option is the same model.
• Device control fails with 400 INVALID_ARGUMENT: check whether Google Search is enabled on the same Gemini agent used for Assist control.[3]
• Assistant controls the wrong thing: inspect exposed entities, aliases, areas, and similarly named scripts before changing the prompt.
• Assistant is too verbose: shorten the instruction prompt and ask for brief confirmations.
• Random failures under heavier use: check API rate limits and look for 429 RESOURCE_EXHAUSTED responses.[7]
• Cost rises faster than expected: inspect input context, conversation history, and output length separately.

Should you run Gemini 3.7 Flash as your Home Assistant agent?

Yes, with containment. Gemini 3.7 Flash is the strongest low-cost Home Assistant conversation-agent choice I would pick right now, after you audit exposed entities and budget tokens. The exact model ID is verifiable, the context window is generous, and the introductory API price is unusually good for this class of model.

The recommendation stops where the safety boundary starts: verify gemini-3.7-flash in your installed Home Assistant build, keep sensitive entities unexposed, leave Google Search out of the control agent, wire TTS only after control is predictable, and price your expected usage at the January 1, 2027 standard rates before you make it the default voice path for the house.

References

1. Introducing Gemini 3.7 Flash, Google, August 13, 2026.
2. Gemini 3.7 Flash, Google AI for Developers, 2026-08-13.
3. Google Generative AI Conversation, Home Assistant.
4. Gemini 3.7 Flash, Google DeepMind.
5. What's New in Gemini 3.7 Flash?, Apidog.
6. How to Use Gemini 3.7 Flash, Layer3.
7. Rate limits, Google AI for Developers.