litellm - 💡(How to fix) Fix [Bug]: github_copilot provider: IndexError (list index out of range) when max_tokens=1 for newer Claude models (opus-4.7, opus-4.8) [1 pull requests]

What happened?

When sending a request with max_tokens=1 to newer Claude models (claude-opus-4.7, claude-opus-4.8) via the github_copilot provider, LiteLLM returns HTTP 500 with:

{"error":{"message":"list index out of range","type":"None","param":"None","code":"500"}}

The same request with max_tokens=2 or higher works perfectly. This breaks Claude Code's model validation, which hardcodes max_tokens:1 as a probe to check if a model is usable.

Relevant log output

Response headers on the 500:

server: uvicorn
x-litellm-version: 1.81.3
x-litellm-call-id: 84fd88ec-6c5f-415f-a15c-76e4ef73481f
x-litellm-model-id: 7b4da4cc-f571-4e47-b361-c40b0422815b
x-litellm-response-cost: 0

The error is a Python IndexError originating inside litellm (not from the upstream Copilot backend), as evidenced by server: uvicorn and x-litellm-response-cost: 0 (no upstream completion was processed).

How to reproduce

# FAILS (500)
curl -s "$LITELLM_BASE/v1/messages" \
  -H "Authorization: Bearer $KEY" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"claude-opus-4.7","max_tokens":1,"messages":[{"role":"user","content":"Hi"}]}'

# WORKS (200)
curl -s "$LITELLM_BASE/v1/messages" \
  -H "Authorization: Bearer $KEY" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"claude-opus-4.7","max_tokens":2,"messages":[{"role":"user","content":"Hi"}]}'

Also reproducible via /v1/chat/completions.

Test matrix

Likely root cause

The newer Copilot backend (for opus-4.7/4.8) returns a different response format compared to older models. When queried via /v1/chat/completions with max_tokens=1:

opus-4.7 response (Anthropic-native, no choices):

{
    "id": "msg_vrtx_...",
    "model": "github_copilot/claude-opus-4.7",
    "usage": {"completion_tokens": 1, "prompt_tokens": 14},
    "copilot_usage": {...}
}

opus-4.6 response (standard OpenAI choices format):

{
    "id": "154d6232-...",
    "model": "github_copilot/Claude Opus 4.6",
    "choices": [{"finish_reason": "length", "index": 0, "message": {"content": "Hi", "role": "assistant"}}],
    "usage": {"completion_tokens": 1, "prompt_tokens": 8}
}

At max_tokens=1, the newer backend appears to return a response with no content/choices field. LiteLLM's response parser indexes into a missing or empty structure without guarding, causing the IndexError.

Impact

• Claude Code cannot switch to claude-opus-4.7 or claude-opus-4.8 via /model command because its model-validation probe uses max_tokens:1.
• Any application that sends max_tokens=1 to these models through the proxy will crash.

Related PRs

• #28054 (open) — acknowledges the format mismatch for newer Copilot models but is unmerged
• #24765 (open) — another symptom of the Copilot format mismatch

LiteLLM version

• LiteLLM proxy version: 1.81.3
• OS: Linux (Azure Container Apps)

Expected behavior

max_tokens=1 should either succeed (return a 1-token response) or return a graceful error — not crash with an unhandled IndexError.