Capability manifests

Versioned, per-provider records of exactly what each provider and profile supports - the source of truth that routing decisions and purge claims both read.

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 reads it to route correctly, 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

{
  "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

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

The Execution Broker uses manifests to filter and choose targets:

Eligibility

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.

Optimization

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.

Honest QoS reasons

When no eligible target exists, the QoS outcome reports a precise reason such as alias_no_compatible_target or region_unavailable, derived from the manifests.

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

Execution profiles

The profiles whose targets manifests describe.

Retention and purge

How a manifest caps a purge guarantee.