Add dedicated xai_key and fallback logic for xAI API key

[PeterDaveHello]

Relevant issues

Replaces #28060 after the temporary OSS staging branch was deleted during cleanup.

Linear ticket

N/A

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
  • Ran: .venv/bin/pytest tests/test_litellm/llms/xai/test_xai_key_fallback.py -q
  • Ran: .venv/bin/pytest tests/test_litellm/llms/xai/test_xai_chat_transformation.py tests/test_litellm/llms/xai/responses/test_xai_responses_transformation.py -q
• 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

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

CI (LiteLLM team)

CI status guideline:

• 50-55 passing tests: main is stable with minor issues.
• 45-49 passing tests: acceptable but needs attention
• <= 40 passing tests: unstable; be careful with your merges and assess the risk.

• Branch creation CI run
  Link:

• CI run for the last commit
  Link:

• Merge / cherry-pick CI run
  Links:

Screenshots / Proof of Fix

.venv/bin/pytest tests/test_litellm/llms/xai/test_xai_key_fallback.py -q
20 passed in 0.45s

.venv/bin/pytest tests/test_litellm/llms/xai/test_xai_chat_transformation.py tests/test_litellm/llms/xai/responses/test_xai_responses_transformation.py -q
20 passed in 1.11s

.venv/bin/black --check litellm/__init__.py litellm/llms/xai/chat/transformation.py litellm/llms/xai/common_utils.py litellm/llms/xai/responses/transformation.py litellm/realtime_api/main.py tests/test_litellm/llms/xai/test_xai_key_fallback.py
6 files would be left unchanged

Type

🐛 Bug Fix
✅ Test

Changes

• Add litellm.xai_key fallback for xAI API key resolution
• Share xAI key resolution across chat, responses, and realtime paths
• Preserve Responses API and realtime legacy litellm.api_key before XAI_API_KEY behavior
• Add focused tests for chat, responses, realtime, resolver, and model listing fallback order

[greptile-apps]

Greptile Summary

This PR introduces litellm.xai_key as a dedicated, provider-specific API key for xAI and centralizes key resolution for all three xAI request paths (chat, responses, realtime) through a single XAIModelInfo.get_api_key helper.

• New key & centralized resolver: litellm.xai_key is added to litellm/__init__.py and wired into XAIModelInfo.get_api_key, which now handles the full resolution chain for all xAI paths while preserving two distinct legacy orderings via a legacy_generic_before_env flag.
• Backward-compatible fallback order: The responses and realtime paths keep their existing litellm.api_key → XAI_API_KEY precedence (opt-in via the flag); the chat path continues to skip litellm.api_key in favour of going straight to XAI_API_KEY, matching pre-PR behaviour.
• Test coverage: 20 new focused unit tests cover the resolver logic, chat config, responses config, realtime resolution, and model listing — all mocked, no network calls.

Confidence Score: 4/5

The change is additive and backward-compatible; no existing key resolution chain is narrowed, only a new litellm.xai_key slot is inserted above the existing fallbacks.

All three xAI request paths now share a single resolver, the fallback orderings are covered by 20 unit tests, and no network calls or external state are touched. The only rough edge is the internal legacy_generic_before_env flag whose name requires reading the docstring to understand — a minor readability concern that does not affect correctness.

No files require special attention; litellm/llms/xai/common_utils.py contains the flag whose naming could be improved but is otherwise correct.

Important Files Changed

Filename	Overview
litellm/init.py	Adds xai_key module-level attribute, consistent with the existing pattern for other provider keys such as groq_key and gigachat_key
litellm/llms/xai/common_utils.py	Centralizes xAI API key resolution with new legacy_generic_before_env flag to preserve two different fallback orderings; get_models error message improved
litellm/llms/xai/chat/transformation.py	Delegates key resolution to XAIModelInfo.get_api_key, adding litellm.xai_key support while keeping existing behavior (no litellm.api_key fallback)
litellm/llms/xai/responses/transformation.py	Delegates key resolution to shared helper with legacy_generic_before_env=True, preserving the legacy litellm.api_key → XAI_API_KEY precedence; error message updated
litellm/realtime_api/main.py	Delegates xAI key resolution to shared helper with legacy_generic_before_env=True, matching previous litellm.api_key fallback behavior
tests/test_litellm/llms/xai/test_xai_key_fallback.py	New test file with 20 focused unit tests covering all fallback orderings for chat, responses, realtime, resolver, and model listing; all mocked, no real network calls

_{Reviews (1): Last reviewed commit: "Add dedicated xai_key and fallback logic..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[veria-ai]

PR overview

Adds xAI-specific API key fallback

This PR introduces a module-level litellm.xai_key, wires it into the xAI chat, responses, realtime, and model-listing key resolution paths, and extends secret redaction for provider key startup logs. I checked the precedence order around explicit request keys versus module/env fallbacks and the proxy logging redaction path.

Security review

• No new security issues were flagged in the latest review.
• 1 previously flagged issue(s) appear fixed in the latest changes.
• No review issues remain open on this pull request.

Risk: 2/10

[Sameerlite]

Can you please share the logic behind this? what problem are you trying to solve?

[PeterDaveHello]

Can you please share the logic behind this? what problem are you trying to solve?

This is the follow-up to the earlier xAI key feedback from #18660 / #28060, now rebased onto litellm_internal_staging.

The goal is to add a provider-specific module-level key for xAI, consistent with existing provider keys like litellm.openai_key and litellm.groq_key, so users can configure xAI globally without overloading the generic
litellm.api_key.

The implementation preserves the existing fallback order for each xAI path, and the redaction update prevents the new module-level credential from being exposed in proxy startup logs.

[PeterDaveHello]

@Sameerlite Thank you! Do you also have a chance to take a look at #28649? Thanks a lot!