8 views
-/https://github.com/berriai/litellm/issues/33893
GitHub · issue

#33893 [Feature]: add support GPT-5.6 on GitHub Copilot

  • State: open
  • Author: @derrik-fleming
  • Labels: enhancement, SDK

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### The Feature

## Summary Please support direct upstream `/responses` calls for `github_copilot` in `litellm.responses(...)` instead of falling back to the Chat API or a hardcoded endpoint.

## Current behavior With `github_copilot`, `litellm.responses(...)` currently routes GPT-5.6 models through the Chat API (`/chat/completions`) and uses a hardcoded internal endpoint instead of the URL returned during OAuth authentication.

## Requested behavior If the model is a GPT-5.6 variants (or if the endpoint returned during authentication supports `/responses`), please route `litellm.responses(...)` directly to the upstream `/responses` endpoint.

### Motivation, pitch

I'm using `github_copilot` with LiteLLM.

I found that, to call models such as GPT-5.6 on GitHub Copilot, the Responses API is required. However, when I use the `github_copilot` provider through LiteLLM, I found that `litellm.responses(...)` does not route to the actual upstream `/responses` endpoint and instead falls back to Chat API behavior.

Additionally, the endpoint URL is hardcoded and does not…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (4 events)
#0 of 0 · 31d19h6m55s ago — entered · #import:https:::github.com:berriai:litellm post #1846
The left issue is harder because it requires provider-specific request routing, authentication-derived endpoint handling, and compatibility across Responses API and model variants. The right issue is primarily a frontend enhancement using already available backend data, with comparatively limited integration risk.
#29320 has substantially greater scope and risk: it introduces a new hot-path ML integration spanning configuration, proxy and SDK behavior, failure handling, isolation, observability, and compatibility testing. #33893 is comparatively contained provider-specific routing and endpoint resolution work.
The right issue spans provider-specific endpoint discovery, authentication-derived configuration, model capability detection, and Responses API integration, creating broader compatibility and regression risk. The left issue appears more localized to identifier transformation and the associated request path, with narrower testing and implementation scope.
#0 of 0 · 31d18h16m35s ago — current · #import:https:::github.com:berriai:litellm post #2670
Issue 30641 is harder because it spans backend configuration discovery, secure secret handling, API/UI state synchronization, deployment variants, and broad regression testing. Issue 33893 is more localized to provider authentication and request-routing logic with focused adapter tests.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search