OPENAI_USE_CHAT_COMPLETIONS=false is ignored for custom OPENAI_BASE_URL

[mzbgf]

$ summarize --version
0.16.3

When I use a custom OPENAI_BASE_URL together with:

{
  "openai": {
    "baseUrl": "https://example-gateway/v1",
    "useChatCompletions": false
  }
}

or set:

OPENAI_USE_CHAT_COMPLETIONS=false

I would expect summarize not to force /chat/completions.

But with a command like:

summarize "https://example.com" --model openai/gpt-5.4

it still goes through /chat/completions when the base URL is custom.

On gateways that expose only the Responses API, that fails. One symptom I saw was:

LLM returned an empty summary (model openai/gpt-5.4).

From reading the current implementation, this seems to come from:

const useChatCompletions = Boolean(forceChatCompletions) || isOpenRouter || isCustomBaseURL;

So a custom base URL overrides OPENAI_USE_CHAT_COMPLETIONS=false / openai.useChatCompletions=false.

Expected behavior: if OPENAI_USE_CHAT_COMPLETIONS=false or openai.useChatCompletions=false, summarize should not force /chat/completions just because OPENAI_BASE_URL is custom.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 10, 2026, 1:53 PM ET / 17:53 UTC.

Summary
Current main still exhibits the reported provider-routing bug, and the reporter’s open linked PR is the active implementation candidate. Keep the issue open until that PR is merged or closed.

Reproducibility: yes. from current-main source inspection: the custom-base condition independently forces chat completions after explicit false has been represented as a non-forcing boolean. A live gateway request was not run, so this is source-reproducible rather than runtime-reproduced.

Next step
The same author already has an open linked fix PR, so maintainers should review and land or close that PR rather than queue a competing repair.

Review details

Best possible solution:

Land a tri-state preference fix that honors explicit false and true while retaining the existing custom-base fallback only when the preference is unset, with focused endpoint-routing regression coverage.

Do we have a high-confidence way to reproduce the issue?

Yes, from current-main source inspection: the custom-base condition independently forces chat completions after explicit false has been represented as a non-forcing boolean. A live gateway request was not run, so this is source-reproducible rather than runtime-reproduced.

Is this the best way to solve the issue?

Yes in direction: preserving true, false, and unset is the narrowest compatibility-safe solution because it honors explicit configuration without changing the established default for gateways whose preference is unset.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Closing this issue before fix: respect explicit openai chat completion toggle #236 merges would remove the canonical tracker for a confirmed current-main bug.
• Changing the unset custom-base default would risk existing OpenAI-compatible gateways, so the fix should distinguish explicit false from an absent preference.

Codex review notes: reasoning high; reviewed against 8999563578c2.

Label changes

Label changes:

• remove clawsweeper:queueable-fix: Current issue advisory state no longer selects this label.
• remove clawsweeper:fix-shape-clear: Current issue advisory state no longer selects this label.

Label justifications:

• P2: The bug blocks Responses-only custom OpenAI-compatible gateways but is confined to a bounded provider-routing path.
• impact:auth-provider: The failure concerns OpenAI provider API-surface selection and request routing.

Evidence reviewed

What I checked:

• Current provider routing: Current main selects chat completions whenever the base URL is custom, even when the incoming force flag is false. (src/llm/providers/openai.ts:98, fcf8c8e5e98d)
• Configuration boundary: The routing API currently represents the preference as an optional boolean force flag, which cannot distinguish explicit false from an unset preference after propagation. (src/llm/providers/openai.ts:20, 8999563578c2)
• Regression coverage gap: Existing provider tests cover explicit true and standard Responses routing, but current-main coverage does not require explicit false to override the custom-base chat default. (tests/llm.openai-provider.test.ts:1, 8999563578c2)
• Open paired implementation: The reporter opened a mergeable PR that explicitly closes this issue, preserves true/false/unset, and adds focused configuration and provider-routing tests. The discussion also supports separating the transport base URL from API-surface selection. (0b2760f0a0f5)

Likely related people:

• Peter Steinberger: Git blame and file history attribute the current OpenAI client configuration and custom-base routing behavior to the v0.16.3 release commit. (role: feature-history owner; confidence: high; commits: fcf8c8e5e98d; files: src/llm/providers/openai.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[HerShin5]

One small routing detail I'd make explicit here: a custom OPENAI_BASE_URL should not by itself imply "Chat Completions only". It is really just a transport target, while the API surface (/chat/completions vs /responses) should remain an independently resolved capability/preference.

A clean regression shape could be:

• no explicit preference + custom base URL: keep today's safe default if you want backwards compatibility;
• explicit useChatCompletions: false: call <baseUrl>/responses, even for a custom gateway;
• explicit true: call <baseUrl>/chat/completions;
• log the final redacted target path on empty-summary failures, e.g. target=/v1/responses vs target=/v1/chat/completions, without printing keys.

That last diagnostic matters because the current user-visible symptom (LLM returned an empty summary) hides whether this was a summarization failure or a gateway route mismatch.

Disclosure: I'm associated with/evaluating KiroForge (https://kiroforge.cloud/v1) as an OpenAI-compatible gateway, so I care about this exact edge case. Gateways increasingly expose different subsets of the OpenAI-compatible surface; treating baseUrl and API-surface selection as separate choices would make this much easier to support/test.