Core API

Parameters

Understand which request fields the gateway adds, aliases, or passes through.

On this page

This page is for developers tuning generation behavior while keeping model-specific differences explicit.

Most JSON request fields are forwarded unchanged. Support, ranges, and defaults therefore depend on the selected model and upstream implementation.

On OpenAI-compatible endpoints, model can be a complete author/model ID or an exact bare alias. The gateway resolves known aliases and treats an unknown bare name as openai/<name>; the response model field shows the resolved full ID. Prefer full IDs in production. Variants such as :free and :batch must always be written as complete IDs.

Common parameters#

FieldTypical typeGateway behaviorAll models?
temperaturenumberPassed through.no
max_tokensintegerPassed through.no
top_pnumberPassed through.no
stopstring or arrayPassed through.no
toolsarrayPassed through.no
tool_choicestring or objectPassed through.no
reasoningobjectPassed through.no
reasoning_effortstringPassed through.no
stream_optionsobjectSupplied only when streaming chat and the client omits it.chat only
userstringSupplied with an internal identifier derived from the key when the client omits it.OpenAI-compatible JSON requests

Unknown fields are not validated or discarded by the gateway. The upstream API can accept, ignore, or reject them. Use the current model catalog metadata as a guide, then run a bounded test with the exact model and field set.

If you do not pass user, the gateway injects an internal identifier derived from your key; pass your own user to control what appears in /v1/responses echoes.

Generation controls#

JSONSyntax highlighted
{
  "model": "openai/gpt-5.4-nano",
  "messages": [{"role": "user", "content": "Return one short sentence."}],
  "temperature": 0.2,
  "max_tokens": 80
}

Reasoning fields are passed through. When usage identifies reasoning or thinking tokens, billing treats them as output tokens.

JSONSyntax highlighted
{
  "model": "openai/gpt-5.4-nano",
  "messages": [{"role": "user", "content": "Explain the result briefly."}],
  "reasoning_effort": "low"
}

Verify support#

Open Models, select the exact callable ID, and inspect its supported-parameter metadata when available. Treat metadata as guidance and the actual response as decisive. A 4xx from the upstream API can mean the model rejected a forwarded field.

Common mistakes#

  • Do not assume a parameter works for every model because the gateway forwards it.
  • Include /v1 in the OpenAI SDK base URL and omit it from the Anthropic SDK base URL.
  • Never enable browser SDK execution; it exposes the key to every visitor.
  • Prefer complete model IDs in production, audit bare-name resolution in the response model field, and keep :free or :batch in the complete ID.
  • Check empty streaming choices arrays.
  • Use cf-ray for inference tracing.

Also available (pass-through, lightly tested)#

Structured output fields are forwarded unchanged for models that accept them. Validate the exact schema and model together.

JSONSyntax highlighted
{
  "model": "openai/gpt-5.4-nano",
  "messages": [{"role": "user", "content": "Return JSON with an ok boolean."}],
  "response_format": {"type": "json_object"}
}
Need a hand?

Find answers to common questions or diagnose a failed request.

Frequently asked questions →Troubleshoot errors →