LLM request linter

What it does

Paste a request and choose the model it is for, or let the tool read it from the request. The linter says what that model, and Salyro when the request goes through it, will do with the request. It finds parameters that are refused or silently ignored, capabilities the model does not have, a limit above the model's own, and values out of range. Nothing is called: the answer comes from the facts Salyro itself enforces.

Try it: Claude Opus 4.7 with a temperature, Gemini 3.6 Flash, which ignores top_p, or values Salyro refuses.

The provider, and Salyro

Each finding says what the provider does and, separately, what Salyro does. Salyro's part is given only where Salyro's engine decides it.

• Refused upstream. From Claude Opus 4.7 on, Anthropic returns a 400 for a non-default temperature or top_p, and the finding is an error. Salyro refuses the field whatever its value, so a request that works through Salyro works at the provider too.
• Ignored upstream. Gemini 3.6 Flash accepts temperature and top_p, discards them and answers at its own defaults, with nothing in the response to say so. That is a warning when the request goes to Google directly. Through Salyro it is an error, because Salyro refuses both kinds with a 400 that names the field, rather than report success for a setting that was thrown away.

A request in Chat Completions or Responses form is checked as Salyro would receive it, with Salyro's own rules too. A request in Anthropic Messages or Gemini form goes to its own provider, so it is checked against the model alone. The converter rewrites it in Salyro's form.

The rules

From Salyro's model catalogue, for the chosen model:

• Parameters it does not honour (parameter.rejected, parameter.ignored): temperature and top_p, where the catalogue records that the model refuses or ignores them.
• Capabilities it lacks (capability.*): images, tools, the parallel tool calls setting, structured output with a JSON schema, streaming.

From the model's own page, in Reference Data:

• Output limit (limit.max-output): a token limit above what the page states one answer may be.
• Context window (limit.context-window): an output limit larger than the whole context window.

From Salyro's request validation, for a request sent to Salyro (salyro.*):

• temperature from 0 to 2, top_p from 0 to 1, an output limit from 1 to 1,000,000 tokens.
• Up to 4 stop sequences of 1 to 256 characters.
• Up to 128 tools, and up to 1,000 messages in Chat Completions or input items in Responses. A tool name uses only letters, digits, _ and -, up to 64 of them.
• Up to 20 images, counting those in any message, a tool message's included.
• A tool_choice or parallel_tool_calls without tools, even as null.
• Both max_tokens and max_completion_tokens, a limit that is not a whole number, or an empty list of tools or of stop sequences.
• strict: true on a tool, for a model whose provider does not keep it: only OpenAI's do.
• An image by an address that is not https: or data:, or of a type Salyro does not carry: it takes PNG, JPEG, GIF and WebP. A content part in any message, a tool message's included, is text or image_url exactly as Salyro checks it: image_url an object of url and an optional detail of auto, low or high. In Responses, the same detail rule, and a text that holds format.
• A message whose content is an empty list, is left out, or is null: only an explicit content: null is allowed, and only on an assistant message that calls tools. In Responses, an empty input string or list.
• A json_schema response format, in either format, whose name is missing or is not 1 to 64 letters, digits, _ or -.
• A developer message in Chat Completions, and the fields and message parts the converter knows Salyro's form does not name, such as seed, n, stream_options or a message's name, even when they are null. Salyro refuses what it does not name, rather than drop it. A field it does name, such as temperature or tools, may be null, which it reads as left out, except where a null still counts as set: a temperature or top_p the model does not honour is refused, tools: null still needs a model with tools, a tool_choice or parallel_tool_calls without tools, even as null, is refused, and so is max_tokens: null beside max_completion_tokens. In Responses, instructions: null is a warning: Salyro accepts it, but sends the provider a system turn with no content, so leave it out.
• In Responses, OpenAI's own shapes: Salyro's /v1/responses takes tools, the tool choice and text.format in the Chat Completions shape, and input items as {role, content} with only input_text parts, as {type, text}, and input_image parts, whose image_url is a string.
• A comment or a trailing comma: Salyro reads the body as JSON.
• A model id without a provider, which Salyro reads as OpenAI's. claude-opus-4-6 is openai/claude-opus-4-6 there, which does not exist, so the finding names the id to send. When you choose the model to check against, the request's own model is still checked.
• The Responses fields Salyro names and refuses: store: true, previous_response_id, conversation, background, include, truncation, prompt, prompt_cache_key, service_tier, safety_identifier, metadata. false, null or leaving them out is accepted.

What it does not know

• A model the catalogue does not hold is reported as unknown, never guessed at.
• It does not check the content of the conversation: whether every tool call has its result, or turns are in an order the provider accepts.
• It does not check whether a tool's schema can be enforced strictly, which image types a provider itself takes, or the size of an image.
• A field the converter does not know of is not checked by name. The list above is what is checked.

Sources

Capabilities and unsupported parameters are Salyro's model catalogue, generated from the engine's own manifests, the same facts its gateway enforces. Output limits and context windows are Reference Data, each with the page it was read from and the date. The bounds are Salyro's request validation, shared with the engine in @salyro/types.