How to Use GLM-5.3 as Your Smart Home Assistant
GLM-5.3 can power Home Assistant's Assist agent today, but the stock OpenAI integration is a dead end. Compare the working access paths, then follow dated, status-labeled setup steps to wire GLM-5.3 into Home Assistant.
Q3 2026 status: GLM-5.3 can be used as a smart home assistant with Home Assistant’s Assist pipeline through OpenAI-compatible cloud routes, but not through Home Assistant’s stock OpenAI conversation integration. The failure point is the API endpoint, not the model name. If the integration refuses third-party OpenAI-compatible backends, changing the prompt, pasting a different model string, or regenerating a valid API key will not make that route work.
GLM-5.3 is Z.ai’s open-weights model released on 2026-08-14, so it is new enough that most of the Home Assistant trail is still thin, and older GLM-4.7 community notes should not be treated as a verified GLM-5.3 recipe. The useful question is narrower than the model launch coverage: can Home Assistant Assist call it cleanly, and through which integration path? [1]
Pick the access path before you paste any keys
In Home Assistant terms, Assist is the user-facing assistant interface: the thing you talk to by voice or text. The conversation agent is the backend selected to interpret that request and, when configured, use Home Assistant context to answer or act on exposed smart-home entities. For a GLM-5.3 smart home assistant integration, the conversation agent is where the routing decision matters.
| Access path | Q3 2026 status | Use it for GLM-5.3 Assist? |
|---|---|---|
| Home Assistant stock OpenAI conversation integration | Dead end for third-party OpenAI-compatible services. Home Assistant documents that it works only with the official OpenAI API endpoint and does not support OpenAI-API-compatible third-party services, proxies, or alternative backends. | No. Do not start here for GLM-5.3 unless the backend is the official OpenAI API, which GLM-5.3 is not. |
| OpenRouter | Home Assistant points to OpenRouter as the alternative path for OpenAI-compatible model access. | Yes, this is the cleanest Home Assistant-pointed route to try first, assuming GLM-5.3 is available in the OpenRouter model selector for your account. |
| Z.ai direct API | Not verified here as a working Home Assistant Assist path through the stock OpenAI conversation integration. | Only if you are using an integration or bridge that explicitly lets Home Assistant call that endpoint. A direct Z.ai key in the stock OpenAI integration is the wrong test. |
| Z.ai Coding Plan or coding-agent route | Relevant to coding-agent access, not established here as a Home Assistant Assist conversation-agent route. | No, not as the primary smart-home assistant setup path. |
| Local or self-hosted GLM-5.3 | Possible in principle because GLM-5.3 is open-weights, but no verified Home Assistant Assist path is established by the provided materials. | Treat as experimental unless your inference server and Home Assistant integration explicitly agree on the endpoint protocol. |
The first row is the one that saves an evening. Home Assistant’s own OpenAI conversation documentation says the integration “works only with the official OpenAI API endpoint” and does not support OpenAI-API-compatible third-party services, proxies, or alternative backends; the same documentation points users toward OpenRouter instead. [2]
Why the stock OpenAI integration is the wrong GLM-5.3 test
A lot of failed Home Assistant LLM setups look deceptively close to working: the API key validates somewhere else, the model name exists in a provider dashboard, and the provider says it is OpenAI-compatible. That still does not mean Home Assistant’s stock OpenAI conversation integration will call it.
“OpenAI-compatible” usually describes the shape of an API: chat completions style requests, familiar message arrays, similar authentication patterns, and model identifiers passed in the request. Home Assistant’s stock OpenAI conversation integration is narrower. Its documented boundary is the official OpenAI API endpoint, so an otherwise valid third-party endpoint is outside the contract. [2]
That is why this setup should not begin with “add OpenAI, paste key, type GLM-5.3.” If the endpoint is rejected by design, the rest of the configuration is noise. The access path has to be one Home Assistant can actually talk to.
Working route to try first: GLM-5.3 through OpenRouter
Use this path if you want the least exotic Home Assistant setup: OpenRouter account, GLM-5.3 selected there if available to your account, then Home Assistant’s OpenRouter conversation-agent path feeding Assist. This is the route Home Assistant points users toward when they need third-party OpenAI-compatible model access rather than the official OpenAI endpoint. [2]
| Stage | What you are proving | Stop if... |
|---|---|---|
| 1. Confirm model access in OpenRouter | Your OpenRouter account can see and call GLM-5.3. | GLM-5.3 is not listed or is unavailable for your account. |
| 2. Create or copy the OpenRouter API key | You have credentials for the route Home Assistant will use. | You only have a Z.ai direct key and no OpenRouter key. |
| 3. Add the OpenRouter integration in Home Assistant | Home Assistant is using the supported third-party route, not the stock OpenAI endpoint path. | You find yourself in the stock OpenAI conversation integration. |
| 4. Select GLM-5.3 as the model for the conversation agent | Assist will send conversation requests through the configured OpenRouter-backed agent. | The model selector does not expose GLM-5.3. |
| 5. Assign the agent to the Assist pipeline | Your voice or text assistant is actually using the GLM-5.3-backed agent. | Assist is still assigned to another conversation agent. |
1. Confirm GLM-5.3 on the provider side
Before touching Home Assistant, sign in to OpenRouter and check whether GLM-5.3 is available to your account. This is a boring check, but it separates an integration problem from a provider-access problem. If the model is not available in OpenRouter, Home Assistant cannot select it through that route.
Do not substitute an older GLM model unless that is an intentional test. Older GLM-4.7 community material may still be useful for understanding the family of models, but it does not verify that GLM-5.3 is selectable, callable, or stable in your Home Assistant Assist setup.
2. Create an OpenRouter key for Home Assistant
Create or copy an OpenRouter API key and label it for Home Assistant if the provider dashboard lets you name keys. The label matters later when something starts making requests at midnight and you need to know whether it was a phone app test, a browser playground, or the kitchen speaker.
At this point, the key should be from OpenRouter, not a Z.ai direct account, and not an OpenAI account. Mixing those up is one of the fastest ways to create a failure that looks like an authentication problem but is really a route mismatch.
3. Add the OpenRouter conversation route in Home Assistant
In Home Assistant, go to the integrations area and add the OpenRouter integration or conversation-agent route exposed by your Home Assistant version. When prompted, paste the OpenRouter key and complete the provider setup. The exact screens can move between releases, but the important checkpoint is simple: the configured provider should say OpenRouter, not OpenAI Conversation.
If you are staring at a form that only represents the official OpenAI conversation integration, back out. That form is useful for the official OpenAI API endpoint. It is not the GLM-5.3 route described here. [2]
4. Select GLM-5.3 as the conversation model
Choose GLM-5.3 from the model selector if OpenRouter exposes it. Avoid hand-typing a guessed model slug unless the provider documentation or UI gives you the exact value. A one-character model-name mismatch can masquerade as a Home Assistant problem, and it is not worth debugging from the wrong end.
Keep the initial system instructions plain. For the first pass, the goal is not to build the perfect household personality; it is to confirm that Assist can send a request to the GLM-5.3-backed agent and receive a response through the selected route.
5. Assign the GLM-5.3-backed agent to Assist
After the provider and model are configured, assign that conversation agent to the Assist pipeline you actually use. This is the small checkbox-style mistake that can make a working model look broken: Home Assistant may have the new agent configured, while your active Assist pipeline is still using a previous GPT, Gemini, Claude, local Ollama, or default agent.
- Open the Assist or voice assistant pipeline settings you normally use.
- Select the OpenRouter-backed conversation agent configured with GLM-5.3.
- Save the pipeline.
- Run the first test from text Assist before involving wake words, satellites, speakers, or automations.
Branch notes: Z.ai direct, Coding Plan, and local GLM-5.3
Z.ai direct access is not the same thing as a verified Home Assistant Assist integration. If you have a Z.ai endpoint and key, the stock OpenAI conversation integration is still blocked by Home Assistant’s documented endpoint restriction. A direct route would need a Home Assistant integration, add-on, proxy, or bridge that explicitly supports changing the base endpoint and passing requests in a way Home Assistant accepts. That is a separate setup path, not a shortcut through the OpenAI box. [2]
A Coding Plan-related GLM-5.3 path belongs in the coding-agent bucket unless it exposes a usable conversation API path for Home Assistant. It may be relevant for writing automations, reviewing YAML, or helping with templates, but that does not make it the agent answering Assist in the hallway.
Local GLM-5.3 is the tempting tinkerer route because the model is open-weights. The missing piece is not the idea of local inference; it is the verified bridge between your local server and Home Assistant’s conversation-agent system. If your stack uses a local OpenAI-compatible server, remember the same rule: Home Assistant’s stock OpenAI conversation integration is not documented to accept alternative backends. Use an integration that explicitly supports that local endpoint, or treat the setup as experimental. [1][2]
Verification checks inside Assist
Start with a non-destructive text prompt in Assist. Ask something that proves the agent is alive but does not touch devices, such as a simple household-status question if your agent has Home Assistant context enabled, or a general test prompt if you have not exposed entities yet. The first pass should answer one question: did Assist get a response from the configured GLM-5.3 route?
- If Assist responds through the OpenRouter-backed agent, the route is working.
- If Assist responds as a different model, check the active Assist pipeline assignment.
- If authentication fails, confirm the key belongs to OpenRouter and has access to the selected model.
- If the model is unavailable, confirm GLM-5.3 is visible in OpenRouter for your account.
- If you configured the stock OpenAI conversation integration, stop there; that remains the wrong path for third-party OpenAI-compatible endpoints.
Only after the text path works should you test voice, exposed entities, and device control. That keeps wake-word handling, microphones, speakers, permissions, and entity exposure out of the first failure domain.
Current dated status: GLM-5.3 is usable as a Home Assistant smart home assistant through a compatible cloud route such as OpenRouter, with Assist assigned to that conversation agent. The stock OpenAI conversation integration remains the dead end for third-party OpenAI-compatible endpoints.
References
- GLM-5.3 release announcement, Z.ai, 2026-08-14, Z.ai
- OpenAI Conversation, Home Assistant, home-assistant.io