[Feature]: Support Anthropic-native response format for /v1/models endpoint (Claude Code gateway discovery)

[odinwang]

Feature Request

Summary

Claude Code 2.1.126+ added gateway model discovery: when ANTHROPIC_BASE_URL points at a compatible gateway, it queries {base_url}/v1/models at startup and populates the /model picker with discovered models labeled "From gateway".

However, this discovery only works with the Anthropic-native /v1/models response format — it does not parse the OpenAI-format response that LiteLLM currently returns.

Current Behavior

LiteLLM's /v1/models returns OpenAI format:

{
  "data": [
    {
      "id": "claude-opus-4-6",
      "object": "model",
      "created": 1677610602,
      "owned_by": "openai"
    }
  ],
  "object": "list"
}

Expected Behavior

Claude Code expects the Anthropic native format:

{
  "data": [
    {
      "type": "model",
      "id": "claude-opus-4-6",
      "display_name": "Claude Opus 4.6",
      "created_at": "2025-05-14T00:00:00Z"
    }
  ],
  "has_more": false,
  "first_id": "claude-opus-4-6",
  "last_id": "claude-haiku-4-5"
}

Key differences:

• type: "model" instead of object: "model"
• display_name field (used as label in the picker)
• created_at (ISO 8601) instead of created (unix timestamp)
• Top-level has_more, first_id, last_id instead of object: "list"

Claude Code's Discovery Filter

From the docs:

Only models whose ID begins with claude or anthropic are added to the picker. Results are cached to ~/.claude/cache/gateway-models.json.

Authentication: sends x-api-key header (or Bearer token via ANTHROPIC_AUTH_TOKEN), same as inference requests.

Proposed Solution

Since LiteLLM already supports the Anthropic /v1/messages pass-through endpoint for Claude Code users, adding an Anthropic-format response option for /v1/models would complete the compatibility story. Possible approaches:

1. Content negotiation: Return Anthropic format when the request includes anthropic-version header (same header Claude Code sends for /v1/messages)
2. Separate endpoint: Serve Anthropic-format at /anthropic/v1/models (similar to the existing /anthropic pass-through path)
3. Config option: A setting like model_list_format: anthropic to switch the /v1/models response format globally

Environment

• LiteLLM version: latest stable (deployed on EKS)
• Claude Code version: 2.1.128
• Config: Using ANTHROPIC_BASE_URL pointing to LiteLLM proxy root, with /v1/messages working correctly

Additional Context

The gateway model discovery feature was added in Claude Code 2.1.126 changelog. Many Claude Code + LiteLLM users would benefit from this since it enables seamless model switching without manual configuration.

[smqd19]

This is a common challenge when integrating models with different response formats, especially in production settings where you want flexible discovery. In our experience, we've handled similar cases by implementing a response normalization layer:

• First, detect the response format (e.g., check for type field vs. object).
• If it's in OpenAI format, transform it into the native Anthropic structure by mapping fields accordingly:
  • object to type: "model"
  • created UNIX timestamp to created_at ISO string
  • Generate display_name (if not provided) from existing data or fallback to id.
• This way, downstream code always sees a consistent format, reducing conditional logic and potential bugs.
  For your case, you could add this normalization step before populating the /model picker, ensuring compatibility with Claude Code’s discovery filter.

[mrchi]

Or could we allow custom response fields in API /v1/models?

[xianzuyang9-blip]

For Claude Code gateway users, I would validate discovery and runtime separately:

1. /v1/models returns Claude-style model ids that Claude Code can recognize.
2. ANTHROPIC_BASE_URL points to the gateway root expected by Claude Code, not an already-suffixed endpoint.
3. Streaming works on a real coding task, not just a tiny curl test.
4. Failed or retried requests are accounted for clearly, since agents can retry a lot.

I maintain a small GPT/Claude-compatible endpoint for low-volume testing as well: https://99887123.xyz/v1

[HerShin5]

This would be useful beyond LiteLLM specifically. For any gateway that fronts multiple models, /v1/messages compatibility is only half of the Claude Code experience; model discovery is what makes the gateway feel first-class in /model.

I'm testing KiroForge as an OpenAI-compatible multi-model gateway (https://kiroforge.cloud/v1), and the same issue shows up conceptually when a bridge/proxy translates inference requests but the model list stays in the wrong shape for the client that is doing discovery.

A small compatibility test matrix might help here:

• /v1/messages works with Claude Code
• streaming works
• tool calls pass through
• /v1/models returns Anthropic-native format when Claude Code is the caller
• discovered models preserve stable IDs/display names

Disclosure: I'm associated with/evaluating KiroForge; mainly adding this as a gateway-compatibility data point.

[yassin-berriai]

Closed by #30273, which merged into a release branch that was deleted and never shipped, so the feature is still absent. #35455 reimplements it