[BE] fix: register xai as a canonical provider so xAI/Grok model prices load

[Anuj7411]

Details

Following the pattern of #7262 (which registered azure) and #7432 (perplexity) — xai is not currently in PROVIDERS_MAPPING, so all 40 entries in model_prices_and_context_window.json tagged with litellm_provider: "xai" silently drop at load time. Every one publishes non-zero input+output rates: the full grok-2 / grok-3 / grok-4 / grok-4-fast / grok-code families.

29 of the 40 also publish cache_read_input_token_cost. xAI's cost calculator in LiteLLM (litellm/llms/xai/cost_calculator.py) delegates to generic_cost_per_token, which is the same helper OpenAI uses — so xai's usage payload follows OpenAI's shape (prompt_tokens_details.cached_tokens flattened into original_usage.*). That means xai routes cleanly through the existing SpanCostCalculator::textGenerationWithCacheCostOpenAI calculator; no new cache-calc method needed, just a mirror of the azure entry in PROVIDERS_CACHE_COST_CALCULATOR.

Change checklist

• User facing
• Documentation update

Issues

• Resolves #
• OPIK-

AI-WATERMARK

AI-WATERMARK: yes

• Tools: Claude Code (CLI)
• Model(s): Claude Opus 4.7
• Scope: assisted in scouting the reachable xai model count (40 non-zero-cost, 29 with cache_read), inspected litellm/llms/xai/cost_calculator.py to confirm xai delegates to generic_cost_per_token and therefore shares the OpenAI usage shape, drafted the two-line plumbing change following the [BE] fix: register azure as a canonical provider so Azure model prices load #7262 pattern, and wrote the parameterized branch-coverage test
• Human verification: ran the test suite locally; verified xai models route through the correct calculator per the cache-vs-plain gate; cross-checked expected dollar values against the rates in model_prices_and_context_window.json

Testing

Local verification on JDK 25 + Maven 3.9.9:

mvn -ntp -f apps/opik-backend/pom.xml \
  -Dtest=CostServiceTest,SpanCostCalculatorTest test

Result: 102/102 green (2 new parameterized cases under calculateCostHandlesXaiModels, matching the style established in #7262 for Azure).

Scenarios covered:

1. Plain text-generation route — xai/grok-2 (input 2e-6, output 1e-5, no cache rates configured). With prompt_tokens=1000, completion_tokens=200, expected 0.004 (1000 * 2e-6 + 200 * 1e-5). Exercises the path where xai is registered but resolveCalculator falls through past the cache check to textGenerationCost.
2. Cache-aware route via OpenAI calc — xai/grok-3 (input 3e-6, output 1.5e-5, cache_read 7.5e-7). With original_usage.prompt_tokens=1000, original_usage.completion_tokens=200, original_usage.prompt_tokens_details.cached_tokens=300, expected 0.005325 (non-cached input 700 * 3e-6 + 200 * 1.5e-5 + 300 * 7.5e-7). Exercises the new PROVIDERS_CACHE_COST_CALCULATOR entry.

Documentation

No docs change. Behavior change is invisible to end users beyond accurate (non-zero) cost numbers for xAI/Grok traces on 40 previously-dropped models.

[andrescrz]

Hi @Anuj7411

Thanks for the contribution! I reviewed the PR and everything looks good from my side. I've approved it, and all CI checks have passed successfully.

We'll merge it shortly, and the change will be included in the next Opik release.

Thanks again for contributing to Opik!