Provider capability and compatibility

Use this reference when you configure or review a model route. It lists the route fields and provider limits that affect structured answers, context caching, images, reasoning, and token counts. Understand model routing explains how those choices affect route selection and attempts.

A model identifier proves none of these capabilities. The route configuration makes the claim, and Duale AI does not test that claim against the provider. When the application sends a response schema, Duale AI still validates every answer against it. A false claim can therefore spend calls and time; it does not relax correctness.

Declare each feature on the route

Declare each feature under Capabilities Override -> Enabled Features. The field accepts six values. Four change provider behavior or cost:

Declaring tools or function_calling has no effect. Tool definitions reach every route whether you declare these values or not. Control tool use through the agent’s registered tools. A benchmark category also uses the name function_calling; it is a different field. Image input is not in this list either: declare it under Image Support.

Only Anthropic, AWS Bedrock, OpenAI Responses, and Microsoft Foundry send a cache control or key to the provider. On the other nine provider types, declaring context_caching can change only the cost Duale AI estimates for the route. It sends no cache signal, so the estimate is not evidence of a provider cache hit.

Give every route that declares context_caching a cached-input price. Without one, Duale AI cannot estimate what the route costs, so a task that raises cost_sensitivity prefers other routes and this one can go unused.

States of the declared feature list

The saved value controls the declared feature set as follows:

Name streaming in any list you save whenever you want streaming: only an absent field gets the default. In the Dashboard, clearing every entry saves an empty list; select Not set to make the field absent again.

Check what each provider type enforces

Before you rely on a typed result, check whether the active provider type enforces the response schema:

Provider enforcement can improve first-answer reliability. Duale AI validates the final result on every route.

Do not declare structured_output on a Z.ai, DashScope Qwen, AWS Bedrock, or Vertex AI route. These provider types cannot enforce a response schema. Duale AI adds the schema as a prompt instruction regardless of that declaration; leaving the feature off keeps the route’s claim accurate.

OpenAI-compatible endpoint switches

Three default to off, so an endpoint that accepts more than the default needs an explicit change. Streaming Usage Options defaults to on, so an endpoint that rejects the usage option needs an explicit change instead.

Together AI applies that same one-call-at-a-time rule under a strict schema, and has no switch to change it.

Verify a declaration against measured behavior

A declaration is a claim until traffic tests it. To check one:

1. Enable the route on its own in an evaluation tenant.
2. Submit work that represents the workload, using the same response schema and tools as production.
3. Open Settings -> LLM Providers -> Performance and read that route’s Structured-output errors, Tool-call errors, and Provider cache hits.

A structured-output error means that one attempt did not produce a valid answer. Compare the rate with your evaluation evidence before you accept the route for this workload. Provider cache hits show whether a context_caching declaration is earning the cached-input rate you priced it at.

The Performance view covers first attempts on enabled routes, so read it as evidence about the route you selected, not as a record of what happened after a failover.

Give a response schema a shape a provider can enforce

When a route sends your response schema through a provider’s structured-output interface, Duale AI first removes keywords that some interfaces reject. The provider does not receive these keywords as schema constraints:

• numeric bounds and multipleOf;
• string length, pattern, and format;
• item counts and uniqueness;
• object property counts, patternProperties, and propertyNames;
• default and discriminator.

Duale AI applies these rules when it validates or builds the application result after the answer returns. A limit violation spends an attempt; it does not become accepted output.

Write the response model your application sends to these rules:

• Restate a limit in the field description. The description survives. A maximum length does not, so the model never sees the limit, and the answer fails validation only after the provider returns it.
• Name every property in the object’s required list. On provider paths that send a strict flag, one missing property turns strict mode off for the whole request.
• Give every object named properties. On those same paths, a free-form or key-value map turns strict mode off for the whole request.

If one object fails either structural rule, Duale AI sends the schema without strict mode on provider paths that use a strict flag. It does not raise a configuration error. Both models below omit their imports, which are the Pydantic ones shown in Integrate model routing in an application:

# Strict mode is off for the entire request: `metadata` has no named properties.
class ReviewResult(BaseModel):
    decision: Literal["manual_review", "reject"]
    metadata: dict[str, str]


# Strict mode stays on: every object names its properties, and every property is required.
class ReviewMetadata(BaseModel):
    model_config = ConfigDict(extra="forbid")

    reviewer_queue: str
    source_system: str


class ReviewResult(BaseModel):
    model_config = ConfigDict(extra="forbid")

    decision: Literal["manual_review", "reject"]
    metadata: ReviewMetadata

On an Anthropic route, Duale AI sends the sanitized schema without a separate strict-mode switch. The provider enforces that schema. The two strict-mode rules above do not control this path, but the description rule still restores limits that Duale AI removed.

The same keyword removal applies to a tool’s parameter schema on three provider types. These are OpenAI-compatible Chat Completions with Strict Structured Responses, Together AI, and DashScope Qwen. The other provider types send it unchanged.

Declare image support separately

Image support is a route contract for images inside Library document tool results. It does not accept images as direct request input. For one of those tool-result images to reach the model, the route must satisfy two conditions.

Check whether the route can carry an image

Both checks must pass before an image can reach the model:

• The route carries an Image Support profile. Absent means no image is ever sent to that model.
• The provider type can carry an image inside a tool result. Only Anthropic, AWS Bedrock, and OpenAI Responses can. Microsoft Foundry cannot, although it uses the same request shape.

These conditions also affect route choice. When at least one route can carry at least one image, Duale AI uses only routes that can carry at least one. When no route can, all routes remain available and every image is dropped.

The Image Support form appears on every provider type. You can therefore save a profile on a route that cannot receive an image. A saved profile alone does not prove transport support.

Set the image profile and budget

The profile needs three values: images per request, bytes per image, and the largest width or height in pixels. The form accepts 1 to 1,000 images, up to 128 MiB per image, and up to 65,535 px. No provider type tightens the pixel value, so an over-size image is dropped on your value alone. Enter all three from the same measured source.

Duale AI applies its own ceilings on top of your profile. A ceiling can only tighten your values, never raise them:

Read the table with two limits in mind:

• The OpenAI Responses count of 1,000 is the profile maximum. The provider type declares 1,500, which never binds because the form stops at 1,000.
• A Request ceiling counts the whole request, not only its images. A long conversation leaves less room for images on the same call.

One more ceiling applies on every provider type and is not in the table: about 42.9 MiB of image files in one request. Above it, Duale AI drops images until the request fits. On an OpenAI Responses route this is the only ceiling beyond your profile, so enter measured provider limits there.

An OpenAI Responses route also carries Image Detail. low sends every image at a fixed low resolution. auto and high both send full-resolution tiling.

Budget an image-heavy workload on input tokens, not on file size. One image costs 256 input tokens on an OpenAI Responses route set to low. It costs up to 6,150 on the same route set to auto or high, and up to 4,784 on an Anthropic route.

Recover when an image is dropped

Duale AI can return a successful answer from text after it drops an image. It drops an image when the image is:

• over the profile or provider count, byte, or dimension limit;
• over the provider request ceiling or the shared transit ceiling;
• unreadable at its source;
• with too little of the deadline left to fetch it and still answer.

Above 20 images on an Anthropic route, each image over the tightened long edge is dropped rather than made smaller.

What the model reads in place of the image depends on the route:

• On a route that can carry images, Duale AI marks the gap where the image was, so the model can tell you an image is missing. Text derived from that image, such as recognized characters or a caption, is dropped with it. Text extracted from the document itself stays.
• On a route that cannot carry images, the tool result reads to the model as though the image were present. Nothing marks the gap.

Ask for a value that only the image carries and check it against a source outside the model. To restore a dropped image, bring it under the ceilings. Read it at a lower resolution, or split a document that exceeds the count or request ceiling across several requests.

Set reasoning depth on the route

Reasoning depth is a route setting. A request cannot override it. Each provider type has its own field and levels:

Reasoning also changes sampling behavior on two provider types. An Anthropic route ignores temperature and top-p. An AWS Bedrock route ignores both when you set a thinking budget.

The levels differ between provider types, so the same word does not mean the same depth on two routes. Set an absolute task deadline that the slowest configured route can meet.

On an Anthropic or AWS Bedrock route, reasoning and a forced tool call do not combine. With reasoning on, the model can answer in text instead of calling a tool, even when your workflow expects one.

Two combinations save without error and then fail every request that reaches the route:

• An Anthropic route sets both a thinking budget and adaptive thinking. Remove one of them.
• An AWS Bedrock route sets a thinking budget that is not below the requested maximum output tokens. Lower the thinking budget or raise the maximum output tokens.

Choose the token encoding that matches the model

tokenizer_encoding defaults to cl100k_base on every provider type, which is wrong for most model families. Select the value that matches the model from the encodings the route form offers.

An encoding that does not match the model makes Duale AI count a conversation incorrectly. If the count is too low, a long conversation can overflow the model’s context window during the call. If the count is too high, Duale AI trims the conversation too early. The mismatch also makes the reported token figures less accurate. Changing the encoding discards the route’s measured latency, like every other field that shapes a request.

Change a declaration under production control

Route declarations are production configuration because they change provider requests, cost estimates, or route suitability. Duale AI measures route latency from real traffic, and most edits discard that measurement. Until traffic rebuilds it, speed_preference gives the route no advantage. Re-test a changed route before you use it for a latency-sensitive workload.

Changing a declaration requires config:update_config. Ownership and approvals maps the configuration actions.

A preset owns each field it declares, and it replaces the whole declared feature list rather than merging it. A preset that ships no Image Support profile leaves that field yours. Govern a preset change through Control model changes.

Record the provider document and the date you checked it beside each declaration in your own change system. Duale AI stores the declaration, not its evidence.

Two checks before you enable a pool

Any enabled route can run any request that reaches its tenant. Two checks belong to this page:

• No route declares a feature its provider type cannot perform, and every route that can serve a schema-bound workload either sends the schema or receives it as a prompt instruction.
• Every route intended for image work has both an Image Support profile and a provider type that carries images.

Plan the deployment and model portfolio covers creating a route and the remaining checks before approval. Verify a pool by testing outcomes on each route, as Integrate model routing in an application describes.