Repository navigation
Conversation
Require explicit API selection when multiple routes answer: route availability does not establish model compatibility.
jacisko
force-pushed
the
feat/openai-responses-custom-provider
branch
from
October 30, 2026 20:41
478a768 to
2a0def1
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Custom endpoints currently have no way to select OpenAI Responses. Models that require it are configured as Chat Completions instead.
This adds
openai-responsesto the API flavor selector, IPC validation, settings persistence, and generated pi configuration. OpenAI endpoints retain their/v1prefix; Responses uses pi's native protocol defaults rather than Chat Completions compatibility overrides.Auto-detection probes the Responses route too. Multiple detected routes now require an explicit API selection instead of silently choosing Chat Completions. Single-route detection and the existing no-route fallback are preserved. Ollama and LM Studio remain on Chat Completions. Existing saved configurations are not migrated automatically.
The UI explains that Test connection checks model listing, not inference compatibility.
Verification
npm test -- tests/unit/responses-integration.test.ts tests/unit/models-config.test.ts tests/unit/settings.test.ts: 139 passed.npm run typecheckandnpm run lint: passed.40d6d4afails because pi posts to/openai/v1/chat/completions; with this patch it passes using/openai/v1/responses.Validation limits
Latest full-suite run: 3,828 passed, 2 failed, 4 skipped. The scheduler test at tests/unit/scheduler.test.ts:449 expects
okbut seesrunning; the same failure reproduced on unchanged main with the same dependencies. A past-chat rendering test timed out at five seconds and passed on a focused rerun. Full-suite green is not claimed.Tests ran locally on macOS with Node 26.9.0 and pi 1.1.0, using the existing installed dependency tree rather than a fresh
npm ci. No dependency or lockfile changes are included. The mock verifies generated-config-to-pi protocol wiring, not compatibility with a live Responses endpoint or the full Stem UI/runtime path.