Model parameters

We serve open-weight models from many different developers. They do not all accept the same request parameters, and the platform does not paper over the difference.

Unsupported parameters are dropped silently

Each model declares the parameters it supports. A parameter that model doesn’t declare is removed before the request is forwarded — your request succeeds, and the parameter simply has no effect.

You will not get an error telling you the option was ignored. If a sampling setting appears to do nothing, this is the first thing to check.

Some things are rejected rather than dropped, and return a 400:

• reasoning_effort sent to a model that doesn’t support reasoning, or set to a value outside the accepted set (see Reasoning models).
• A content type the model doesn’t accept — an image part sent to a text-only model. Check architecture.input_modalities on the model.
• max_tokens (or max_completion_tokens) above the model’s max_completion_tokens ceiling.

The last two used to succeed and silently discard your input: an image sent to a text-only model returned 200 and an answer written from the text alone.

Checking what a model supports

Ask the API. The model detail endpoint returns the authoritative list:

curl -i "https://api.resetdata.ai/api/v1/models/detail?slug=zai/glm-5.2" \
  -H "Authorization: Bearer $RESETDATA_API_KEY"

Confirm you got a 200, then pipe the body through jq to pull out the fields you care about:

curl -s "https://api.resetdata.ai/api/v1/models/detail?slug=zai/glm-5.2" \
  -H "Authorization: Bearer $RESETDATA_API_KEY" \
  | jq '{supported_parameters, default_parameters, context_length, max_completion_tokens}'

A jq filter hides errors

If the request fails, the body is an error object — and jq will happily report every field you asked for as null, which looks like “the model has no parameters” rather than “the call failed”. Check the status with -i first when something looks wrong.

The most common cause is an unset variable: $RESETDATA_API_KEY expanding to nothing sends a malformed Authorization header and returns 401. Verify with echo "${RESETDATA_API_KEY:0:6}" — it should print sk-rd-.

supported_parameters is the allowlist. default_parameters shows what the model applies when you don’t specify a value.

The same fields appear on every entry in GET /api/v1/models, so you can audit your whole integration in one call.

How much this varies

Real differences across the current catalog:

Parameter	Availability
temperature, top_p, max_tokens, stream	Effectively universal on text models
top_k	Some models only
repetition_penalty	A minority of models
min_p	Rare — a couple of models
logprobs / top_logprobs	Rare
logit_bias	Rare
reasoning_effort	Reasoning models only — a small subset
detail	Vision models, for image input fidelity

Non-text models have entirely different vocabularies. Image models take steps, width, height, cfg_scale, seed. Embedding models take encoding_format, dimensions, input_type. Rerankers take top_n, return_documents. Transcription takes language and response_format.

Tool calling

There is no single “supports tools” flag — tool calling is available exactly when tools and tool_choice appear in supported_parameters. The app shows a Function-calling badge derived from the same check.

Tool support is genuinely not universal in this catalog. Several capable text models, and all image, audio, embedding and reranker models, do not offer it. Verify before designing an agent loop around a given model.

Reasoning models

Models that support reasoning_effort accept an effort level that trades latency and token spend against answer quality.

reasoning_effort accepts one of seven values:

none  minimal  low  medium  high  xhigh  max

This is a unified set. Reasoning models do not all implement seven levels — most implement two or three — so the platform maps your value onto the levels the model actually has, following that model’s own published documentation. Two consequences worth planning around:

• Distinct values can behave identically. On a model with three native levels, several of the seven collapse onto the same one. Asking for medium instead of high may change nothing at all.
• Levels are not comparable across model families. high on one model is not high on another. Treat effort as a per-model dial you tune, not a portable setting you copy between models.

To see what a given model offers, read default_parameters from the model detail endpoint. Models that declare distinct effort levels expose them as reasoning_effort_levels:

curl -s "https://api.resetdata.ai/api/v1/models/detail?slug=deepseek/deepseek-v4-flash" \
  -H "Authorization: Bearer $RESETDATA_API_KEY" \
  | jq '.default_parameters'

Not every reasoning model declares the list. When reasoning_effort_levels is absent, the model accepts the full set above but the mapping onto its native levels is not published — assume fewer distinct levels than you sent, and measure rather than trusting the label.

Values outside the seven are rejected with a 400 naming the accepted set. This matters more than it sounds: reasoning_effort is case-sensitive, so "HIGH" is not "high" and will be rejected rather than quietly ignored.

Reasoning tokens share your max_tokens budget

Reasoning tokens count toward output tokens — they are billed, and they are drawn from the same max_tokens budget as the answer. A hard prompt at a high effort level can spend 20,000+ tokens thinking.

If max_tokens is too small, reasoning consumes all of it and you get finish_reason: "length" with empty content. When you set max_tokens yourself on a reasoning model, budget for the thinking as well as the answer.

On some models a higher level also prepends instructions to your prompt, which adds input tokens and invalidates the prefix cache — so changing effort mid-conversation costs more than holding it steady.

Reasoning by default

Whether a model reasons when you omit reasoning_effort varies by model — and some models reason by default at a high effort level. Where a model declares one, reasoning_effort_default names the level used when you leave the field out:

curl -s "https://api.resetdata.ai/api/v1/models/detail?slug=deepseek/deepseek-v4-flash" \
  -H "Authorization: Bearer $RESETDATA_API_KEY" \
  | jq '.default_parameters.reasoning_effort_default'

When it is absent, the upstream model’s own default applies.

DeepSeek V4 Flash declares high, matching api.deepseek.com, which reasons by default. Omitting reasoning_effort on that model therefore produces reasoning tokens — and those are billed as output tokens.

Omitting the field is not the same as turning reasoning off

If you want a non-reasoning response, send reasoning_effort: "none" explicitly. Leaving the field out gives you the model’s default, which may be reasoning at high effort.

Changing reasoning effort can cost you the prompt cache

On some models the effort level is rendered into the prompt itself, very close to the start. Changing it between requests therefore changes the prefix and can invalidate the cache for the whole conversation, turning cached input into full-price input. Pick a level per workload and keep it stable.

Context and output limits

context_length is the total window (input plus output). max_completion_tokens is the ceiling on a single response, and is often much smaller than the context window — these are separate limits and both are per-model.

Switching models safely

When moving an integration from one model to another:

1. Diff supported_parameters between the two.
2. Check max_completion_tokens — output caps vary far more than context windows.
3. Confirm tools / tool_choice if you rely on function calling.
4. Re-check pricing; input and output rates differ independently between models.
5. Re-tune sampling. Identical settings do not produce identical behaviour across model families.