Overview
The TokenHub platform aggregates language models from multiple providers, including Tencent Hy, DeepSeek, Zhipu GLM, Kimi, and MiniMax, covering scenarios such as conversational interaction, content creation, code generation, and reasoning analysis. All models uniformly support two protocols: the OpenAI Chat Completions API and the Anthropic Messages API. You can directly use the OpenAI SDK, Anthropic SDK, or any compatible client to connect.
Supported Protocols by Model
|
Hy4 preview | hy4-preview
| ✅ | ✅ | ✅ |
Hy3 | hy3
| ✅ | ✅ | ✅ |
DeepSeek-V4-Flash 0731 GA (Vendor Direct) | deepseek-v4-flash-202605
deepseek/deepseek-v4-flash-0731
deepseek/deepseek-v4-flash
| ✅ | ✅* | ✅ |
DeepSeek-V4-Pro 0813 GA (Vendor Direct) | deepseek-v4-pro-202606
deepseek/deepseek-v4-pro-0813
deepseek/deepseek-v4-pro
| ✅ | ✅* | ✅ |
DeepSeek-V4-Flash-Vision-Exp (Vendor Direct) | deepseek/deepseek-v4-flash-vision-exp
| ✅ | ✅* | ✅ |
DeepSeek-V4-Flash 0731 GA | deepseek-v4-flash-0731
| ✅ | ✅* | ✅ |
DeepSeek-V4-Pro 0813 GA | deepseek-v4-pro-0813
| ✅ | ✅* | ✅ |
DeepSeek-V4-Flash | deepseek-v4-flash
| ✅ | ✅* | ✅ |
DeepSeek-V4-Pro | deepseek-v4-pro
| ✅ | ✅* | ✅ |
Deepseek-v3.2 | deepseek-v3.2
| ✅ | ❌ | ✅ |
GLM-5.3 | glm-5.3
| ✅ | ✅ | ✅ |
GLM-5.3-Flash | glm-5.3-flash
| ✅ | ✅ | ✅ |
GLM-5.2 | glm-5.2
| ✅ | ✅* | ✅ |
GLM-5.1 | glm-5.1
| ✅ | ✅* | ✅ |
GLM-5V-Turbo | glm-5v-turbo
| ✅ | ❌ | ✅ |
GLM-5-Turbo | glm-5-turbo
| ✅ | ❌ | ✅ |
GLM-5 | glm-5
| ✅ | ❌ | ✅ |
Kimi K3 | kimi-k3
| ✅ | ✅* | ✅ |
Kimi K2.7 Code HighSpeed | kimi-k2.7-code-highspeed
| ✅ | ❌ | ✅ |
Kimi K2.7 Code | kimi-k2.7-code
| ✅ | ❌ | ✅ |
Kimi-K2.6 | kimi-k2.6
| ✅ | ✅* | ✅ |
Kimi-K2.5 | kimi-k2.5
| ✅ | ✅* | ✅ |
MiniMax-M3 | minimax-m3
| ✅ | ✅ | ✅ |
MiniMax-M2.7 | minimax-m2.7
| ✅ | ✅ | ✅ |
MiniMax-M2.5 | minimax-m2.5
| ✅ | ✅ | ✅ |
Hy-MT2-Plus | hy-mt2-plus
| ✅ | ❌ | ✅ |
Note:
The ✅ symbol indicates native support. The ✅* symbol indicates support via compatibility mode indicates the model natively provides only the Chat Completions protocol, and the platform automatically performs protocol conversion on the server side. The invocation method is consistent with that of natively supported models, but certain parameters and built-in tools have limitations. For details, see the Responses API Compatibility Mode Description.
The models listed in the table can be called only after their corresponding model services are activated in the console. If a call is made before activation, a 402 error is returned. This is independent of whether the model itself supports the protocol.
Platform models are continuously updated. You can query the latest list of available models via the GET /v1/models API. Models with a status of online in the returned results are currently available.
Protocols and Invocation Methods
TokenHub uniformly provides clients with three industry-standard protocols. All models are accessed through the same set of Base URLs, requiring only a switch of the protocol path and the model (all three protocols use POST requests):
|
OpenAI Chat Completions | /v1/chat/completions
| OpenAI SDK and compatible clients | Most versatile, covering all models. |
OpenAI Responses | /v1/responses
| OpenAI SDK (Responses API) | A new interface for multiple input types and built-in tools, with limited model support. |
Anthropic Messages | /v1/messages
| Anthropic SDK and compatible clients | A Claude-style protocol, compatible with models such as DeepSeek. |
Base URL (Choose one based on the access region)
Singapore (Global): https://tokenhub-intl.tencentcloudmaas.com/v1
Guangzhou (Chinese mainland): https://tokenhub.tencentcloudmaas.com/v1
Silicon Valley (United States): https://tokenhub-us.tencentcloudmaas.tech/v1
Authentication Method (Set the request header according to the invocation protocol)
OpenAI Chat / Responses Path: Authorization: Bearer YOUR_API_KEY
Anthropic Messages Path: x-api-key: YOUR_API_KEY
For the complete field descriptions and invocation examples of each protocol, see the following documents:
TokenHub Changes Compared to the Standard API
TokenHub maintains the native semantics of three standard protocols for clients. Typically, the same piece of OpenAI / Anthropic SDK code can be integrated by simply replacing the Base URL, API Key, and model. Compared to the official standards of each protocol, the main differences are concentrated in the following aspects:
Unified Endpoint and Authentication: All models share the same set of Base URLs, with only the path switched according to the protocol (/v1/chat/completions, /v1/responses, /v1/messages). For OpenAI-compatible paths, use Authorization: Bearer, and for Anthropic paths, use x-api-key.
model is the platform model name: Enter the model identifier provided by TokenHub for model.
Capabilities vary by model: Support for thinking modes, tool calling, multimodal features, caching, and certain sampling parameters depends on the specific model used. Some fields in the standard protocol may be ignored or downgraded. For details, see the corresponding protocol-specific documentation.
Thinking Content Delivery Method: The OpenAI-compatible path returns the reasoning chain via reasoning_content, while the Anthropic path returns it via the thinking content block. The method for enabling or disabling this feature is determined by the corresponding protocol-specific documentation.
usage Field Differences: The usage fields (especially those detailing cache-related tokens) returned by different models are not exactly the same. Please refer to the actual returned values.
For per-field difference annotations and invocation examples of each protocol, refer to the three protocol-specific documents in the Protocols and Invocation Methods section above. Error Handling
Error responses for all three protocols are in JSON format, containing both the HTTP status code and the platform's business error code. Business error codes are six-digit numbers, where the first three digits correspond to the HTTP status code (for example, 400xxx corresponds to parameter errors, 401xxx to authentication issues, and 429xxx to rate limiting).
For a complete list of error codes, their meanings, and handling suggestions, see API Error Codes. Common Types of Errors During Integration:
401002: The API Key is invalid. Please confirm that the Key and the Base URL you are using belong to the same site. <Guangzhou> and <Singapore> are independent sites, and API Keys are not interchangeable between them.
402xxx: The model service is not activated or has insufficient quota. You must first activate the corresponding model in the console. This is independent of whether the model supports the protocol.
429xxx: Rate limiting is triggered. The response may include a Retry-After header. It is recommended to retry using exponential backoff.
When an error occurs during the return of a streaming request, the error information is presented as an SSE error frame within the data stream. This must be handled during stream parsing.
AI Tools Integration
TokenHub is compatible with both the OpenAI and Anthropic standard protocols. Consequently, the vast majority of AI coding tools and Agent clients that support custom model services can connect directly without requiring modifications.
The integration process typically requires only three steps:
1. Create an API Key in the console and activate the required model.
2. In the tool's configuration (configuration file or environment variables), set the service address to TokenHub's Base URL. For tools using the OpenAI protocol, enter https://tokenhub-intl.tencentcloudmaas.com/v1. For tools using the Anthropic protocol, enter the same address. The platform automatically distinguishes between them based on the request path.
3. Replace the model name with the model parameter value from Supported Protocol Overview, and confirm that the model supports the protocol used by the tool. The configuration file locations, environment variable names, and optional parameters vary across different tools. The detailed configuration steps for each tool are as follows:
Dedicated Guide Portal
The above provides a general explanation applicable across models. For vendor-specific parameters, version differences, and best practices for each model, refer to the corresponding vendor-specific documentation:
Some capabilities have dedicated documentation. When relevant, please refer to them as well: