Skip to main content
Your application or coding harness supplies optional generation controls in the JSON request body. Use the names for the endpoint you call. AsterWise checks both the request shape and the capabilities of eligible model routes; a field recognized by the parser is not necessarily available for generation. This reference covers the current Code and Work baseline routes. Additional controls can reduce fallback eligibility. It does not promise every upstream API feature or every combination of settings.

​
Supported controls by endpoint

All controls below are optional. A dash means that field is unavailable on that endpoint. See the Chat Completions, Responses, and Messages guides for complete request examples.

​
Reasoning names and effort levels

These are endpoint-specific shapes, not interchangeable aliases:
Chat Completions
Responses
Messages
Use low or high when you need an effort value supported by both baselines. Values are case-sensitive. A recognized value such as none or max is not a baseline capability merely because the request parser recognizes it. Fallback-specific capabilities are not a guarantee for the public model. thinking configures Messages thinking behavior; output_config.effort selects effort. They are distinct controls. A thinking token budget, when supported by the route, is also different from an effort level and from the total output cap. AsterWise does not offer a universal reasoning map with interchangeable enabled, max_tokens, exclude, and effort controls. Do not copy that shape from another gateway or assume arbitrary nested fields are supported. For manual integrations, use the effort examples above. Preserve a qualified harness’s native thinking settings and signed/encrypted reasoning items when continuing its conversation. Replaying opaque reasoning can restrict the request to its original provider, model, and protocol.

​
Defaults and output limits

  • stream defaults to false.
  • If you omit the output cap, the gateway uses the model’s published output limit, bounded by its runtime maximum. Set an explicit cap to control each request’s output allowance.
  • Current public output ceilings are 65,536 tokens for Code and 32,768 for Work. Output accounting includes provider-reported reasoning tokens; these ceilings are not an extra allowance for visible answer text.
  • Chat Completions accepts either max_tokens or max_completion_tokens, never both.
  • AsterWise does not insert universal defaults such as temperature: 1, top_p: 1, or penalties of 0. Omitted sampling and effort settings follow downstream runtime/model behavior.
See pricing and limits. A cap is an upper bound, not a promise that the model will generate that many tokens.

​
Tools and tool choice

Tool definitions follow the endpoint’s native shape. AsterWise returns tool requests; your application executes the tool and sends its result with the matching call ID and conversation history. Provider-hosted tools such as built-in web search are not supported. parallel_tool_calls is available on eligible Chat Completions and Responses baseline routes. The corresponding Messages field, tool_choice.disable_parallel_tool_use, is recognized but requires an additional capability that current routes do not advertise; omit it in manual requests. DeepSeek fallback does not provide the same parallel-tool capability. A request’s complete set of controls determines which routes remain eligible.

​
Sampling on DeepSeek fallback

On the DeepSeek thinking fallback, valid temperature, top_p, frequency_penalty, and presence_penalty settings are accepted as no-ops. AsterWise removes those four controls from the outbound request; they do not tune generation there. This exception applies only with default enabled thinking or supported thinking efforts (low, high, max). It does not apply to disabled thinking, none, or malformed values. If your workflow depends on exact sampling behavior, do not assume it remains identical across a fallback. Other unsupported controls are not silently dropped under this exception.

​
Currently unavailable controls

These are not customer-supported controls on the current routes, even where the endpoint recognizes their names.

​
Validation and continuation

An unknown top-level field produces unsupported_native_field. Invalid effort values produce invalid_reasoning_effort; recognized but unavailable efforts instead fail route eligibility. Unsupported tool selection can produce unsupported_tool_choice; incompatible control combinations can produce no_compatible_baseline. The exact error depends on the entire request. Output-cap errors include conflicting_output_limits, invalid_output_limit, and unsupported_output_limit. Correct the request before retrying. In streaming mode, capability failures can arrive in the stream after HTTP headers; HTTP 200 alone does not establish success. See errors and fallback. Send conversation history on each request. Non-null previous_response_id and conversation values are rejected with continuation_requires_explicit_history. Remote storage, background execution, and automatic truncation are not supported. No session_id is required; a top-level session_id is not an accepted field.