Skip to content

Reasoning effort is uncontrollable on OpenAI-compatible providers — no per-provider knob for gateways #545

Description

@ruttybob

Problem

Reasoning-effort control exists only for providers whose model ids are listed natively in the matrix:

  • coworker/providers/matrix.py_EFFORT_NATIVE entries (OpenAI Responses lineup) get wire-native effort positions.
  • coworker/providers/codex_provider.py honors settings.get("reasoning_effort").
  • coworker/providers/openai_provider.py pins reasoning_effort: none reactively when the server rejects tools+effort — but that is a retry path, not user control.

Meanwhile every _compat vendor in the registry (zai, deepseek, kimi, minimax, qwen, xai, …) rides the plain /v1/chat/completions wire with no way for the user to set reasoning effort at all: no per-provider setting, no capability flag, nothing in the settings surfaces. The request goes out with whatever default the server picks — even though many of these backends (GLM, Kimi, Qwen thinking modes) do honor an effort-style parameter.

Proposal

Add a per-provider (or per-model) reasoning-effort knob for _compat providers, routed through the existing thinking-controls envelope so it composes with the 7-level thinking scale rather than introducing a second control:

  • Optional field in the provider profile (SecretStore-backed), absent = current behavior (server default).
  • Resolve through thinkingLevelMap → wire-native reasoning_effort in the chat-completions kwargs, same shape codex uses.
  • Surface it in ProviderSetup / settings for compat vendors.

Notes

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions