[Feature][AI Proxy] Register Anthropic Messages and Gemini protocol converters #8457

Feature Request

Register Anthropic Messages and Gemini protocol converters in AI Proxy, so that a client protocol a provider does not support natively is converted automatically. The routing for this already exists; only one converter is registered today.

Is your feature request related to a problem? Please describe

The conversion framework from #7871 is in place on master @ 9dd9a12. AiProtocolRouteResolver.resolve (shenyu-plugin-ai-proxy/.../enhanced/routing/AiProtocolRouteResolver.java L53-L80) forwards a request unchanged when the provider natively supports the client protocol. Otherwise it asks AiProtocolConverterFactory.findConverter for a converter, converts the request, and binds the reverse response conversion, including SSE.

Only one converter is registered: ConnectResponsesToChatConverter (OpenAI Responses to OpenAI Chat). It is registered in AiProxyPluginConfiguration.connectResponsesToChatConverter (L170-L174) and in the default route resolver of AiProxyEngine (L225-L228). As a result:

• A client using Anthropic Messages (POST /v1/messages) or the Gemini API cannot be served by any configured provider. All registered providers (OpenAI, DeepSeek, ALiYun, OpenAPI, Moonshot) are OpenAI-compatible.
• An Anthropic body also has a top-level messages array, so today it is detected as openai-chat by body shape and forwarded as if it were Chat. [Task] Unify AI protocol detection and support ai-prompt for more protocols #8371 / feat(ai): unify AI protocol detection and support ai-prompt for openai-response #8409 address detection.

Other AI gateways provide this conversion automatically. For example, Higress ai-proxy detects /v1/messages and converts it to OpenAI when the target provider does not support Claude natively.

The conversion library AI Proxy already depends on, io.github.agentic-ai-java:connect:0.1.0, declares Format.CLAUDE and Format.GEMINI next to OPENAI_CHAT and OPENAI_RESPONSES. Its RequestCodec and ResponseCodec contain Claude and Gemini codecs (toClaude/fromClaude, toGemini/fromGemini, Gemini usageMetadata). I identified these from the class files; I have not verified their behavior.

Describe the solution you'd like

1. Client-side converters to the providers ShenYu has today. Add AiProtocolConverter implementations, following ConnectResponsesToChatConverter, for:

   • Anthropic Messages to OpenAI Chat, with the reverse response conversion for JSON and SSE (message_start, content_block_delta, message_delta, message_stop).
   • Gemini generateContent / streamGenerateContent to OpenAI Chat, with the reverse conversion.

   Register them as beans in AiProxyPluginConfiguration. This needs client protocol registrations (AiProxyProtocol) for both formats, and path-based detection from [Task] Unify AI protocol detection and support ai-prompt for more protocols #8371 / feat(ai): unify AI protocol detection and support ai-prompt for openai-response #8409.

2. Provider-side converters, once native providers exist. When [Feature][AI Proxy] Add an opt-in native Anthropic Messages protocol and provider binding #8388 and [Feature][AI Proxy] Add opt-in native Gemini generateContent and streaming support #8389 add Anthropic and Gemini providers, add OpenAI Chat to Anthropic Messages and OpenAI Chat to Gemini converters. Then OpenAI-format clients can reach those providers.

3. Lossy fields. Report fields that cannot be represented in the target protocol through the existing diagnostics, using the same LossPolicy handling as the Responses converter. Reject the request before opening the upstream connection when a field cannot be represented safely.

4. Keep existing Chat and Responses routes unchanged. Document the supported conversion matrix in the AI Proxy README, which currently says it "does not add native Claude or Gemini upstream transports".

Describe alternatives you've considered

• Hand-written converters in ShenYu. These duplicate what connect already provides and add maintenance cost.
• Requiring clients to use the OpenAI format. This is the current state and blocks Claude-SDK and Gemini-SDK clients.

Additional context

• Related: [Task][AI Proxy] Introduce Provider-native protocol routing and bidirectional protocol conversion #7871 (conversion framework, closed), [Task] Unify AI protocol detection and support ai-prompt for more protocols #8371 / feat(ai): unify AI protocol detection and support ai-prompt for openai-response #8409 (protocol detection), [Feature][AI Proxy] Add an opt-in native Anthropic Messages protocol and provider binding #8388 (native Anthropic provider), [Feature][AI Proxy] Add opt-in native Gemini generateContent and streaming support #8389 (native Gemini provider), [Feature][AI Proxy] Add an opt-in vendor-native passthrough mode #8454 (passthrough mode).
• Governance plugins (usage, token limiter, PII, request view) also need to understand these formats; that is tracked in [Feature][AI] Support Anthropic Messages and Gemini payloads in AI governance plugins #8458.
• This adds client-visible protocol support, so it needs an IssueSpec Proposal and Design before implementation.