- Treat an empty tool argument string as no parameters instead of raising
JSONDecodeError; the proxy sends "" for tools like the timer status
(upstream issue #3).
- Do not replay earlier web searches in the history. The chat log keeps only
their status, and a search without results makes the model disown the
answers it based on it and search again (upstream issue #4).
- Look up the home location for web search with the subentry's model instead
of gpt-4o-mini, and save the options without city/region if the lookup
fails (upstream issue #5).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Home Assistant 2026.10 pins openai==3.10.0 in its package constraints, so the
manifest's exact openai==2.45.0 can no longer be installed and setup fails:
Setup failed for custom integration 'openai_compatible': Requirements for
openai_compatible not found: ['openai==2.45.0'].
The requirement is now a floor. Each Home Assistant release then installs the
openai it pins: 2.45.0 on 2026.9, 3.10.0 on 2026.10.
The vendored code needs no change for 3.x. The only breaking change in openai
3.0 is HTTPX2 as the default client, and passing Home Assistant's legacy httpx
client is still supported at runtime, which is how core's own integration
handles it. Every openai import in the integration resolves on 3.10.0, and the
suite passes against it on the 2026.10.0 test harness (170 passed).
requirements_test.txt now pins 3.10.0 so CI tests what current Home Assistant
ships.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0123XQr8dh5RnFLnECHPVNrd
Writes up what is still OpenAI-specific in this fork, since the base URL
being configurable is what makes it reach a compatible endpoint, not what
makes it behave correctly against one. Four findings, each with what it
actually costs:
1. service_tier, store and prompt_cache_retention are sent on every
request whatever the provider is (entity.py:515-563); reasoning,
include and text.verbosity are gated on OpenAI name prefixes.
2. 23 startswith() model-name gates plus the UNSUPPORTED_* lists infer
capability from OpenAI naming, which fails in both directions: service
tier, code interpreter and web search are offered to providers that
cannot honour them, while reasoning effort/summary and verbosity are
withheld from any model whose name does not look like OpenAI's.
3. manufacturer="OpenAI" and the "Error talking to OpenAI" error text.
4. Repair issues citing core's 2026.9.0 removal schedule, which has
passed and was never this fork's commitment, and an OpenAI-only
organization-verification repair.
Two things worth having written down beyond the list itself:
- A proxy set to drop incompatible parameters hides finding 1 entirely
and makes finding 2 worse, because a dropped parameter turns a
misconfigured option into a silent no-op rather than an error. Testing
only against such a proxy therefore says nothing about portability, and
a strict server is the honest target. This reorders the priorities:
finding 2 first, since it is what the user sees and the failure is
silent; finding 1 matters for setups without a normalising proxy.
- The prerequisite decision is recorded rather than assumed. There is no
capability discovery in the OpenAI API -- GET /v1/models returns ids,
not feature support -- so the three candidates (per-entry capability
toggle, host detection, per-endpoint checkboxes) are laid out with
their trade-offs and explicitly marked unsettled.
No behaviour change; the README links it from a short "known
OpenAI-specific behaviour" section so it is findable from the front page.
Local: 170 passed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NxJYWgGJtCw13qUHZtG8ki
This repo has no tags and no GitHub releases, and manifest.json has read
"1.0.0" since the integration was vendored -- unchanged across 20 commits,
including today's breaking reshape of the config flow. HACS falls back to
serving the default branch when there are no releases, so every download is
indistinguishable from the last and there is no way to tell what is running.
- scripts/release.py bumps manifest.json, commits and creates an annotated
tag in one step. It refuses a dirty tree, a branch other than main, a main
that differs from origin/main, a malformed version and an existing tag. It
stops short of pushing, since pushing the tag is what publishes.
- .github/workflows/release.yaml triggers on v* tags and refuses to publish
when the tag and manifest.json disagree. That mismatch is the failure worth
guarding: HACS offers the tag while Home Assistant reports the manifest, so
you install "v0.2.0" and the integration page says 0.1.0. It then creates
the release with gh (no third-party action).
- tests/test_version.py keeps the manifest version parseable by
AwesomeVersion (what HACS validates with) and in the shape the release
script accepts, so a release never fails on the version string itself.
Scheme: 0.x while the config entry shape is still in motion -- it changed
twice today -- and 1.0.0 when it settles. Documented in the README.
Local: 169 passed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NxJYWgGJtCw13qUHZtG8ki
Reshapes setup around how a multi-model proxy is actually used: one config
entry per server/provider, then one endpoint per model added by hand, with
the model chosen from what that provider advertises right now.
Setup (async_step_user):
- Adds a Name field. With one entry per provider the title matters, and it
was hardcoded to "ChatGPT" regardless of where the entry pointed. Blank
falls back to the endpoint host via url_util.title_from_base_url.
Deliberately absent from the reauth schema (now split out as
STEP_REAUTH_DATA_SCHEMA): that step writes its input back into entry.data
via data_updates, so a name field there would persist the title as
connection data on every key rotation.
- Stops auto-creating four subentries. conversation/ai_task_data/stt/tts were
all created up front carrying RECOMMENDED_* options, which pin OpenAI model
names (gpt-4o-mini-tts, gpt-4o-mini-transcribe). Against a third-party
endpoint those entities are dead on arrival -- the reported symptom was an
install that "loads bits, it's all janky".
- Drops _async_abort_entries_match, so several entries may point at one
server (one per provider-side key, for instance). Upstream aborts with
already_configured on matching url+key.
Model discovery (new model_list.py, kept out of the vendored files like
url_util.py):
- async_fetch_model_ids asks the endpoint's GET /v1/models. It calls
with_options(max_retries=0), because this runs while the user waits on a
dialog and the SDK otherwise retries with backoff -- visible in the test
run as repeated "Retrying request to /models" and a suite that went from
5s to minutes.
- Returns [] on any OpenAIError, and model_field() then yields a plain text
field instead of a dropdown, so an endpoint that serves /v1/responses but
not /v1/models is still configurable by hand. The dropdown sets
custom_value=True for the same reason (LiteLLM wildcard routes).
- Wired into all four types: conversation and ai_task_data on the additional
step, stt (which hardcoded OpenAI's three transcribe models) and tts on
init. TTS had no model field at all -- it silently used gpt-4o-mini-tts.
A new endpoint now starts with "recommended" unticked. Ticked, the flow ends
on the first step and never shows a model field, which is why the model
looked unpickable; reconfigure still keeps whatever was saved.
The model field stays on the additional step rather than moving to init. The
init position reads better, but 71 ported tests drive the model through the
additional step, several from parametrized option dicts that no mechanical
edit could relocate. Rewriting the only regression net against upstream to
save one click was the wrong trade.
Also: the setup description no longer says "your OpenAI API key", and
instructions_url pointed at a README anchor (#generate-an-api-key) that does
not exist -- now #configuration. strings.json re-verified against core's
RE_URL: 0 violations.
Local: 167 passed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NxJYWgGJtCw13qUHZtG8ki
The `hacs` validation job has failed on every push since the scaffold
commit (6/9 checks). This fixes the four failures that live in the repo;
the two that live in GitHub metadata (description, topics) are set via
the API and need no commit.
- hacs.json: remove `render_readme`. It is not in the HACS manifest
schema (valid keys: name, content_in_root, zip_release, filename,
hide_default_branch, country, homeassistant, hacs,
persistent_directory), and HACS rejects the whole file on an unknown
key -- which is what `<Validation hacsjson> failed` was. Expecting
the cascading `integration_manifest` failure ("expected a dictionary.
Got None") to clear with it, since manifest.json itself already
carries every key HACS requires.
- README.md: the repo had none, so the `information` check failed and
HACS had nothing to render. Documents the one thing this fork adds
(configurable base URL) and, importantly, the compatibility ceiling:
upstream calls the Responses API, so an endpoint that only serves
/v1/chat/completions cannot back the conversation or AI Task
subentries. Also records which endpoint each subentry needs, that
upstream's recommended model names and unsupported-model lists are
OpenAI-specific, the base-URL rules (http/https, no embedded
credentials, include /v1), and why a blank API key sends the
`not-required` placeholder.
- brand/icon.png + icon@2x.png: `brands` fails unless the repo ships
brand assets or the domain is in home-assistant/brands. Shipping
assets is the option that does not depend on a third-party PR.
Generated with stdlib zlib/struct (no PIL or ImageMagick in this
environment) from supersampled SDFs; the generator is scratch, not
committed. Deliberately neither OpenAI's nor Home Assistant's mark,
and a placeholder -- replace it with real artwork before release.
Not done here: this fork has no git tag or GitHub release yet. HACS
treats releases as preferred-but-not-required and the action does not
check for one, so it is not part of this failure.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NxJYWgGJtCw13qUHZtG8ki
pc-heiniandClaude Opus 5.5