Model parameter support

Each row is one model from Salyro's catalogue and one request parameter. The status is what the catalogue records for that model, and no more:

• No restriction recorded: for temperature and top_p, the catalogue lists the models that do not honour them, and this model is not among them. That is Salyro's record, not a reading of the provider's own rules for the model.
• Rejected: the catalogue records that the provider refuses a request that sets the parameter, except, at most, to its default value.
• Ignored: the catalogue records that the provider accepts the parameter and silently ignores it. The answer comes at the model's own defaults, and nothing in the response says so.
• Supported: the catalogue records the capability the parameter needs (streaming, tools, parallel tool calls, a JSON schema or an image) for this model.
• Not available through Salyro: the catalogue records the capability as absent. Either the model lacks it, or Salyro's path to the model cannot carry it; the table does not say which.

Through Salyro, a request that sets a rejected or ignored parameter, or one not available through Salyro, is refused with a 400 naming the field, before it reaches the provider. Remove the field to use the model at its defaults, or pick another model. The LLM request linter runs these checks on a request you paste, in your browser.

The column "In the provider's API" is the field the parameter becomes when a request is written in the provider's own format. The format writers of the LLM parameter mapping produce it, so it changes when they do. A parameter a format has no field for says so and why. ‹value› stands for whatever you set.

The source column is Salyro's catalogue, with the provider page its models were checked against and the day. That page lists models; it is not a page about parameters. The caption gives the catalogue revision. Search by model or parameter, filter by provider, parameter or status, sort any column, and download the rows you see as CSV.