Feature request: provider-agnostic Model Capabilities registry (context window, token limits, feature support)

[natansalvadorligabo]

Expected Behavior

Provide a provider-agnostic, runtime-accessible model capabilities registry so applications can discover per-model capability and limits (for example: context window, max output tokens, and support for tool calling, streaming, multimodality, reasoning). The API should be additive and opt-in for providers that can supply this data.

Example API sketch (consumer):

Optional<ModelCapabilities> caps = modelCapabilitiesProvider.getCapabilities("gpt-5-mini");
if (caps.isPresent() && caps.get().contextWindowTokens() != null) {
    validatePromptBudget(caps.get().contextWindowTokens());
}
if (caps.isPresent() && !caps.get().supportsToolCalling()) {
    // Disable tool execution for this model at runtime
}

Providers or model implementations may register capabilities beans or the framework may ship a central lookup that aggregates provider-supplied metadata.

Current Behavior

Spring AI exposes model operations and options but does not provide a unified runtime capability descriptor for models. As a result, application teams must:

• hardcode per-model limits in their apps, or
• maintain and synchronize an external map/registry of model -> capabilities, or
• consult provider documentation at development time and rely on runtime inference.

None of these approaches are ideal for production systems that must validate prompt sizes, set safe defaults, or degrade features dynamically.

Context

How has this affected you?

• It increases application complexity and risk: apps either risk runtime failures (oversized prompts) or conservative limits that reduce utility.
• It forces duplicate maintenance across projects and teams.

What are you trying to accomplish?

• Add a small, provider-neutral contract to Spring AI so client code can query model capabilities at runtime and adapt behavior safely.

What other alternatives have you considered?

• Keep capability registries in application code (current workaround) — error-prone and hard to keep current.
• Provider-specific metadata APIs only — workable but fragments application logic and increases branching.
• Documentation-only guidance — insufficient for runtime validation.

Additional notes

• Fields should be nullable/optional when a provider cannot return them.
• Providers may expose extra, provider-specific keys via a map for advanced use cases.
• I can follow up with a PR that implements the minimal contract and a provider-side stub for one or two model integrations to demonstrate the pattern.

[jewoodev]

This seems like a useful runtime adaptation use case, but I would avoid making Spring AI a central source of truth for every provider/model capability. Model capability data changes frequently and can also depend on provider route or deployment context, so a framework-maintained catalog could become stale or misleading.

A smaller approach might be to introduce an opt-in, provider-neutral capabilities SPI. For example, core could expose a ModelCapabilities value type and a ModelCapabilitiesProvider lookup contract, while provider modules or applications can contribute or override capability metadata. Unknown values would remain unknown instead of being guessed.

That would allow applications to do runtime feature gating and prompt budget checks without requiring Spring AI to maintain a static catalog of all model facts.

I opened a small draft PR to make the proposed API shape more concrete: #6489