Model Capabilities

Model capabilities differ even when models share an API endpoint. The model detail page and public model schema are the source of truth for the selected model.

Read the model page before integrating

Check these fields:

• Input and output modality — text, image, audio, or video.
• Context and output limits — maximum input and generated output where published.
• Supported parameters — fields accepted by the model and their allowed ranges or enum values.
• Pricing rules — billing meters such as tokens, images, characters, or seconds.
• Examples — request bodies generated from the same public parameter schema used by the Playground.

The live catalog can also be queried through GET /public/models. Do not hardcode a capability based only on the provider family name.

Tool and function calling

For models that advertise tool support:

1. Send tool definitions in tools.
2. Execute the returned tool call in your application.
3. Append the complete assistant tool-call message to history.
4. Append the tool result with the matching call ID.
5. Send the updated history to obtain the final model response.

Preserve tool-call IDs and arguments exactly. A normal stop finish reason and a tool-call finish reason are different application states. If the model page does not list tool support, do not assume that the router will emulate it.

Structured output

Models that support response_format can return JSON objects or JSON Schema-constrained output. Validate the final payload in your application even when strict structured output is enabled.

For streaming, buffer the complete JSON value before parsing it. Individual deltas are fragments and may not be valid JSON by themselves.

Reasoning models

Reasoning fields, effort controls, summaries, and token accounting vary by model and protocol. When continuing a conversation:

• retain the complete assistant response fields required by the protocol;
• pass them back without renaming provider-defined wire fields;
• do not expose hidden reasoning to end users unless the response contract explicitly marks content as displayable;
• include reasoning tokens when estimating cost if the model prices them as output.

Multimodal inputs

Depending on the selected model, input can include URLs, Base64 data, uploaded files, or Token360 asset references. Confirm all of the following on the model page:

• accepted MIME types and file limits;
• whether remote URLs must be public and HTTPS;
• whether an image slot accepts one item or multiple references;
• whether an asset:// reference requires a particular asset-group type;
• whether signed output URLs expire.

Real Face and Virtual Portrait have additional identity, provider, and asset-state requirements. Follow their dedicated guides.

Streaming

Streaming support is endpoint- and model-specific. Applications must handle:

• content deltas;
• tool-call or reasoning deltas when supported;
• a final finish reason;
• final usage when returned;
• an error event or connection close before [DONE].

Treat an interrupted stream as failed unless your application can safely retain a partial result.

Capability validation checklist

Before moving a model into production, test the exact public model name with:

• the smallest valid request;
• every special parameter you plan to use;
• an invalid value to verify error handling;
• streaming and non-streaming, if applicable;
• tool calls or structured output, if applicable;
• a second turn containing the original assistant fields;
• the expected usage and billing fields.