Catalog

Capabilities

Models differ in what they accept. Here is what each capability changes about your request — and what happens when you exceed it.

Capability flags

Field	Type	Description
`vision`	boolean	Accepts images. See Vision.
`tools`	boolean	Supports function calling. See Tool calling.
`reasoning`	boolean	Can spend extra tokens thinking. See Reasoning.
`context window`	number	Maximum tokens for input and output combined.
`max output`	number	Upper bound on a single response.

Context window#

The window covers input and output. A 200,000-token window with 190,000 tokens of input leaves room for a very short answer — which is why a request can fail with plenty of window apparently left.

Rejected before anything is spent

An oversized request returns 400 at the gateway, before any provider is called, so it costs you nothing. The message states the measured size and the limit.

{
  "error": {
    "message": "Input is ~164970 tokens, which exceeds the safe limit of 160000 tokens for this model. Shorten the input or use a model with a larger context window.",
    "type": "invalid_request_error",
    "code": "invalid_request"
  }
}

The limit sits slightly below the advertised window on purpose. Token counting is an estimate until the provider tokenises for real, and a request accepted here but rejected upstream costs a round trip and is far more confusing to debug.

Maximum output#

A max_tokens larger than a model allows is clamped down — never up. Your value is a cost ceiling, so raising it silently would bill you beyond a budget you set deliberately.

Images on a model without vision#

The request is not rejected. The image is removed and replaced with a note telling the model it could not see an image, so it says so rather than describing something it never saw.

Current turn — the model is told explicitly not to guess, and to suggest switching to a vision model.
Earlier turns — replaced with a short marker so the history still reads coherently.

Editors and agent frameworks routinely attach screenshots the user never meant to send. Failing the whole request over an incidental attachment throws away the question they actually asked.

Tools on a model without native support#

Some models are driven through prompting rather than a native tool API. The wire format you see is identical either way — the same tool_calls shape comes back. Emulated tool use is less reliable on complex schemas, so keep parameter sets small if you target those models.

Checking capabilities#

GET /v1/modelslists the chat models your account can call, and the dashboard catalog shows the capability flags per model. Check there rather than inferring from a model's name — names do not reliably predict features.

Degradation respects all of this

When xKiro substitutes a model, capability is checked first: a candidate that cannot handle your images, your tools or your context length is skipped entirely. Serving a request the substitute cannot handle is worse than an honest error, because the failure surfaces halfway through your agent instead of at the call site.