Add OpenAI Responses API tools support for Home Assistant

[sheepdestroyer]

Summary

Add the OpenAI Responses API capabilities required by Home Assistant's openai_conversation integration when LiteLLM is used as the OpenAI-compatible endpoint.

Home Assistant is configured with:

• Base URL: https://litellm.x570.vendeuvre.lan/v1
• Model: local-qwen-3.6-hass
• Home Assistant version: 2026.7.4
• Integration: official Home Assistant OpenAI integration

Normal conversation/tool calls can use the existing LLM route, but enabling additional AI services in Home Assistant currently fails with Unknown error occurred.

Reproduction

1. In Home Assistant, open the OpenAI integration options.
2. Configure an AI Task model routed through LiteLLM.
3. Enable one or more of:
   • Code interpreter
   • Web search
   • Include home location
4. Submit the configuration.

Current error

Home Assistant calls the Responses API during configuration, using gpt-4o-mini to resolve the home location. LiteLLM returns:

HTTP 400
/responses: Invalid model name passed in model=gpt-4o-mini.
Call `/v1/models` to view available models for your key.

The failure occurs in Home Assistant's openai_conversation/config_flow.py while calling:

client.responses.create(...)

The existing LiteLLM endpoint also needs compatible handling of Responses API tools, not only Chat Completions-compatible requests.

Requested work

Implement and expose the Responses API functionality needed by Home Assistant, while preserving existing routing behavior and avoiding any implicit change of model backends:

• Responses API endpoint compatibility.
• Model discovery through /v1/models for the models intended for HA.
• Code interpreter tool support, including the expected request/response event format.
• Web search tool support, or a clear capability/error response if the selected backend cannot provide it.
• Home-location lookup request compatibility, including accepting the model selected by Home Assistant or documenting the required model alias/configuration.
• Tool/function calling for Home Assistant Assist actions without breaking the existing Chat Completions API.
• Correct propagation of tool calls, tool outputs, streaming events, usage, errors, and response IDs.
• Authentication and model alias behavior consistent between /v1/chat/completions and /v1/responses.

Acceptance criteria

• GET /v1/models lists the model aliases usable by Home Assistant.
• A minimal POST /v1/responses request succeeds through the public LiteLLM endpoint.
• A Responses API request containing Home Assistant-style tools can be executed and returns valid tool calls.
• Code interpreter configuration no longer fails with an unsupported-endpoint or invalid-model error when routed to a compatible backend.
• Web search either works with a supported backend or returns a documented, actionable capability error.
• Home Assistant can save the AI Task/OpenAI integration configuration with the required options enabled.
• Existing /v1/chat/completions behavior and current production model routing remain unchanged.
• Add automated tests for model aliases, Responses API requests, tool calls, streaming/non-streaming behavior, and unsupported-tool errors.
• Document backend requirements and any model aliases/configuration needed for Home Assistant.

Constraints

• Do not change existing model backends or fallback policy as part of this issue unless explicitly configured for the new HA capability.
• Keep production and development configuration separate.
• Validate against the dev deployment before production rollout.

[github-actions]

The request proposes adding support for the OpenAI Responses API to the LiteLLM endpoint used by Home Assistant’s openai_conversation integration. This would allow tools like the code interpreter and web search to function within Home Assistant when configured through LiteLLM. The issue outlines the current errors encountered, details required functionality (e.g., model discovery, tool support, response formatting), and lists acceptance criteria to ensure compatibility with Home Assistant while preserving existing functionality and routing behavior.