fix(chatgpt): honour engine override instead of hardcoding model 'auto'

[sjgold]

Fixes #75

chatgpt-engine.js send() accepts an engine argument and never reads it, so every request posts model: 'auto' no matter what the caller asked for. The override already survives the entire chain (CLI -> rest-api.cjs -> main-v2.cjs -> api.cjs -> injected window.__proximaChatGPT.send); it was just dropped at the final step. Gemini's equivalent selection works, which is what made the gap easy to overlook.

Change

Nine lines. Read engine when it is present, keep auto when it is not.

What is verified

The parameter now reaches the request payload instead of being discarded. Confirmed by tracing the value through to the injected call and into the POST body on Windows 11, v5.0.0, Session (Browser) mode. Behaviour with no override is unchanged.

What is NOT verified

I cannot currently confirm that ChatGPT's backend honours the model field on /backend-api/conversation for browser-session requests.

An earlier revision of this PR claimed verification based on message.metadata.model_slug from the response stream. That method is invalid and I have withdrawn it. model_slug echoes whatever model string was sent, including nonsense:

requested: banana-9000           -> model_slug: banana-9000
requested: not-a-real-model-xyz  -> model_slug: not-a-real-model-xyz

Both returned normal completions. So the field proves the value was transmitted, and nothing more. Apologies for the noise; I would rather correct it than leave a false result in the record.

If a maintainer knows whether this endpoint respects model for session-mode requests, that would settle it. Either way the current code is wrong on its face, since the argument is accepted and then ignored.

Note for maintainers

MODEL_ALIASES in rest-api.cjs:25 maps bare names like gpt-4o to the provider chatgpt, so -m gpt-4o reads as a provider selection with no engine. The colon form -m chatgpt:<slug> is the only way to express an engine today. Worth a line in proxima --help if you want that discoverable.

[qodo-code-review]

PR Summary by Qodo

Fix ChatGPT engine override being dropped (model hardcoded to 'auto')

🐞 Bug fix 🕐 Less than 10 minutes

AI Description

• Use the engine argument to set ChatGPT request model when explicitly provided.
• Default to auto when no engine override is supplied.
• Log the requested model slug to aid debugging of model selection issues.

Diagram

graph TD
  CLI["CLI -m chatgpt:<slug>"] --> REST["rest-api.cjs"] --> MAIN["main-v2.cjs"] --> API["api.cjs"] --> ENG["chatgpt-engine.js send()"] -->|model=requestedModel (default auto)| OAI[("ChatGPT backend /backend-api/conversation")]

Loading

High-Level Assessment

This is the correct minimal fix: the engine override already propagates through the call chain, and the bug is isolated to the final payload construction. Considered adding central validation/aliasing for ChatGPT engine slugs, but keeping the backend-compatible pass-through here avoids coupling to a potentially changing model list and preserves existing behavior when no override is provided.

Files changed (1) +9 / -1

Bug fix (1) +9 / -1

chatgpt-engine.jsUse 'engine' override to set ChatGPT payload 'model' (default auto) +9/-1

Use 'engine' override to set ChatGPT payload 'model' (default auto)

• Adds logic in 'send()' to derive 'requestedModel' from the 'engine' argument when it is a non-empty, non-'auto' string. Replaces the hardcoded 'model: 'auto'' with 'model: requestedModel' and logs the chosen model slug for troubleshooting.

electron/providers/engines/chatgpt-engine.js

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

[sjgold]

Closing this. After further testing, the change doesn't deliver a functional fix: ChatGPT's ignores the field for browser-session requests and serves whatever the in-app model picker is set to. Confirmed behaviourally — requesting the research (Deep Research) slug returned a normal ~4s completion instead of a research run, and unrelated/nonsense slugs are accepted without effect.

So model: 'auto' may well be a deliberate safe default rather than a bug. Forwarding an arbitrary slug that the backend discards adds no capability and slight risk, so it isn't worth merging.

The underlying observation still stands and I've left it in #75: the ChatGPT engine accepts an engine argument it never reads, and separately, model selection for session-mode ChatGPT is controlled only by the in-app picker, not the API model field. Happy to help document that if it's useful.

[sjgold]

Closing this. After further testing it does not deliver a functional fix.

ChatGPT's /backend-api/conversation ignores the model field for browser-session requests and serves whatever the in-app model picker is set to. Confirmed behaviourally: requesting the research (Deep Research) slug returned a normal ~4s completion instead of a research run, and nonsense slugs are accepted without any effect.

So model: 'auto' may well be a deliberate safe default rather than a bug. Forwarding an arbitrary slug the backend discards adds no capability and slight risk, so it is not worth merging.

The underlying observation still stands in #75: the ChatGPT engine accepts an engine argument it never reads, and separately, model selection for session-mode ChatGPT is controlled only by the in-app picker, not the API model field. Happy to help document that if it is useful.