Capabilities and compatibility

LYRouter serves three chat endpoints, Chat Completions, Anthropic Messages and Responses, plus image, video, audio and other endpoints, from a single address. Whether a call succeeds and whether its params take effect depend on the chosen model and the channel that actually serves it. The gateway converts automatically between Chat Completions and Anthropic Messages, while Responses requests are forwarded unchanged to the channel's Responses endpoint. When the model does not support the requested endpoint or input, the gateway returns 400 directly; image and video endpoints drop some params the model does not support and list them in a response header.

Endpoints and channel protocols

Each channel uses one upstream protocol: OpenAI-compatible or Anthropic. The gateway decides whether to convert a request based on the channel protocol:

When calling through /v1/messages, error responses are converted to the Anthropic format as well, with only error.type and error.message and no error.code.

How params are handled during conversion

Cross-protocol conversion keeps only fields that have a matching meaning on both sides and removes the rest; these removals are not reported in response headers. If your application relies on the params below, confirm the protocol of the channel that actually serves it:

The three reasoning params reasoning_effort, enable_thinking and thinking_budget belong to different providers, and the gateway does not convert between them; for providers it has adapted, it removes the ones that provider does not recognize. When a model is served by several channels, verify JSON output, reasoning and caching behavior on each channel; see Connecting multiple providers.

Requests the gateway rejects

Before sending a request, the gateway checks the endpoint and input against the capabilities declared in the model catalog. When they do not match, it returns 400 directly, without calling the upstream or moving to a fallback model:

When the model catalog does not declare the endpoint scope, the gateway usually lets the request through, and the upstream decides whether to accept it. Fallback models should support the same endpoints and input types as the primary model; see Retries and fallback.

Vision input and image generation

These are different capabilities that use different endpoints:

• Vision understanding: put images in the messages of a chat endpoint, and the model outputs text. The model's input modalities must include images; a text-only model returns 400 This model accepts text input only.
• Image generation and editing: call /v1/images/generations or /v1/images/edits with a model whose output modalities include images, and the model outputs images.
• Video generation: call /v1/videos to submit an asynchronous task.

Filter by Input modalities and Output modalities on the left of the model marketplace to tell these kinds of models apart. Each model's endpoints, params and billing are in Multimodal capabilities.

Figure 1: The public model marketplace lists the models the gateway has adapted and can filter by input and output modality; what you can call is decided by the workspace model marketplace. Demonstration data; click the image for full size.

Params on image and video endpoints

On image and video endpoints, the gateway drops some params the selected model does not support and calls it as usual, listing the dropped param names in the X-Gateway-Unsupported-Parameters response header. To get an error in such cases instead, add this to the request:

curl "$LYROUTER_BASE_URL/v1/images/generations" \
  -H "Authorization: Bearer $LYROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -H "X-Gateway-Strict-Parameters: true" \
  -d '{"model":"google/gemini-3-pro-image","prompt":"A cat sitting by the window"}'

With strict mode on, a param that would be dropped makes the request return 400 unsupported parameters for this model: <parameter> with error.code unsupported_parameters, and the upstream is not called. Which params each model supports and drops is in Multimodal capabilities. Setting the environment variables is covered in Your first model call.

Checking a model's declared capabilities

Call GET /v1/models with an API key. When the model catalog has the information, model entries in the list include:

Context length, tool calling and structured output are finally decided by the upstream. After changing the model, provider or channel, verify params, streaming events and tool calls again with real requests; see Model versions and retirement.

FAQ

I set response_format. Why is JSON sometimes not returned?

Answer: When the request is routed to an Anthropic-protocol channel, response_format is removed during conversion. Check this request's Provider in the request logs and compare it with Upstream request under Raw packets. For stable JSON output, state the output format clearly in the prompt; you can also ask the Owner to disable sources you do not need in the model details; see Connecting multiple providers.

Codex calls return errors, but the same model works with Chat Completions. What should I do?

Answer: Codex uses the Responses endpoint, and its requests are forwarded unchanged to the channel's Responses endpoint. When it returns 400 This model does not support the responses API, switch to a model that declares Responses support. When it returns an upstream error such as 404, the channel serving this request may not provide a Responses endpoint; switch to another model, or ask the Owner to adjust the model's sources.