[Feature] Expose openai-responses as an API type in custom server settings #1266

Problem

ThinkRail’s custom server configuration currently supports only the OpenAI Chat Completions API (api: "openai-completions"). Users cannot select the OpenAI Responses API (/v1/responses) when adding a custom OpenAI-compatible server through the GUI.

There is also a second limitation: models configured manually through pi’s models.json file do not support image inputs. Even if a user works around the GUI restriction by editing models.json directly, a custom model that supports vision/multimodal input still cannot be used with images in ThinkRail.

As a result, custom OpenAI-compatible endpoints that expose the Responses API and/or image input capabilities cannot be used to their full extent.

Motivation

OpenAI positions the Responses API as the recommended API for agentic applications, with benefits such as preserved reasoning state, better tool usage, and improved cache utilization. More OpenAI-compatible gateways and self-hosted proxies now expose /v1/responses, so users reasonably expect the same “Add server” flow to support this API shape.

Image input is also increasingly important for coding agents — for example, screenshots, UI mockups, diagrams, and error images. A coding-agent IDE should allow custom vision-capable models to receive images, not just text.

Proposed Solution

Expose api as a selectable field in the Add server dialog, with at least:

openai-completions (keep as default for backward compatibility)

openai-responses

When openai-responses is selected, the server entry written to models.json should use api: "openai-responses" instead of the current hard-coded value.

Support image inputs for models configured through pi models.json. A custom model entry should be able to declare image/vision capability, and ThinkRail should pass image content to the selected API in the expected format — including input_image content parts for the Responses API.

The existing model discovery, API key handling, and limit probing flow can remain unchanged.

Alternatives Considered

Manually editing models.json: This can work around the API-type limitation, but it is error-prone and still does not solve the missing image-input support.

Adding a separate “Responses” preset: This is less flexible than a generic API-type selector and may not cover all OpenAI-compatible gateways.