Switching service type away from OpenAI silently carries useResponsesAPI=true into OpenAI Compatible

[mattezell]

Summary

Switching a service's type away from "OpenAI" silently carries useResponsesAPI: true along, so an "OpenAI Compatible" service keeps routing through /v1/responses after the operator explicitly switched types to escape it.

The server code documents defending against exactly this ("a stale flag carried over from a previous service type must not be allowed to route the request through Responses", llm/configuration.go above ServiceUsesResponsesAPI) -- but the defense exempts the two types that honor the flag (openaicompatible, azure), and the UI is the source of the staleness: webapp/src/components/system_console/service.tsx force-enables the flag when type is openai (useEffect, ~L129) and the type-change handler keeps the previous value for every other type (useResponsesAPI: nextType === 'openai' ? true : props.service.useResponsesAPI, ~L250).

Steps to reproduce

1. Create a service with type "OpenAI" (flag force-set true), pointed at any OpenAI-compatible server without /v1/responses support (e.g. llama.cpp).
2. Requests fail; operator switches type to "OpenAI Compatible" (the documented escape) and saves. The "Use Responses API" radio still shows true (carried), which is easy to miss since the operator never set it.
3. Requests still go to /v1/responses (observed directly in the backend server's request log).

Expected

Switching away from "OpenAI" resets useResponsesAPI to false (or at minimum the UI visibly surfaces that the flag is on and why).

Proposed fix

One line in the type-change handler: useResponsesAPI: nextType === 'openai' -- switching away resets, switching to openai force-enables as today. Happy to PR.

Env: plugin 2.4.2 (code unchanged on current master), server 11.9.0, self-hosted llama.cpp backend.

🤖 Generated with Claude Code

https://claude.ai/code/session_016e12GP7EHU2KeCGGYcfvBo