Skip to main content
Surplus Intelligence
Marketplace
ReferenceParameter compatibility

Parameter Compatibility

Which parameters work with which models.

Guaranteed Compatible (all models)

modelDescription · Model name
messagesDescription · Message array
streamDescription · Enable SSE streaming
max_tokens / max_completion_tokensDescription · Max output tokens
temperatureDescription · Sampling temperature
top_pDescription · Nucleus sampling
stopDescription · Stop sequences
seedDescription · Deterministic sampling
Why the same parameter survives on one wire and not another
Chat wire — a sievePasses through unless explicitly stripped. Provider extras usually survive.
Anthropic / Responses — a rebuildReconstructed field by field. Anything without a slot is not carried.
The chat wire passes anything it is not told to strip. The Anthropic and Responses wires are rebuilt field by field, so a parameter with no slot in the target shape is simply not carried.

Widely Supported (most models)

tools / tool_choiceDescription · Function calling
response_formatDescription · JSON mode / structured outputs
frequency_penaltyDescription · Repetition reduction
presence_penaltyDescription · Topic diversity
logprobs / top_logprobsDescription · Token probabilities

Model-Specific

top_kModels · Anthropic, some open models
repetition_penaltyModels · Open models (Llama, Mistral)
min_pModels · Some open models
reasoning_effort / reasoningModels · Reasoning models only. See Reasoning Controls

Check supported_parameters on GET /v1/models for the resolved model before relying on any of these.

How It Works

On the chat wire, parameters are forwarded by a deny-list: anything that is not a credential, an SSRF vector, or money and tenancy truth is passed through as sent, so a brand-new provider knob reaches the wire without a change here. The Anthropic and Responses wires behave differently: both rebuild the request from a fixed set of fields, so a knob outside that set is dropped rather than forwarded. Unsupported params are silently ignored by most providers (the same behavior as OpenRouter).

Several things modify a request on the way out:

  1. A reviewed adapter policy removes or rewrites parameters a specific provider or model is known to reject. The reasoning-related rules are listed in Reasoning Controls.
  2. Reactive repair. When a provider returns a 4xx that names its own fix ("Unsupported parameter: 'stop'", "does not support 'max' with this model"), the marketplace can apply that fix and retry the same seller instead of failing you. This is gated by ADAPTER_REPAIR, which ships off; until an operator arms it the provider's error surfaces instead. model, messages, tools, tool_choice and response_format are protected from the generic strip, though a few narrowly-scoped rules do rewrite messages and tool_choice where a provider names them specifically.
  3. Prompt-cache injection, which can add a prompt_cache_key and Anthropic cache_control breakpoints.
  4. stream_options: {"include_usage": true}, auto-injected for metering on streaming chat requests.

Most of these are named in the X-SI-Adapted-Params response header, which is the best available record of what changed. It is not exhaustive: when you send no stream_options of your own the injection is deliberately silent, and fields dropped by an Anthropic or Responses wire rebuild are not itemised. (If you did send stream_options and it was overwritten, that one is disclosed.)

A provider 4xx the marketplace cannot interpret is returned to you as a 400. It does not automatically fail over to another seller.

Previous← Adapter policy contractsNextReasoning controls →