Use native Responses API flow for OpenAI reasoning models with tools

[geekforbrains]

Summary

Operator currently uses litellm.acompletion() everywhere and relies on LiteLLM's chat-to-responses bridge for OpenAI models that require /v1/responses when reasoning_effort and tools are used together.

The immediate regression is fixed by routing those requests through LiteLLM's Responses bridge, but the deeper implementation should make the OpenAI path natively Responses-aware instead of depending on a model alias rewrite.

Problem

• OpenAI reasoning models such as gpt-5.4 reject function tools + reasoning_effort on /v1/chat/completions.
• LiteLLM advertises reasoning_effort support, so capability checks alone are not enough to select the correct API route.
• The current forward fix rewrites request models to openai/responses/... so LiteLLM bridges the call.

Goal

Implement a first-class Responses API path for relevant OpenAI models and request shapes, while preserving the existing agent loop semantics (tool execution, fallback handling, usage accounting, cancellation, and history sanitation).

Scope

• Detect when an OpenAI call should be executed through Responses natively.
• Call litellm.aresponses() (or equivalent native path) instead of litellm.acompletion() for those requests.
• Normalize Responses output back into the internal agent loop representation.
• Confirm tool-call parsing, text extraction, and usage accounting still behave correctly.
• Revisit whether model capability checks should distinguish parameter support from endpoint requirements.

Notes

The patch release fix intentionally keeps behavior stable and should remain until the native Responses path is complete and covered by tests.