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.

The one exception is reasoning_effort: sending it to a model that doesn’t support reasoning returns a 400 rather than being dropped.

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. Supported levels vary by model — most offer a none level that disables reasoning entirely, and the levels in between are not directly comparable across model families.

Check default_parameters on the model for the levels it advertises, and treat reasoning output as billable — it counts toward output tokens.

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.