Vendor JS SDKs on One Aggregator Key: Which Ones Speak OpenAI-Compatible

Many teams want to use the official JavaScript SDKs for different model backends but prefer a single API key from an aggregator. This guide surveys the official JS SDKs for six popular backends—Claude, GPT, DeepSeek, Qwen, GLM, and Kimi—and checks whether they can point to a custom base URL without patching, what request-shape gaps exist, and how to shim them. We stay conceptual; no specific version numbers or rate limits are given, as these change frequently. Always refer to the latest vendor documentation.

Why Use Official SDKs with an Aggregator?

Using official SDKs gives you typed interfaces, streaming helpers, and idiomatic patterns for each provider. An aggregator lets you access many models with one key, simplifying billing and access. Combining the two requires that the SDK can target a custom endpoint (the aggregator's base URL) and that the aggregator accepts the SDK's request format—or that you can shim the differences.

The Six Backends and Their JS SDKs

We examine the following:

• Claude (Anthropic): @anthropic-ai/sdk
• GPT (OpenAI): openai
• DeepSeek: openai (OpenAI-compatible) or community SDKs
• Qwen (Alibaba): openai (OpenAI-compatible) or dashscope SDK
• GLM (Zhipu AI): openai (OpenAI-compatible) or zhipuai SDK
• Kimi (Moonshot AI): openai (OpenAI-compatible) or moonshot SDK

Most providers offer an OpenAI-compatible endpoint, meaning you can use the openai SDK with a different base URL. However, some features (e.g., function calling, vision, streaming) may have subtle differences.

Custom Base URL Support

The key question: can the SDK be pointed at a custom base URL without patching?

• OpenAI SDK: Yes. Set baseURL in the client constructor. This works for any OpenAI-compatible endpoint.
• Anthropic SDK: Yes. Set baseURL in the client constructor. The request shape follows Anthropic's API, not OpenAI's.
• DeepSeek: If using the openai SDK, yes. DeepSeek also provides its own SDKs; check if they support custom base URLs.
• Qwen: The openai SDK works with DashScope's compatible mode. The official dashscope SDK may not support custom base URLs easily.
• GLM: The openai SDK works with Zhipu's compatible endpoint. The zhipuai SDK may have its own configuration.
• Kimi: The openai SDK works with Moonshot's compatible endpoint. The moonshot SDK likely supports custom base URLs but verify.

In summary, the openai SDK is the most versatile for OpenAI-compatible backends. The Anthropic SDK is separate but also supports custom base URLs.

Request-Shape Gaps and Shims

Even with custom base URLs, request and response shapes may differ. Here are common gaps:

• Message format: Anthropic uses a messages array with role and content, but roles include system as a top-level parameter, not a message. OpenAI has system as a message role. When using the Anthropic SDK with an aggregator, the aggregator must translate to the target model's format.
• Function/Tool calling: The JSON schema for tools differs between OpenAI and Anthropic. Some aggregators normalize this; others don't.
• Streaming: SSE formats are similar but not identical. The openai SDK expects data: [DONE] and specific chunk structures. Anthropic's streaming uses different event types.
• Vision: Image input formats vary. OpenAI uses image_url objects; Anthropic uses source with base64 or URL.
• Parameters: maxtokens is common, but temperature, topp, etc., may have different ranges or defaults. Some models ignore certain parameters.

To shim these gaps, you can:

• Use the aggregator's OpenAI-compatible endpoint and stick to the openai SDK for all models. This minimizes shims but may limit access to provider-specific features.
• For provider-specific features, use the vendor SDK and point it to the aggregator. The aggregator must accept the vendor's request shape (i.e., act as a proxy). Not all aggregators do this.
• Write a thin adapter layer that transforms requests from the SDK's format to the aggregator's expected format.

Practical Integration Checklist

1. Identify the SDK: Choose openai for OpenAI-compatible backends; use vendor SDKs only if you need unique features.
2. Set the base URL: In the SDK constructor, set baseURL to your aggregator's endpoint (e.g., https://api.example.com/v1).
3. Authentication: Use your aggregator API key as the API key in the SDK. The aggregator will route based on the model name.
4. Model naming: Use the model identifiers that the aggregator expects. These may differ from official model names.
5. Test request/response: Send a simple chat completion. Check for errors related to unsupported parameters or mismatched shapes.
6. Handle errors: Aggregators may return errors in OpenAI format even for non-OpenAI models. Ensure your error handling is generic.
7. Streaming: Test streaming if needed. Verify chunk parsing works.
8. Tool calling: If using tools, verify the schema matches. You may need to adapt.
9. Monitor usage: The aggregator provides usage stats. Ensure your SDK doesn't interfere.

Conclusion

Most official JS SDKs can be pointed at a custom base URL, but the request shape must be compatible. The openai SDK is the safest bet for OpenAI-compatible backends (GPT, DeepSeek, Qwen, GLM, Kimi). For Claude, the Anthropic SDK works but requires the aggregator to support its message format. Always test with a simple request first, and be prepared to shim differences in tool calling, streaming, and vision. With an aggregator that offers OpenAI-compatible endpoints, you can use one key across many models with minimal changes.