refactor: route openai to responses #1303
Conversation
📝 WalkthroughWalkthroughAdds a migration to convert legacy OpenAI provider apiType values, updates DEFAULT_PROVIDERS entries to use "openai-completions", remaps provider instantiation so "openai" uses Responses provider and "openai-completions" uses a completions-compatible provider, and surfaces UI/locale notices and endpoint-suffix logic for these variants. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Renderer as Renderer UI
participant Config as ConfigPresenter
participant Manager as ProviderInstanceManager
participant ProviderResponses as OpenAIResponsesProvider
participant ProviderCompletions as OpenAICompatibleProvider
participant ExternalAPI as OpenAI/3rd-party API
User->>Renderer: Configure/select provider
Renderer->>Config: Load config (triggers migrations)
Config->>Config: migrateConfigData updates apiType -> "openai-completions" when needed
Renderer->>Manager: Request provider instance (id / apiType)
Manager->>Manager: Map id/apiType -> implementation
alt provider id == "openai"
Manager->>ProviderResponses: instantiate Responses provider
ProviderResponses->>ExternalAPI: call Responses API
else provider apiType == "openai-completions"
Manager->>ProviderCompletions: instantiate Completions-compatible provider
ProviderCompletions->>ExternalAPI: call Chat Completions endpoint
end
ExternalAPI-->>Provider*: Response
Provider*-->>Renderer: Deliver model output
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
No actionable comments were generated in the recent review. 🎉 Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Fix all issues with AI agents
In `@src/renderer/src/i18n/da-DK/settings.json`:
- Line 305: Translate the value of the openaiResponsesNotice key into Danish,
keeping the technical terms "OpenAI", "Responses API", and "Chat Completions"
unchanged; e.g., replace the English sentence with a Danish localization such as
"OpenAI bruger som standard Responses API. Hvis en tredjeparts-endpoint kun
understøtter Chat Completions, brug OpenAI Completions provider." Ensure the key
name openaiResponsesNotice remains identical.
In `@src/renderer/src/i18n/en-US/settings.json`:
- Line 317: The i18n key openaiResponsesNotice uses camelCase instead of the
required lowercase dot-separated hierarchy; rename the key to
provider.openai.responses.notice in src/renderer/src/i18n/en-US/settings.json,
update all code references that read openaiResponsesNotice to use
provider.openai.responses.notice (eg. any getString/getTranslation or useI18n
lookups), and mirror the same key change across all locale files so translations
remain in sync.
In `@src/renderer/src/i18n/fr-FR/settings.json`:
- Around line 317-318: The translation key openaiResponsesNotice in fr-FR
settings.json is still English and uses camelCase; change its key to a lowercase
dot-separated name (e.g., settings.openai.responsesNotice or
common.openai.responses_notice depending on your key hierarchy) and replace the
English value with the correct French translation, then update all usages of
openaiResponsesNotice across the codebase/locales to the new key name (also
ensure modelList key remains consistent if related); adjust other locale files
to use the same new key to keep keys consistent across translations.
In `@src/renderer/src/i18n/he-IL/settings.json`:
- Line 317: Translate the value for the JSON key "openaiResponsesNotice" into
Hebrew, preserving the technical terms exactly as-is in English: OpenAI,
Responses API, Chat Completions, and OpenAI Completions; replace the current
English sentence with a concise Hebrew sentence that conveys the same meaning
and keep the JSON string formatting intact.
In `@src/renderer/src/i18n/ko-KR/settings.json`:
- Line 438: The string value for the key openaiResponsesNotice is still in
English; replace it with a proper Korean localized sentence while keeping
technical terms unchanged (e.g., "OpenAI", "Responses API", "Chat Completions",
"OpenAI Completions provider"); update the value so it reads naturally in Korean
(for example: "OpenAI는 기본적으로 Responses API를 사용합니다. 서드파티 엔드포인트가 Chat Completions만
지원하는 경우 OpenAI Completions provider를 사용하세요.") and ensure punctuation and spacing
match the surrounding locale entries.
In `@src/renderer/src/i18n/ru-RU/settings.json`:
- Line 438: Replace the English value for the JSON key openaiResponsesNotice
with a Russian translation while leaving technical names unchanged: set it to a
natural Russian sentence such as: По умолчанию OpenAI использует Responses API.
Если сторонний эндпоинт поддерживает только Chat Completions, используйте
провайдер OpenAI Completions; ensure "OpenAI", "Responses API", "Chat
Completions" and "OpenAI Completions" remain in English exactly as shown.
🧹 Nitpick comments (6)
src/renderer/src/i18n/fa-IR/settings.json (1)
317-317: Consider localizing the OpenAI notice for fa-IRThis string is still English; translating it would keep the Persian UI consistent.
src/renderer/src/i18n/pt-BR/settings.json (1)
317-317: Consider localizing the OpenAI notice for pt-BRThis string is still English; translating it would keep the Portuguese UI consistent.
src/renderer/src/i18n/ja-JP/settings.json (1)
317-317: Consider localizing the OpenAI notice for ja-JPThis string is still English; translating it would keep the Japanese UI consistent.
src/renderer/settings/components/ProviderApiConfig.vue (1)
3-13: Dark mode styling concern for the notice banner.The hardcoded
bg-amber-50 text-amber-900 border-amber-300classes are light-mode-only. In dark mode,bg-amber-50will appear as a bright white-ish block against a dark background, andtext-amber-900may have poor contrast. Consider adding dark-mode variants:- class="w-full rounded-md border border-amber-300 bg-amber-50 px-3 py-2 text-amber-900" + class="w-full rounded-md border border-amber-300 bg-amber-50 px-3 py-2 text-amber-900 dark:border-amber-600 dark:bg-amber-950 dark:text-amber-200"src/renderer/src/components/settings/ModelConfigDialog.vue (1)
522-533:isResponsesProvidermay have a timing gap whenproviderStorehasn't loaded yet.If
providerStore.providersis empty when the dialog first opens (e.g., store not yet hydrated),currentProviderwill beundefined, and theapiTypebranch on line 527-528 will not match. TheproviderIdLowercheck on line 523 would still catch'openai'and'openai-responses'by ID, but any custom provider whoseapiTypeis'openai'but whoseidis something else would be missed until the store loads.This is likely an edge case since the dialog is typically opened after the app is fully loaded, but worth noting.
src/renderer/settings/components/AddCustomProviderDialog.vue (1)
72-74: Endpoint hint may look odd whenbaseUrlis empty.When
formData.baseUrlis empty and the user selectsopenaioropenai-completions, the hint will display just/responsesor/chat/completionswithout a base URL prefix. Consider hiding the hint whenbaseUrlis also empty:- <div v-if="apiEndpointSuffix" class="text-xs text-muted-foreground mt-1"> + <div v-if="apiEndpointSuffix && formData.baseUrl" class="text-xs text-muted-foreground mt-1">
| "getKeyTipEnd": "to get API Key", | ||
| "urlFormat": "API Example: {defaultUrl}", | ||
| "urlFormatFill": "Fill into API URL", | ||
| "openaiResponsesNotice": "OpenAI defaults to the Responses API. If a third-party endpoint only supports Chat Completions, use the OpenAI Completions provider.", |
There was a problem hiding this comment.
New i18n key doesn’t follow lowercase dot-separated naming.
The key openaiResponsesNotice introduces camelCase. Consider nesting as provider.openai.responses.notice and update references + other locales accordingly.
♻️ Suggested key structure (en-US example)
- "openaiResponsesNotice": "OpenAI defaults to the Responses API. If a third-party endpoint only supports Chat Completions, use the OpenAI Completions provider.",
+ "openai": {
+ "responses": {
+ "notice": "OpenAI defaults to the Responses API. If a third-party endpoint only supports Chat Completions, use the OpenAI Completions provider."
+ }
+ },As per coding guidelines: Use dot-separated hierarchical structure for translation key naming with lowercase letters and descriptive names grouped by feature/context (e.g., common.button.submit, chat.send.placeholder).
🤖 Prompt for AI Agents
In `@src/renderer/src/i18n/en-US/settings.json` at line 317, The i18n key
openaiResponsesNotice uses camelCase instead of the required lowercase
dot-separated hierarchy; rename the key to provider.openai.responses.notice in
src/renderer/src/i18n/en-US/settings.json, update all code references that read
openaiResponsesNotice to use provider.openai.responses.notice (eg. any
getString/getTranslation or useI18n lookups), and mirror the same key change
across all locale files so translations remain in sync.
| "openaiResponsesNotice": "OpenAI defaults to the Responses API. If a third-party endpoint only supports Chat Completions, use the OpenAI Completions provider.", | ||
| "modelList": "Liste des modèles", |
There was a problem hiding this comment.
Localize the notice and align key naming with i18n conventions
The value is still English in fr-FR, so the UI won’t be fully localized. Also, openaiResponsesNotice is camelCase while the i18n naming rule prefers lowercase dot-separated keys—consider renaming the key (and updating usages across locales) to align with the convention.
As per coding guidelines: "Use dot-separated hierarchical structure for translation key naming with lowercase letters and descriptive names grouped by feature/context (e.g., common.button.submit, chat.send.placeholder)".
🤖 Prompt for AI Agents
In `@src/renderer/src/i18n/fr-FR/settings.json` around lines 317 - 318, The
translation key openaiResponsesNotice in fr-FR settings.json is still English
and uses camelCase; change its key to a lowercase dot-separated name (e.g.,
settings.openai.responsesNotice or common.openai.responses_notice depending on
your key hierarchy) and replace the English value with the correct French
translation, then update all usages of openaiResponsesNotice across the
codebase/locales to the new key name (also ensure modelList key remains
consistent if related); adjust other locale files to use the same new key to
keep keys consistent across translations.
* Merge pull request #1302 from ThinkInAIXYZ/bugfix/question-end-error fix(agent): mark question tool messages sent * refactor: route openai to responses (#1303) * refactor: route openai to responses * fix(i18n): localize openaiResponsesNotice * feat: add hooks for notify (#1304) * docs(hooks): add hooks notifications spec/plan * docs(hooks): adjust settings UX and notifier triggers * docs(hooks): define webhook notifications and lifecycle hooks * feat(hooks): add confirmo notifications * feat(hooks): improve notifications cards * chore(i18n): add notifications hooks translations * fix(hooks): correct env var prefix * fix(hooks): align hook dispatch * fix(settings): improve hooks ui * fix(hooks): harden hook dispatch * chore: update 0.5.8 --------- Co-authored-by: yyhhyyyyyy <yyhhyyyyyy8@gmail.com>
2 participants
This PR migrates OpenAI provider routing to the Responses API, introduces explicit openai-completions semantics for third-party OpenAI-compatible endpoints with version-gated config migration (<0.5.8), and updates settings UI/i18n (including a top banner notice and API endpoint visibility rules) to match the new behavior.
Summary by CodeRabbit
New Features
Documentation