Skip to content

fix: route OpenAI models through Responses API - #99

Open
Maurice-aXeTech wants to merge 2 commits into
frappe:developfrom
aXeTech-NL:fix/openai-responses-routing
Open

fix: route OpenAI models through Responses API#99
Maurice-aXeTech wants to merge 2 commits into
frappe:developfrom
aXeTech-NL:fix/openai-responses-routing

Conversation

@Maurice-aXeTech

Copy link
Copy Markdown

Problem

Flow always sends chat calls through LiteLLM's Chat Completions path. That remains valid for many models, but OpenAI is increasingly Responses-first; those models can reject or lose tool-call behavior when forced through /chat/completions.

There is currently no supported way to select the Responses API or deliberately retain Chat Completions for a proxy.

Change

  • add an API Style setting to Flow Model: Auto, Responses, or Chat Completions
  • route direct official openai/* models through LiteLLM's Responses bridge in Auto mode
  • leave custom-base/proxy OpenAI connections and non-OpenAI providers on LiteLLM's existing/default route in Auto mode
  • allow either route to be selected explicitly
  • use the same routing helper for normal calls, streaming calls, persisted tool-result conversations, and Test Connection

The implementation continues to call litellm.completion(). It selects LiteLLM's built-in Responses bridge through the canonical openai/responses/<model> ID, so Flow keeps its current normalized ModelResponse, streaming, and tool-call handling instead of maintaining a second parser.

Compatibility

  • existing Flow Model rows default to Auto
  • non-OpenAI providers are unchanged
  • OpenAI-compatible proxies with a custom Base URL are unchanged in Auto mode
  • users can explicitly choose Chat Completions when required

Validation

  • focused tests cover Auto routing, explicit overrides, tool calls, streaming, persisted assistant/tool messages, and Test Connection
  • changed-file Ruff/format, Python compilation, JSON validation, and diff checks pass
  • the Responses bridge was also smoke-tested against a local /v1/responses endpoint with a real function-call response

This is the first isolated change in a planned provider-connection cleanup; it has no dependency on the fork's Frappe 16-specific features.

@greptile-apps

greptile-apps Bot commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

Confidence Score: 5/5

The PR appears safe to merge because no eligible blocking failure remains.

No blocking failure remains.

Reviews (2): Last reviewed commit: "fix: use valid Responses connection-test..." | Re-trigger Greptile

OpenAI Responses requires max_output_tokens >= 16. LiteLLM maps max_tokens to that field, so use the minimum accepted value when testing a Flow Model connection.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant