Provider Capabilities

Provider Capabilities

Migaki should be provider-neutral, not provider-naive.

Different providers expose different execution capabilities. mIR should stay portable while backends use provider-specific capabilities during lowering.

Capability Registry

type ProviderCapabilities = {
  supportsPromptCaching: boolean
  supportsExplicitCacheBreakpoints: boolean
  supportsAutomaticCaching: boolean
  supportsToolCalling: boolean
  supportsRemoteMCP: boolean
  supportsStructuredOutputs: boolean
  supportsBatching: boolean
  supportsReasoningControls: boolean
  supportsZeroDataRetention?: boolean
  maxContextTokens?: number
  cacheTtlOptions?: string[]
}

Registry Requirements

• Version provider capability declarations.
• Include source and observed date when capabilities are based on external docs.
• Allow tests to assert backend behavior against capability fixtures.
• Include assumptions in execution evidence bundles.
• Fail closed when a required provider capability is unavailable.

Lowering Rules

• mIR should describe logical execution intent.
• Backends should translate logical plans into provider-specific calls.
• Provider-specific optimizations should appear in evidence.
• Provider-specific failures should be represented as execution results, not hidden behind generic errors.

Examples

Prompt caching:

• mIR can identify stable context blocks.
• The OpenAI-style backend may use automatic cache behavior.
• The Anthropic-style backend may use explicit cache breakpoints.
• The evidence bundle records which assumption was used.

Structured output:

• mIR can require schema validation.
• A backend with native structured output support can lower directly.
• A backend without native support can use prompt constraints plus post-validation.
• The evidence bundle records the downgrade.

Risk

Provider APIs change quickly. A stale capability registry can silently produce bad plans. Capability drift should be treated as a normal maintenance problem, not an edge case.