Is it a request payload issue?
If it's a request payload issue, you MUST know
N/A - this is a response-schema conformance issue, not a request payload issue.
Describe the bug
The Anthropic-compatible model listing (GET /v1/models routed to the Claude handler) returns model objects that omit fields defined by Anthropic's List Models response schema, so the response is not a faithful emulation of the upstream API.
Per the spec, each object in data[] is a ModelInfo with id, display_name, max_input_tokens (number), max_tokens (number), created_at, type, and an optional capabilities.
The Claude branch of convertModelToMap (internal/registry/model_registry.go) currently emits only id, object, owned_by, created_at, type, and display_name, and emits display_name only when it is non-empty:
max_input_tokens — not emittedmax_tokens — not emitteddisplay_name — dropped for any model without a configured display name
The registry already holds the data needed (ModelInfo.ContextLength and ModelInfo.MaxCompletionTokens), and the Gemini branch of the same function already surfaces equivalent metadata as inputTokenLimit / outputTokenLimit - so the Claude branch is simply incomplete relative to both the spec and existing in-repo precedent.
CLI Type
claude code (any Claude-backed account; the gap is in the Claude-compatible /v1/models output regardless of the underlying auth type)
Model Name
Any claude-* model (example: claude-sonnet-4-6)
LLM Client
Any client that dynamically fetches the model list and deserializes it strictly against the documented Anthropic schema. Clients that ship a hardcoded model list are unaffected, which is why this has gone unnoticed.
Request Information
curl -s http://localhost:8317/v1/models \
-H 'User-Agent: claude-cli' \
-H 'Anthropic-Version: 2023-06-01' \
-H 'X-Api-Key: <key>'
Each entry in data[] comes back without max_input_tokens / max_tokens, and without display_name when the model has no configured display name.
Expected behavior
The Claude listing should include the documented fields for every model:
max_input_tokens sourced from ContextLengthmax_tokens sourced from MaxCompletionTokensdisplay_name always present (falling back to the model id when unset)
with sensible defaults for the token fields when a model lacks the metadata, so the listing always carries usable, schema-valid values.
Additional context
Is it a request payload issue?
If it's a request payload issue, you MUST know
N/A - this is a response-schema conformance issue, not a request payload issue.
Describe the bug
The Anthropic-compatible model listing (
GET /v1/modelsrouted to the Claude handler) returns model objects that omit fields defined by Anthropic's List Models response schema, so the response is not a faithful emulation of the upstream API.Per the spec, each object in
data[]is aModelInfowithid,display_name,max_input_tokens(number),max_tokens(number),created_at,type, and an optionalcapabilities.The Claude branch of
convertModelToMap(internal/registry/model_registry.go) currently emits onlyid,object,owned_by,created_at,type, anddisplay_name, and emitsdisplay_nameonly when it is non-empty:max_input_tokens— not emittedmax_tokens— not emitteddisplay_name— dropped for any model without a configured display nameThe registry already holds the data needed (
ModelInfo.ContextLengthandModelInfo.MaxCompletionTokens), and the Gemini branch of the same function already surfaces equivalent metadata asinputTokenLimit/outputTokenLimit- so the Claude branch is simply incomplete relative to both the spec and existing in-repo precedent.CLI Type
claude code (any Claude-backed account; the gap is in the Claude-compatible
/v1/modelsoutput regardless of the underlying auth type)Model Name
Any
claude-*model (example: claude-sonnet-4-6)LLM Client
Any client that dynamically fetches the model list and deserializes it strictly against the documented Anthropic schema. Clients that ship a hardcoded model list are unaffected, which is why this has gone unnoticed.
Request Information
Each entry in
data[]comes back withoutmax_input_tokens/max_tokens, and withoutdisplay_namewhen the model has no configured display name.Expected behavior
The Claude listing should include the documented fields for every model:
max_input_tokenssourced fromContextLengthmax_tokenssourced fromMaxCompletionTokensdisplay_namealways present (falling back to the modelidwhen unset)with sensible defaults for the token fields when a model lacks the metadata, so the listing always carries usable, schema-valid values.
Additional context
internal/registry/model_registry.go(convertModelToMap,case "claude")