Supported parameters
Understand request validation and endpoint-specific parameter support.
Accepted request fields
| Category | Fields |
|---|---|
| Conversation and routing | model, models, messages, provider, route, cyber |
| Output and streaming | stream, stream_options, max_tokens, max_completion_tokens, n |
| Sampling | temperature, top_p, top_k, min_p, top_a, stop, seed, frequency_penalty, presence_penalty, repetition_penalty |
| Output controls | response_format, logit_bias, logprobs, top_logprobs, prediction |
| Client tools | tools, tool_choice, parallel_tool_calls |
| Reasoning | reasoning, reasoning_effort |
| Other accepted fields | user, session_id, metadata, service_tier, safety_identifier, prompt_cache_key |
Accepted does not mean every endpoint supports it
Each provider has its own capabilities and fixed-parameter constraints. The gateway adapts the request and reports ignored fields in cyberrouter.dropped_params. To require support, set provider.require_parameters: true; no eligible endpoint may remain.
Check model endpoint details before relying on tool calling, structured output, reasoning options, or sampling parameters. Sending tool definitions does not give CyberRouter permission to execute your client’s tools.
Unsupported fields
Unknown top-level fields produce 400 invalid_request. These fields are explicitly unsupported:
| Field | What to use instead |
|---|---|
| prompt | Supply role-based messages. |
| transforms | Manage context in your application; automatic middle-out truncation is not supported. |
| plugins | OpenRouter plugins are not part of CyberRouter’s public API. |
Provider preference fields are also validated. Copying an example from another router does not make its features available here; use the CyberRouter guides for accepted options.