> ## Documentation Index
> Fetch the complete documentation index at: https://docs.asterwise.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Parameters and model compatibility

> Choose supported generation controls and use the correct names for each API endpoint.

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.

| Control                | Chat Completions                                                        | Responses                                    | Messages                                           |
| ---------------------- | ----------------------------------------------------------------------- | -------------------------------------------- | -------------------------------------------------- |
| Reasoning effort       | `reasoning_effort` (string)                                             | `reasoning.effort` (string inside an object) | `output_config.effort` (string inside an object)   |
| Thinking configuration | Route-specific `reasoning` object; prefer `reasoning_effort` for effort | `reasoning` object                           | `thinking` object                                  |
| Sampling temperature   | `temperature` (number)                                                  | `temperature` (number)                       | `temperature` (number)                             |
| Nucleus sampling       | `top_p` (number)                                                        | `top_p` (number)                             | `top_p` (number)                                   |
| Frequency penalty      | `frequency_penalty` (number)                                            | —                                            | —                                                  |
| Presence penalty       | `presence_penalty` (number)                                             | —                                            | —                                                  |
| Output-token cap       | `max_completion_tokens` or `max_tokens` (positive integer)              | `max_output_tokens` (positive integer)       | `max_tokens` (positive integer)                    |
| Tool definitions       | `tools` (array of function definitions)                                 | `tools` (array of function definitions)      | `tools` (array of named tools with `input_schema`) |
| Tool selection         | `tool_choice` (string or object)                                        | `tool_choice` (string or object)             | `tool_choice` (object)                             |
| Streaming              | `stream` (boolean)                                                      | `stream` (boolean)                           | `stream` (boolean)                                 |

See the [Chat Completions](/api/chat-completions), [Responses](/api/responses), and [Messages](/api/messages) guides for complete request examples.

## Reasoning names and effort levels

These are endpoint-specific shapes, not interchangeable aliases:

```json Chat Completions theme={"dark"}
{"reasoning_effort": "low"}
```

```json Responses theme={"dark"}
{"reasoning": {"effort": "low"}}
```

```json Messages theme={"dark"}
{"output_config": {"effort": "low"}}
```

| Public model | Baseline effort levels                      |
| ------------ | ------------------------------------------- |
| `aster-code` | `low`, `high`                               |
| `aster-work` | `minimal`, `low`, `medium`, `high`, `xhigh` |

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](/pricing-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.

| Selection      | Chat Completions                                   | Responses                             | Messages                          | Baseline availability |
| -------------- | -------------------------------------------------- | ------------------------------------- | --------------------------------- | --------------------- |
| Automatic      | `"auto"`                                           | `"auto"`                              | `{"type":"auto"}`                 | Code and Work         |
| No tool        | `"none"`                                           | `"none"`                              | `{"type":"none"}`                 | Code                  |
| Named tool     | `{"type":"function","function":{"name":"lookup"}}` | `{"type":"function","name":"lookup"}` | `{"type":"tool","name":"lookup"}` | Code                  |
| Require a tool | `"required"`                                       | `"required"`                          | `{"type":"any"}`                  | Neither baseline      |

`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.

| Parameter                     | Current behavior                                                                                                                              |
| ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `top_k`                       | Recognized only on Messages; no current route advertises it.                                                                                  |
| `min_p`, `repetition_penalty` | Unknown top-level fields on all three endpoints.                                                                                              |
| `stop` / `stop_sequences`     | `stop` is recognized on Chat Completions and `stop_sequences` on Messages, but no current route advertises either. Responses accepts neither. |
| `logit_bias`                  | Recognized on Chat Completions; no current route advertises it.                                                                               |
| `logprobs`, `top_logprobs`    | Recognized on Chat Completions; no current route advertises them.                                                                             |
| `response_format`             | Recognized on Chat Completions; no current route advertises it. Responses formatting via `text` is also not currently available.              |
| `seed`                        | Recognized on Chat Completions; no current route advertises it. Deterministic sampling is not promised.                                       |

## 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](/errors-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.