epam / epam/statgpt-backend

Migrate the chat completion app endpoint to the OpenAI Responses API

Open
#488 1 comment 0 reactions 1 assignee Claimed by @Fedir-Yatsenko View on GitHub
enhancement
Dominant language
Python
Stars
26
Forks
1
Avg merge
1d 17h
Merged PRs (30d)
25

Description

## StatGPT Backend version

`latest`

## What is the problem this feature will solve?

The app backend currently exposes its conversational interface through the Chat Completions API surface (`add_chat_completion_with_dependencies` / `ChatCompletion` in `statgpt/app/application/app_factory.py`). The Chat Completions API is effectively in maintenance mode upstream, while the **OpenAI Responses API** is the forward-looking interface and offers a richer, stateful model for agentic flows (built-in tool calls, reasoning items, structured streaming events, and server-side state).

Staying on Chat Completions limits our ability to adopt these capabilities and keeps us on an API surface that no longer receives new features.

## What is the proposed feature or solution?

Migrate the app endpoint to serve the OpenAI Responses API instead of (or alongside) Chat Completions.

> [!IMPORTANT]
> **Prerequisite / blocker:** `aidial-sdk` does **not** currently support the Responses API. SDK support must be added upstream first before this migration can proceed. This issue depends on that work.

High-level scope once the SDK supports it:

- Replace/augment the chat-completion registration in `DialAppFactory` with a Responses-based endpoint.
- Adapt the channel completion implementations (`ChannelCompletion`, `ChannelOnboardingCompletion`) to the Responses request/response and streaming model.
- Map our existing tool-calling agent output (tool calls, intermediate results, stages) onto Responses event/item types.
- Preserve existing DIAL integration behavior (configuration endpoint, heartbeat, telemetry, middleware).

## What alternatives have you considered?

- **Stay on Chat Completions** — no upstream SDK work needed, but forgoes Responses API capabilities and remains on a maintenance-mode surface.
- **Dual-serve both APIs during a transition** — lower migration risk, at the cost of maintaining two code paths.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.