litellm - ✅(Solved) Fix [Bug]: GitHub Copilot provider does not support reasoning_effort from Claude Code [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#25666Fetched 2026-04-14 05:38:20
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
Participants
Timeline (top)
labeled ×4cross-referenced ×1

When using the github_copilot provider with Claude models (e.g., github_copilot/claude-sonnet-4.5, github_copilot/claude-opus-4.6) from Claude Code, extended thinking does not work. Claude Code sends the Anthropic-native thinking parameter via POST /v1/messages, but since GitHub Copilot uses an OpenAI-compatible API, litellm needs to convert it to reasoning_effort. Currently this conversion does not happen — the thinking parameter is silently dropped, reasoning_effort never reaches the Copilot API, and the response contains no reasoning output.

Root Cause

When using the github_copilot provider with Claude models (e.g., github_copilot/claude-sonnet-4.5, github_copilot/claude-opus-4.6) from Claude Code, extended thinking does not work. Claude Code sends the Anthropic-native thinking parameter via POST /v1/messages, but since GitHub Copilot uses an OpenAI-compatible API, litellm needs to convert it to reasoning_effort. Currently this conversion does not happen — the thinking parameter is silently dropped, reasoning_effort never reaches the Copilot API, and the response contains no reasoning output.

Fix Action

Fixed

PR fix notes

PR #25667: fix: support reasoning_effort for Claude models on github_copilot provider

Description (problem / solution / changelog)

Relevant issues

Fixes https://github.com/BerriAI/litellm/issues/25666

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

  • I have Added testing in the tests/test_litellm/ directory, Adding at least 1 test is a hard requirement - see details
  • My PR passes all unit tests on make test-unit
  • My PR's scope is as isolated as possible, it only solves 1 specific problem
  • I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

Screenshots / Proof of Fix

Before fixreasoning_effort not present in request to Copilot API:

After fixreasoning_effort: "medium" correctly forwarded to Copilot API, response contains reasoning output:

Type

🐛 Bug Fix

Changes

Problem

The github_copilot provider does not support reasoning_effort for Claude models. Two issues:

  1. GithubCopilotConfig inherits OpenAIConfig.map_openai_params, which delegates to a hardcoded openAIGPTConfig singleton. That singleton uses its own get_supported_openai_params — not the subclass override — so reasoning_effort is filtered out.

  2. When requests come from Anthropic-compatible clients (e.g., Claude Code via POST /v1/messages), the native thinking parameter is not converted to reasoning_effort. Copilot's OpenAI-compatible API does not understand thinking, so the intent is lost.

Fix

litellm/llms/github_copilot/chat/transformation.py:

  • Override get_supported_openai_params to add thinking and reasoning_effort for all Claude models.
  • Override map_openai_params to:
    • Convert Anthropic-native thinkingreasoning_effort (defaults to "medium" when thinking is enabled and no explicit reasoning_effort is set).
    • Strip thinking from the request (Copilot doesn't understand it).
    • Use self._map_openai_params() for Claude models instead of delegating to the singleton, so the correct get_supported_openai_params is called.
  • Non-Claude models (GPT, O-series) are unaffected — they fall through to the parent implementation.

tests/test_litellm/llms/github_copilot/test_github_copilot_transformation.py:

  • Added 11 new tests covering reasoning_effort pass-through, thinkingreasoning_effort conversion, thinking stripping, and non-Claude model behavior.

Changed files

  • litellm/llms/github_copilot/chat/transformation.py (modified, +68/-10)
  • tests/test_litellm/llms/github_copilot/test_github_copilot_transformation.py (modified, +146/-6)
RAW_BUFFERClick to expand / collapse

Check for existing issues

  • I have searched the existing issues and checked that my issue is not a duplicate.

What happened?

Description

When using the github_copilot provider with Claude models (e.g., github_copilot/claude-sonnet-4.5, github_copilot/claude-opus-4.6) from Claude Code, extended thinking does not work. Claude Code sends the Anthropic-native thinking parameter via POST /v1/messages, but since GitHub Copilot uses an OpenAI-compatible API, litellm needs to convert it to reasoning_effort. Currently this conversion does not happen — the thinking parameter is silently dropped, reasoning_effort never reaches the Copilot API, and the response contains no reasoning output.

Steps to Reproduce

Give your coding agent this prompt to reproduce:

  1. Clone the litellm repo and install dependencies with pip install -e ".[proxy]".
  2. Create a proxy config YAML with a github_copilot/claude-* model (e.g., github_copilot/claude-opus-4.6). Set drop_params: true and a master_key.
  3. Start the litellm proxy from source: python -m litellm.proxy.proxy_cli --config proxy_config.yaml --port 9000 --detailed_debug.
  4. Launch Claude Code with a temporary config that sets ANTHROPIC_BASE_URL=http://localhost:9000 and ANTHROPIC_API_KEY=<your master_key>, pointing it at the litellm proxy.
  5. Send a request through Claude Code that triggers extended thinking (e.g., ask it to solve a complex reasoning problem).
  6. Inspect the litellm proxy debug logs. Check whether reasoning_effort appears in the request forwarded to the Copilot API, and whether the Copilot response contains reasoning-related fields (e.g., reasoning_content, reasoning_text).

Expected: reasoning_effort is present in the request to Copilot, and the response includes reasoning content.

Actual: reasoning_effort is not passed through. The Copilot request contains no reasoning parameter, and the response has no reasoning output.

Relevant log output

What part of LiteLLM is this about?

Proxy

What LiteLLM version are you on ?

v1.83.7

Twitter / LinkedIn details

No response

extent analysis

TL;DR

The issue can likely be fixed by modifying the litellm proxy to convert the thinking parameter to reasoning_effort when forwarding requests to the GitHub Copilot API.

Guidance

  • Verify that the thinking parameter is being sent by Claude Code by inspecting the request payload in the litellm proxy debug logs.
  • Check the litellm proxy code to see where the thinking parameter is being dropped and modify it to convert the parameter to reasoning_effort before forwarding the request to the Copilot API.
  • Test the modified proxy by repeating the steps to reproduce and checking the debug logs to ensure that reasoning_effort is now being passed through to the Copilot API.
  • If the issue persists, verify that the Copilot API is correctly configured to handle the reasoning_effort parameter and return reasoning-related fields in the response.

Example

No code snippet is provided as the issue does not include specific code details, but the modification would likely involve adding a parameter conversion step in the litellm proxy code that handles requests to the Copilot API.

Notes

The fix assumes that the litellm proxy has the capability to modify request parameters before forwarding them to the Copilot API. If this is not the case, additional modifications may be required.

Recommendation

Apply workaround: Modify the litellm proxy to convert the thinking parameter to reasoning_effort to enable extended thinking with Claude models. This workaround is recommended as it directly addresses the identified issue and allows for extended thinking to work as expected.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING