Chat completions

The main inference endpoint on the Public Free Model APIs. It follows OpenAI’s chat completions schema. A dedicated endpoint serves the same path from your own vLLM or SGLang, and none of the request filtering below applies there.

POST /v1/chat/completions Bearer key or session

Also reachable at /api/v1/chat/completions — the two paths are the same endpoint.

Request

Parameter	Type		Description
model	string	Required	Model to run. Must be one returned by GET /v1/models.
messages	array	Required	Conversation so far. Each item has a role (system, user, assistant, or tool) and content. Where a system message may sit differs per model — see below.
stream	boolean	Optional	Stream the response as server-sent events. Defaults to false.
temperature	number	Optional	Sampling temperature. Higher is more random.
top_p	number	Optional	Nucleus sampling threshold.
max_tokens	integer	Optional	Cap on tokens generated in the response.
presence_penalty	number	Optional	Penalises tokens already present.
frequency_penalty	number	Optional	Penalises tokens by how often they’ve appeared.
response_format	object	Optional	{"type": "json_object"} or a json_schema, on models where json_output is true.
tools	array	Optional	Tool definitions, if the model supports tool calling.
tool_choice	string or object	Optional	Which tool the model may or must call.
reasoning_effort	string	Optional	Controls thinking length. Accepted tiers vary per model — see the table below; low and medium work everywhere. Whether omitting it disables thinking also varies per model.
reasoning.effort	string	Optional	Same thing, unified form. Cannot be combined with reasoning_effort.

messages: roles and system-message placement differ per model

The accepted role set is system, user, assistant, tool. developer — the role newer OpenAI SDKs emit in place of system — is not accepted by every model, and neither is a system message anywhere other than first.

messages shape	DeepSeek-V4-Flash	Qwen3.8-Flash-Next
system first, then user	200	200
system after a user turn	200	400
system last	200	400
two system (first + middle)	200	400
developer in place of system	200	422

For one code path across both models: send at most one system message, put it first, and use system rather than developer. Per-model detail and the exact error strings are on the model reference pages.

How to turn thinking on

On this endpoint, reasoning_effort (or the equivalent reasoning.effort) is the only way to enable thinking.

{
  "model": "DeepSeek-V4-Flash",
  "reasoning_effort": "high",
  "messages": [{ "role": "user", "content": "..." }]
}

The thinking text comes back in choices[0].message.reasoning (not reasoning_content). For the token count use usage.completion_tokens_details.reasoning_tokens — every model reports it. The top-level usage.reasoning_tokens is only emitted by some models (DeepSeek-V4-Flash has it, Qwen3.8-Flash-Next does not), so do not rely on it.

Omitting reasoning_effort does not mean no thinking. The default differs per model:

Model	When omitted
DeepSeek-V4-Flash	Does not think (reasoning empty, reasoning_tokens 0)
Qwen3.8-Flash-Next	Still thinks — the default tier is xhigh, the longest one

Pass the value explicitly if you want deterministic behaviour; send low to make Qwen3.8-Flash-Next think less.

Which tiers a model accepts differs per model. An unsupported value is rejected, but with one of two status codes — validation happens in two layers, so do not catch only 400:

Status	Layer	Looks like
400	Model	Unexpected reasoning effort high. Supported types are xhigh (default), medium, and low.
422	Request-body deserialisation	Failed to deserialize the JSON body into the target type: reasoning_effort: unknown variant 'max', expected one of 'low', 'medium', 'high'

Tier	DeepSeek-V4-Flash	Qwen3.8-Flash-Next	GLM-5.2
minimal	✅	❌	❌
low	✅	✅	✅
medium	✅	✅	✅
high	✅	❌	✅
xhigh	✅	❌	❌
max	✅	❌	❌

For one code path across all models, stick to low and medium — those are the only two every model accepts.

There are also fewer effective tiers than enum values: on DeepSeek-V4-Flash, minimal/low/medium think about the same amount, while high/max think noticeably longer — two tiers in practice.

Do not use thinking — it has no effect

Some clients (Anthropic-flavored ones in particular) send thinking: {"type": "enabled", "budget_tokens": N} to enable thinking. This endpoint does not support it, and the serving backend has no notion of a token budget for thinking either.

thinking and reasoning.enabled now return 400, with the error naming the parameter that does work:

{
  "error": {
    "message": "\"thinking\" is not supported on /v1/chat/completions and was not applied. Use \"reasoning_effort\" (or \"reasoning.effort\") to control thinking.",
    "type": "invalid_request_error",
    "code": "unsupported_parameter"
  }
}

An error beats a silent drop: these requests used to return 200 with no thinking at all, which is hard for a caller to notice.

If you must speak Anthropic, the working control on POST /v1/messages is output_config: {"effort": "high"}; thinking is rejected there too.

Unlisted parameters are dropped, not forwarded

The request is validated against the schema above and then rebuilt field by field before it reaches the serving backend. Anything outside the accepted set is removed silently — no error, no effect.

That includes some parameters an OpenAI or vLLM client would reasonably expect to work: stop, seed, logit_bias, logprobs, top_logprobs, top_k, min_p, and repetition_penalty. If you need any of them, run a dedicated endpoint, which passes your body straight to vLLM or SGLang.

Example

curl https://developer.amd.com.cn/radeon/api/v1/chat/completions \
  -H "Authorization: Bearer $RADEON_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "DeepSeek-V4-Flash",
    "messages": [
      {"role": "system", "content": "You are a concise assistant."},
      {"role": "user", "content": "What is ROCm?"}
    ],
    "temperature": 0.7,
    "max_tokens": 256
  }'

Response

{
  "id": "chatcmpl-8f3b21d0",
  "object": "chat.completion",
  "created": 1756108800,
  "model": "DeepSeek-V4-Flash",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "ROCm is AMD's open software platform for GPU computing..."
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 24,
    "completion_tokens": 118,
    "total_tokens": 142
  }
}

finish_reason is stop when the model finished on its own, length when it hit max_tokens, and tool_calls when it wants a tool invoked.

Reasoning models add reasoning_tokens to usage, and a prompt-cache hit adds usage.prompt_tokens_details.cached_tokens.

Streaming

Set stream: true to receive server-sent events. Each event carries a delta rather than the whole message, and the stream ends with data: [DONE].

from openai import OpenAI

client = OpenAI(
    base_url="https://developer.amd.com.cn/radeon/api/v1",
    api_key="rc-...",
)

stream = client.chat.completions.create(
    model="DeepSeek-V4-Flash",
    messages=[{"role": "user", "content": "Explain ROCm in two sentences."}],
    stream=True,
)

for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

Streaming responses aren’t buffered by the platform, so tokens arrive as the model produces them.

Timeouts

A non-streaming request can take up to 10 minutes before the platform gives up. When streaming, the same 10 minutes applies to the gap between chunks rather than to the whole generation. Long generations should stream, both so you see progress and so the connection stays active.

Errors

401 invalid key. 429 rate limited — see Rate limits. 502 or 503 the backend is unreachable or saturated; retry with backoff.

A model name that isn’t in the catalog is rejected by the gateway with 400 and Requested model <name> not supported — the request never reaches a backend. Errors the model itself raises, such as a context-length overflow, are passed through with the backend’s own status and message. See Errors for the response shapes.