# Capability manifests (/concepts/capability-manifests)
A **capability manifest** is a versioned, factual record of what one provider can do: does it cache prompts, how, with what discount and retention; does it have a Batch API; what is its context window; can its cache be manually cleared. The [Execution Broker](/concepts/execution-profiles) reads it to route correctly, and [purge](/concepts/retention-and-purge) reads it to claim only the deletion guarantee the provider can actually back. A manifest is data, not behavior - it describes reality so the rest of the platform can reason about it.
## Shape [#shape]
```json
{
"provider": "anthropic",
"manifest_revision": "cap_2026_06_09",
"prompt_cache_supported": true,
"prompt_cache_type": "explicit",
"prompt_cache_min_tokens": 1000,
"prompt_cache_discount_pct": 90,
"prompt_cache_default_ttl_seconds": 300,
"prompt_cache_extended_ttl_seconds": 3600,
"cached_token_reporting": true,
"manual_cache_clear_supported": false,
"batch_api_supported": true,
"batch_api_discount_pct": 50,
"batch_api_max_latency_seconds": 86400,
"response_retrieval_supported": false,
"conversation_state_supported": false,
"background_mode_supported": false,
"live_search_supported": false,
"context_window_max_tokens": 200000,
"multimodal_input_supported": true,
"dedicated_deployment_available": false,
"speculative_decoding_supported": false,
"service_tiers": ["standard"],
"data_retention_class": "zero_retention_available",
"region_support": ["us"]
}
```
`prompt_cache_type` is one of `none`, `automatic`, `explicit`, `implicit`, or `both` - capturing the real differences between, say, OpenAI's automatic caching, Anthropic's explicit cache-control, and Gemini's implicit caching.
## Manifests are versioned [#manifests-are-versioned]
Every manifest carries a `manifest_revision`. Provider capabilities change, and when they do the platform mints a new revision rather than mutating the old one.
An [alias release](/concepts/model-aliases) pins the `capability_manifest_revision` it resolved against. That means a past routing decision can be reasoned about with the exact capability facts that were true at the time, not with whatever the provider supports today.
## How routing reads them [#how-routing-reads-them]
The Execution Broker uses manifests to filter and choose targets:
A target that cannot satisfy a hard constraint - wrong region, too small a context window, no Batch API for a batch request - is filtered out before selection.
Among eligible targets, cache type, discount, and retention inform which path captures the most reuse for the workload. A 90% explicit-cache discount on a recurring long prefix compounds faster than a smaller automatic discount.
When no eligible target exists, the [QoS outcome](/concepts/qos) reports a precise reason such as `alias_no_compatible_target` or `region_unavailable`, derived from the manifests.
## How purge reads them [#how-purge-reads-them]
This is where manifests prevent the platform from over-promising.
`manual_cache_clear_supported: false` means the provider's cache cannot be actively cleared on request. A [purge](/concepts/retention-and-purge) against that provider therefore returns a `best_effort_expiry` guarantee bounded by `prompt_cache_extended_ttl_seconds`, **not** a false claim of immediate physical deletion. The manifest is what stops a purge receipt from promising more than the provider can deliver.
So the same purge request can yield different guarantee classes depending on which providers a workload touched, and the manifest is the audited source for each one. New provider adapters get a manifest reviewed before they ship, and manifests are re-audited on every provider API update.
The profiles whose targets manifests describe.
How a manifest caps a purge guarantee.