feat: support anthropic openai api#12881
Conversation
…nai' into young/feat/support-anthropic-openai
There was a problem hiding this comment.
Pull request overview
This PR adds support for Anthropic's OpenAI-compatible API to the APISIX AI plugins. The implementation follows the pattern of other OpenAI-compatible providers by creating a new driver that uses the openai-base implementation.
Changes:
- Added new
anthropic-openaidriver for Anthropic API integration - Updated plugin schemas to include
anthropic-openaias a valid provider - Added comprehensive test coverage for the new provider
- Updated English and Chinese documentation across multiple plugins
Reviewed changes
Copilot reviewed 11 out of 11 changed files in this pull request and generated 8 comments.
Show a summary per file
| File | Description |
|---|---|
| apisix/plugins/ai-drivers/anthropic-openai.lua | New driver file for Anthropic OpenAI API using openai-base with proper host and path configuration |
| apisix/plugins/ai-drivers/schema.lua | Added anthropic-openai to chat_request_schema and is_openai_compatible_provider function |
| apisix/plugins/ai-proxy/schema.lua | Added anthropic-openai to provider enum in both instance and proxy schemas |
| apisix/plugins/ai-request-rewrite.lua | Added anthropic-openai to provider enum |
| t/plugin/ai-proxy-anthropic-openai.t | New test file with coverage for authentication, streaming, and basic request handling |
| docs/en/latest/plugins/ai-proxy.md | Updated to mention Anthropic support in description and provider list |
| docs/en/latest/plugins/ai-proxy-multi.md | Updated to mention Anthropic support in description and provider list |
| docs/en/latest/plugins/ai-request-rewrite.md | Updated to include anthropic-openai in provider options |
| docs/zh/latest/plugins/ai-proxy.md | Chinese version of ai-proxy documentation updates |
| docs/zh/latest/plugins/ai-proxy-multi.md | Chinese version of ai-proxy-multi documentation updates |
| docs/zh/latest/plugins/ai-request-rewrite.md | Chinese version of ai-request-rewrite documentation updates |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| | ------------------------- | ------------ | -------- | ------------------------------------------------------------------------------------ | | ||
| | prompt | Yes | String | The prompt send to LLM service. | | ||
| | provider | Yes | String | Name of the LLM service. Available options: openai, deekseek, azure-openai, aimlapi and openai-compatible. When `aimlapi` is selected, the plugin uses the OpenAI-compatible driver with a default endpoint of `https://api.aimlapi.com/v1/chat/completions`. | | ||
| | provider | Yes | String | Name of the LLM service. Available options: openai, deekseek, azure-openai, aimlapi, anthropic-openai, openai-compatible. When `aimlapi` is selected, the plugin uses the OpenAI-compatible driver with a default endpoint of `https://api.aimlapi.com/v1/chat/completions`. When `anthropic-openai` is selected, the plugin uses the OpenAI-compatible driver with a default endpoint of `https://api.anthropic.com/v1/chat/completions`. | |
There was a problem hiding this comment.
The provider name is misspelled as "deekseek" but should be "deepseek" to match the actual provider enum value.
| | ------------------------- | ------------ | -------- | ------------------------------------------------------------------------------------ | | ||
| | prompt | 是 | String | 发送到 LLM 服务的提示。 | | ||
| | provider | 是 | String | LLM 服务的名称。可用选项:openai、deekseek、azure-openai、aimlapi 和 openai-compatible。当选择 `aimlapi` 时,插件使用 OpenAI 兼容驱动程序,默认端点为 `https://api.aimlapi.com/v1/chat/completions`。 | | ||
| | provider | 是 | String | LLM 服务的名称。可用选项:openai、deekseek、azure-openai、aimlapi、anthropic-openai 和 openai-compatible。当选择 `aimlapi` 时,插件使用 OpenAI 兼容驱动程序,默认端点为 `https://api.aimlapi.com/v1/chat/completions`。 | |
There was a problem hiding this comment.
The provider name is misspelled as "deekseek" but should be "deepseek" to match the actual provider enum value.
| print "Hello, World!\n"; | ||
| print $resp; | ||
|
|
||
|
|
There was a problem hiding this comment.
Debug print statements should be removed from test files before merging. These print statements appear to be left over from development/debugging.
| print "Hello, World!\n"; | |
| print $resp; |
| | instances | array[object] | True | | | LLM instance configurations. | | ||
| | instances.name | string | True | | | Name of the LLM service instance. | | ||
| | instances.provider | string | True | | [openai, deepseek, azure-openai, aimlapi, openai-compatible] | LLM service provider. When set to `openai`, the Plugin will proxy the request to `api.openai.com`. When set to `deepseek`, the Plugin will proxy the request to `api.deepseek.com`. When set to `aimlapi`, the Plugin uses the OpenAI-compatible driver and proxies the request to `api.aimlapi.com` by default. When set to `openai-compatible`, the Plugin will proxy the request to the custom endpoint configured in `override`. | | ||
| | instances.provider | string | True | | [openai, deepseek, azure-openai, aimlapi, openrouter, openai-compatible, anthropic-openai] | LLM service provider. When set to `openai`, the Plugin will proxy the request to `api.openai.com`. When set to `deepseek`, the Plugin will proxy the request to `api.deepseek.com`. When set to `aimlapi`, the Plugin uses the OpenAI-compatible driver and proxies the request to `api.aimlapi.com` by default. When set to `openrouter`, the Plugin uses the OpenAI-compatible driver and proxies the request to `openrouter.ai` by default. When set to `anthropic-openai`, the Plugin will proxy the request to `api.anthropic.com` by default. When set to `openai-compatible`, the Plugin will proxy the request to the custom endpoint configured in `override`. | |
There was a problem hiding this comment.
Documentation mentions "openrouter" as a supported provider, but this is inconsistent with the actual implementation. The PR only adds support for "anthropic-openai", not "openrouter". Either the "openrouter" provider support needs to be implemented with corresponding schema updates and driver file, or it should be removed from the documentation.
| | instances | array[object] | 是 | | | LLM 实例配置。 | | ||
| | instances.name | string | 是 | | | LLM 服务实例的名称。 | | ||
| | instances.provider | string | 是 | | [openai, deepseek, azure-openai, aimlapi, openai-compatible] | LLM 服务提供商。设置为 `openai` 时,插件将代理请求到 `api.openai.com`。设置为 `deepseek` 时,插件将代理请求到 `api.deepseek.com`。设置为 `aimlapi` 时,插件使用 OpenAI 兼容驱动程序,默认将请求代理到 `api.aimlapi.com`。设置为 `openai-compatible` 时,插件将代理请求到在 `override` 中配置的自定义端点。 | | ||
| | instances.provider | string | 是 | | [openai, deepseek, azure-openai, aimlapi, openrouter, openai-compatible, anthropic-openai] | LLM 服务提供商。设置为 `openai` 时,插件将代理请求到 `api.openai.com`。设置为 `deepseek` 时,插件将代理请求到 `api.deepseek.com`。设置为 `aimlapi` 时,插件使用 OpenAI 兼容驱动程序,默认将请求代理到 `api.aimlapi.com`。设置为 `openrouter` 时,插件使用 OpenAI 兼容驱动程序,默认将请求代理到 `openrouter.ai`。设置为 `anthropic-openai` 时,插件使用 OpenAI 兼容驱动程序,默认将请求代理到 `api.anthropic.com`。设置为 `openai-compatible` 时,插件将代理请求到在 `override` 中配置的自定义端点。 | |
There was a problem hiding this comment.
Documentation mentions "openrouter" as a supported provider, but this is inconsistent with the actual implementation. The PR only adds support for "anthropic-openai", not "openrouter". Either the "openrouter" provider support needs to be implemented with corresponding schema updates and driver file, or it should be removed from the documentation.
| "stream": true | ||
| }, | ||
| "override": { | ||
| "endpoint": "http://localhost:7737/v1/chat/completions" |
There was a problem hiding this comment.
The endpoint in TEST 3 uses port 7737, but the mock server is configured to listen on port 6725 (line 53). This will cause TEST 4 to fail because it tries to send requests to the endpoint configured in TEST 3. The endpoint should be changed to "http://localhost:6725/v1/chat/completions" to match the mock server configuration.
| "endpoint": "http://localhost:7737/v1/chat/completions" | |
| "endpoint": "http://localhost:6725/v1/chat/completions" |
moonming
left a comment
There was a problem hiding this comment.
I have several concerns that need to be addressed:
- API Endpoint Compatibility (Critical)
According to Anthropic’s official documentation, their native API uses /v1/messages, not /v1/chat/completions. Could you please clarify:
• Does Anthropic officially support the `/v1/chat/completions` endpoint on `api.anthropic.com`?
• Can you share the complete test logs showing actual requests/responses to this endpoint?
If this endpoint isn’t officially supported, we may need to implement a native driver for the /v1/messages API instead.
- Testing Approach
The current tests use mocked responses, which only validates our routing logic but doesn’t verify actual compatibility with Anthropic’s API. Please add integration tests with real API calls to ensure the request/response format conversion works correctly.
- Naming Convention
The provider name anthropic-openai is confusing. We should use simply anthropic to match the pattern of other providers (openai, deepseek, etc.). The -openai suffix suggests this is a variant or compatibility layer, which may mislead users.
- Documentation Consistency
The docs mention both “OpenRouter” and “Anthropic” - please ensure consistency across all documentation files.
Looking forward to your clarification!
|
|
waiting merge of #12878 |
There was a problem hiding this comment.
Has this naming been confirmed? Do we need to add an explicit suffix hint for "using compatible API"? This seems inconsistent with our expectations. This holds true even if you intend to express a "vendor-product branch."
I believe that regardless of the AI we use internally, whether it's in compatibility mode or not has no impact on users. Since all APIs are now exposed in OpenAI format, users don't need to know the format used upstream—they just need the functionality to work.
Therefore, anthropic suffices as this provider value.
There was a problem hiding this comment.
My initial idea came from the naming of azure-openai, which has already been expressed above #12881 (comment). The advantage of doing this is to leave room for the Anthropic API.
But it seems you already have different ideas.
There was a problem hiding this comment.
agree to use anthropic as provider name
bzp2010
left a comment
There was a problem hiding this comment.
Temporarily block the merge until the provider name is confirmed.
Description
Refer to the changes in #12565 to add support for anthropic
Already tested in real world:
Which issue(s) this PR fixes:
Fixes #
Checklist