Model protocols and parameters
This reference follows model → protocol → parameter using the current market's public catalog. A display name can differ from the invocation ID. Free and paid variants have separate IDs. China and international catalogs are independent; a result in one market does not establish availability in the other.
Query the current model
Current market: International · Invocation IDs are listed separately and free status follows the catalog flag; the other market may expose different models and protocols.
OpenAI: GPT-6.1 Sol
Invocation model ID: gpt-6.1-sol · Not marked free
These endpoints come from the current public catalog configuration. Listing an endpoint does not establish parameter qualification. Minimal requests illustrate protocol structure and are not successful-call receipts.
| Protocol | Current catalog |
|---|---|
| OpenAI Chat Completions | Invocation endpoint declared |
| OpenAI Responses | Invocation endpoint declared |
| Anthropic Messages | Invocation endpoint declared |
OpenAI Chat Completions
POST /v1/chat/completions
No parameter guarantee is configured or declared. Parameter commitments for this model and protocol cannot be listed. This does not mean that every parameter is unsupported; do not infer support from another model or a vendor parameter table.
Cannot generate a verifiable invocation address: this protocol is missing a valid public Base URL or endpoint. Retry later.
OpenAI Responses
POST /v1/responses
No parameter guarantee is configured or declared. Parameter commitments for this model and protocol cannot be listed. This does not mean that every parameter is unsupported; do not infer support from another model or a vendor parameter table.
Cannot generate a verifiable invocation address: this protocol is missing a valid public Base URL or endpoint. Retry later.
Anthropic Messages
POST /v1/messages
No parameter guarantee is configured or declared. Parameter commitments for this model and protocol cannot be listed. This does not mean that every parameter is unsupported; do not infer support from another model or a vendor parameter table.
Cannot generate a verifiable invocation address: this protocol is missing a valid public Base URL or endpoint. Retry later.
Parameter lists and constraints come from current model configuration, rather than a vendor specification. No parameter guarantee configured or declared means that parameter commitments cannot currently be listed, not that every parameter is unsupported. A declared endpoint does not establish channel qualification. Select a model first, then its protocol; do not reuse another model's parameter table.
Request fields and structure
The table describes protocol structure and usage. Capability fields are only commitments when declared for the selected model and protocol. An undeclared default is not inferred.
| Protocol | Field | Type / required | Omission behavior and purpose | Structure and example |
|---|---|---|---|---|
| All three | model | string / required | Selects the invocation model; no default | Use the exact invocation ID above, including any free suffix |
| Chat Completions | messages | array / required | Supplies conversation history; no default history | [{"role":"user","content":"Hello"}]; text messages include role and content |
| Responses | input | string or array / required | Supplies text or explicit history; no default input | "Hello" or [{"role":"user","content":"Hello"}] |
| Messages | messages | array / required | Supplies user/assistant history; no default history | [{"role":"user","content":"Hello"}]; use separate system for system instructions |
| Chat / Messages | system message or system | string or content-block array in the protocol's format | Omission adds no explicit system instruction; hidden or vendor defaults are not guaranteed | Chat uses a system entry in messages; Messages uses the system field |
| Responses | instructions | string / optional | Instructions for this turn; does not establish stored history | "Answer concisely" |
| All three | stream | boolean / optional | Without streaming, returns a non-streaming response; true requests SSE | true; event format follows the selected protocol |
| Chat Completions | stream_options | object / optional | Controls streaming usage reporting, rather than generation | {"include_usage":true} |
| Messages | max_tokens | integer / explicitly supply in a protocol request | Output cap in tokens; no universal fixed default; consult the guarantee for bounds | A value such as 128 is usable only if the current declaration permits it |
Chat function tools use tools:[{"type":"function","function":{"name":"lookup","parameters":{"type":"object","properties":{}}}}]. Responses uses tools:[{"type":"function","name":"lookup","parameters":{"type":"object","properties":{}}}]. Messages uses tools:[{"name":"lookup","input_schema":{"type":"object","properties":{}}}]. These illustrate object shapes; they do not establish tool support for the current model. Tool names, schema profiles, item counts and subfield constraints follow its current guarantee.
range:[minimum,maximum] is an inclusive numeric interval; a null bound leaves that side unspecified. enum lists permitted values; const fixes a value; forbid_values excludes values; max_items caps array length; fields recursively constrains object subfields. schema_profile constrains tool JSON Schema shape and ttl lists cache TTL values. Missing bounds do not establish unlimited support, and a context window is not an output-token limit.
Purposes and combinations
Output caps use Chat's max_tokens / max_completion_tokens, Responses' max_output_tokens, or Messages' max_tokens, all in tokens. temperature and top_p control sampling. reasoning_effort, reasoning and thinking control reasoning. response_format, text.format and output_config.format control structured output. Only the current protocol declaration determines accepted fields, values and bounds.
| Rule | Meaning | Correction |
|---|---|---|
exclusive | The listed params cannot occur together | Keep one and remove conflicting fields |
requires | The first parameter requires every subsequent parameter | Add companions or remove the triggering field |
fixed_when | When when matches, the target parameter must equal value | Use that fixed value or change the triggering condition |
For example, {"temperature":0.5} illustrates a permitted value only if the selected model declares range [0,1]. If its rules also make temperature exclusive with top_p, omit top_p. This explains a hypothetical declaration and is not a commitment for any particular model.
Parameter errors and corrections
For models with enforced parameter admission, the gateway rejects unsupported capabilities and invalid constraints before an upstream invocation. Unconfigured, disabled and observation-only models do not automatically provide the same refusal behavior. An absent parameter table does not establish that enforcement is enabled.
| Error identifier | Meaning | Correction example |
|---|---|---|
unsupported_parameter | A capability is outside this model/protocol guarantee, or the platform does not provide it | Remove undeclared seed; change protocol only when the destination declares the capability |
unsupported_value | Invalid type, range, enum, object or array constraint | If the declared range is [0,1], change temperature:2 to 0.5; select enum values from the current table |
invalid_parameter_combination | An exclusive, dependency or conditional fixed-value rule was violated | If parallel_tool_calls requires tools, supply valid tools or remove parallel_tool_calls |
Chat and Responses return HTTP 400 in OpenAI form: error.type is invalid_request_error, error.code identifies the error, and error.param names the first affected field. Messages returns HTTP 400 in Anthropic error form with type invalid_request_error; its message retains parameter diagnostics. Do not assume it includes OpenAI's error.code. Fix the reported problem before retrying.
Responses capability boundaries
A Responses endpoint declaration does not establish every server-side state feature. previous_response_id history enrichment depends on an account-scoped temporary history cache (the current TTL is 24 hours), rather than permanent conversation storage. If history cannot be restored and input contains no earlier turn, the request returns 400; send full history explicitly in input. Keep the history your application needs instead of depending on temporary-cache availability.
Under enforced admission, background, conversation, prompt and hosted tools such as web_search, file_search and computer_use are not accepted as provided capabilities. The admission vocabulary classifies store and include as accepted but not guaranteed to be forwarded; they do not establish storage, retrieval, background tasks or cancellation. GET /v1/responses/{id} and cancellation are not listed as available endpoints here. An unconfigured model may retain older behavior; lack of an error does not prove the capability took effect.
Cache fields and usage
Cache markers are commitments only when declared for the current model and protocol. {"type":"ephemeral","ttl":"5m"} illustrates a cache_control object. 5m means five minutes and 1h means one hour; accepted values still follow current configuration. Acceptance does not establish a cache hit, TTL or cost; check the actual response and pricing.
| Protocol | Common protocol usage fields | ModelGo extensions and interpretation |
|---|---|---|
| Chat Completions | usage.prompt_tokens_details.cached_tokens | cached_creation_tokens is a ModelGo compatibility extension; do not assume it is a standard field accepted by every OpenAI client |
| Responses | usage.input_tokens_details.cached_tokens | A missing field does not establish zero cached tokens |
| Messages | usage.cache_read_input_tokens, usage.cache_creation_input_tokens | Do not add the write total to its 5m / 1h breakdown again |
Unreported cache usage differs from a reported 0. Models without the newer output behavior may retain older zero/omission handling, so one zero or missing field does not prove that the upstream reported zero cache usage. Reconcile visible call logs and billing. New output behavior is enabled per model, rather than assumed across models.